EntityId in setUserData?

Hi,

I want to put entityId object in setUserData of the mesh but its showing me UnsupportedType exception.

[java] public Spatial createModel (EntityId e) {
models[modelIndex].setUserData(“Entity”, e);
[/java]

However setUserData accepts all objects in its arguments I guess??

My purpose is,
I want to store entity ID because I dont know what components will be attached to the model at compile time. I will parse a string and then depending on its content attach components conditionally. How should I construct a entity object without knowing the components.

Secondly, whats is the underlying difference between entity and entityId, what are use cases??

I don’t know about Zay-ES but if that is the same old user data as on spatials the answer is that it does not accept all objects as arguments although it isn’t obvious.

This should give a hint.

https://code.google.com/p/jmonkeyengine/source/browse/branches/3.0final/engine/src/core/com/jme3/scene/Spatial.java#1226
https://code.google.com/p/jmonkeyengine/source/browse/branches/3.0final/engine/src/core/com/jme3/scene/UserData.java#86

You can attach only Savable objects or primitive types. You have two choices basically - either extract the internal representaton of EntityId and put it as long/string (whatever it is in this case) and the reconstruct EntityId back when retrieving, or create a simple wrapper class which implements Savable and contains EntityId.

Big question is if you serialize your runtime structures using JME serialization. If not, wrapper can be just not implemented - simple class to keep JME happy. If you do, you will anyway have to access internal representation of EntityId, so you might as well skip the wrapper alltogether.

I’m confused by the rest of your post regarding attaching unknown entities to model based on what is contained in model. I use above hacks purely for picking purposes - so when I do collission with geometry, I can immediately get entity id without having some big reverse lookup geometry->entity map. In almost every other case, you should have pointers/maps from entity to geometry/nodes, not from scenegraph to entities.

Just pass the long returned by getId() to setUserData() and then create an EntityId from it when retrieving it. UserData is kind of annoying this way but I guess it keeps users from shooting themselves in the foot later.

It would be nice if there were some easy way to reconcile the three different ways to serialize something in a JME app (Java Serialization versus SpiderMonkey Serialization versus JME Savables)… but it’s not so bad I guess.

Anyway… for example:
spatial.setUserData(“entityId”, someEntityId.getId());

EntityId myId = new EntityId(spatial.getUserData(“entityId”));
…basically.

Got it. Thanks a lot!!

The other part of my question is that why do we need entities when we have entityIds. If one just look at the outer abstract interface of Entity and EntityId, one will conclude that EntityId is with all components and Entity is with only a subset of its components. We can construct entity at anytime using entityId. So entity seems like a subset of entityIds. In this case there is no point to pass entity anywhere as its just subset of entityid (although we can get entityid from entity)…

I’m digressing now, would be glad to hear if you have some points on this.

EntityId has no components at all. It is just a primary key of the entity.
Entity is a concept - collection of all components belonging to given EntityId. In some implementations you won’t have Entity class at all - just a big table of (EntityId,ComponentType)->Component. Entity class which is present in zay-es is not really The entity, it is rather something like … EntityView? EntitySnapshot? Just a convenience class so you can access multiple components of same entity at once, without having to re-query them one by one.

An Entity is a specific view of an entity at the time it was captured… as part of an EntitySet. It’s a specific view for one system and isolated from all of the other systems.

Yeah, @abies has it right.

You may want to ask some deeper questions along these lines because it’s a sign that you may not really understand the point of an ES yet.