Whoever fixes these problems wins a bag of Julio’s. (I’m serious.) None of these are trivial:
1) When you join two objects then rotate the parent, the child becomes impossible to control. When you drag it one way, it moves in another direction. My best guess is that we can fix this by modifying RelationalMovable or Wicket or ClickManager or wherever we implement our drag-and-drop these days. Moving a Wicket should take into account the local translation of its parent.
2) Parent/Child relationships are preserved as long as the server is running. But when you kill the server, problems arrise. I think register recursively needs to be adjusted. And possibly Wicket needs to save its name and its parent’s name; but I think this is probably already the case (because Wicket extends Node, which surely saves its own name.) So this might be as simple as sending the right parent name in the SynchronizeCreateCommonMessage that we create for each Wicket we load. However, if we have to worry about the order that messages are received on the client, then we might have trouble. For example, what if a client gets a message to create a child before it has created the parent? It will try to set the child’s parent to a Wicket that doesn’t exist yet. Should it wait around in its own thread until the parent has been created? We’ll have to see if things start breaking.
3) We can join Wickets, but we can’t unjoin them. This won’t be hard, I think. We can just have a key (like “U”), which loops through all of the selected Wicket’s children and sets their parents to be the sceneNode. But these changes must, of course, be reflected on the Server and other clients. So sending the proper messages is important. It’s possible that you can use existing method in Wicket — setParentWithName(String name) — for changing the parent based on a name string. The only problem is that, at the moment, the sceneNode’s name is null. NOTE: I think I might have left a field in SynchronizeCommonMessage called parentName. Don’t use it. It doesn’t do anything. All name setting is based on using the setId() method in Wicket (to which you pass a SynchronizeMessage’s syncObjectId.)
4) The thing that’s frustrating me most right now is that sometimes (but not all the time), if you log onto the server and create an object, all will SEEM well; but it really isn’t…
The server outputs something like “registering object with id = 2.” But then, whenver you try to move the object you’ve made, the server will continually spit out “Unable to find object 2 on server.” So it seems like it didn’t really register it in the SynchronizationManager.
I have no idea why this happens. But I have one clue: I played around with the call to hasDuplicate() in CommonObjectSynchronizationManager; and when I removed it, the problem (as far as I could tell) disappeared. It was, however, replaced by a problem involving duplicate Wickets appearing in the game — which is the same problem that motivated us to make the hasDuplicate() method in the first place. It keeps duplicate SyncWrappers from getting into the active queue in CommonObjectSynchronizationManager. So maybe it’s being too zealous and keeping SyncWrappers out when it should be letting them in?