This is a question what is the best style to do it.
If I have a collision/contact handler which tells me which Nodes collide. So I have the Node objects and the Name of it.
But I need the original object which contains the node so that I can say for example ship.addDamage(someValue);
What is the best way to asociate a Node to an object? Derive all my classes from Node? Or add them with their names to a static hashtable?
My classes are declared like that:
class MyShip
{
PhysicsNode node;
float shields=100;
public MyShip()
{
// create physics node, assign a name and add it to scene
}
public void addDamage(float value){shields-=value;}
}
hashtable/hashmap should be fine (not necessarily static, though)
Thanks, Irrisor.
I just noticed that there was a similar thread ("How to best get Java object from Geometry") some time ago 
Sure I could use a hashtable, but I have to guarantee that all names in my app are unique (who really can say this in a really large app).
Then I have to remember to always update the hashtable when nodes are removed/added. When a node which contains childnodes is added removed I would have to recursively find all its childs and update the hashtable each time.
Also if I do not make the hashtable static, I always have to pass it around which is very annoying.
I think this is such a common task, wouldn't it be a good idea to add a field "Object owner" to the class Spatial itself?
Aren't you one of the developers of JME? What is your opinion of that?
Please correct me this is complete nonsense what Iam talking about
codymanix said:
Sure I could use a hashtable, but I have to guarantee that all names in my app are unique (who really can say this in a really large app).
No, don't use names - use the Spatials as keys.
codymanix said:
Then I have to remember to always update the hashtable when nodes are removed/added.
yes (this is usually guaranteed by doing that in the setter for the spatial in your entity)
codymanix said:
When a node which contains childnodes is added removed I would have to recursively find all its childs and update the hashtable each time.
no, (recursively) lookup the parent of a Spatial if you can't find the entity for it instead (more efficient)
codymanix said:
Also if I do not make the hashtable static, I always have to pass it around which is very annoying.
that's a matter of preference - from a general software engineering perspective using static stuff (or singletons) is "bad"
codymanix said:
I think this is such a common task, wouldn't it be a good idea to add a field "Object owner" to the class Spatial itself?
Aren't you one of the developers of JME? What is your opinion of that?
We already discussed this several times. The problem with this is, that there might be multiple owners for a spatial (e.g. an animation controller from some library - or jME itself - could use it, and the actual game as well). Additionally most Spatials do not have an owner - so the additional field/list would waste memory. Search for "user object" on the boards for the complete story.
Thank you for the quick reply!
I thought a little bit and this came up my mind:
UserDataManager.getInstance().AddUserData(mySpatial, myDomainObject);
UserDataManager.getInstance().AddUserData(mySpatial, myController);
and then:
MyDomainObject obj = UserDataManager.getInstance().GetUserData(mySpatial, MyDomainObject.class);
MyController ctrl = UserDataManager.getInstance().GetUserData(mySpatial, MyController.class);
That is, you would be able to store multiple objects per spatial, and later you retrieve them using its type as key.
It would be implemented with a static hashtable (spatial reference is the key) which item type is another hashtable where the class is the key.
Like that: Hashtable< Spatial, Hashtable<Class, Object> >
The engine should ensure that all userdata of of removed nodes is removed also.
This way you do not waste memory in the spatial itself and you can assign multiple user objects to any spatial (but only one per type, you cannot add multiple instances of MyController for example to the same spatial, which isn't useful anyway).
What do you think of that?
No answer? Was my idea worse than I thought?
Wouldn't this be a great enhancement to JME?
codymanix said:
What do you think of that?
Using a separate map for those different classes/purposes saves memory and makes lookup faster. Additionally adding and removing to/from a map is done with a single line of code. So why would someone benefit from such an addition to jME?
Sure, the only gain would be that the user would be saved from writing boilerplate code again and again.
But maybe you are right, for most purposes a simple hashtable and 2 lines of code will be enough.
Thank you for reply, anyway!