How to get all components attached to an entityid

Hi,

I want to get all components attached to an entityid. One way to do is to check for each EntityComponent using something like this and check whether it returns null or not…
[java]MagnetSubMesh subMesh = ed.getComponent(entity.getId(), MagnetSubMesh.class);[/java]

However this is not generic as my code needs to know what all components exist in the code. is there a generic way to get all components attached to an entityid??

@simar.i3r said: Hi,

I want to get all components attached to an entityid. One way to do is to check for each EntityComponent using something like this and check whether it returns null or not…
[java]MagnetSubMesh subMesh = ed.getComponent(entity.getId(), MagnetSubMesh.class);[/java]

However this is not generic as my code needs to know what all components exist in the code. is there a generic way to get all components attached to an entityid??

No, because a game using an ES should never need to know this information.

Can you say why you think you need it?

At present, i do all checks like this:

[java]
MagnetSubMesh subMesh = ed.getComponent(entity.getId(), MagnetSubMesh.class);
if (subMesh != null) {
DoWhatYouWant();
}

AnotherComponent anotherComp = ed.getComponent(entity.getId(), AnotherComponent.class);
if (anotherComp != null) {
DoWhatYouWant();
}
[/java]

@pspeed but i really think it would be cool to have possibility to get all components. I agreed with @simar.i3r . It would be easier and faster to write code like this:

[java]
if (allComponents.hasComponent(MagnetSubMesh.class)) {
DoWhatYouWant();
}

if (allComponents.hasComponent(AnotherComponent.class)) {
DoWhatYouWant();
}
[/java]

But that’s my IMHO. As i’m not an advanced programmer.

Edited:
It would be cool if EntitySet could put “null” for its specified components.
For example:
[java]entData.getComponents(MagnetSubMesh.class, AnotherComponent.class);[/java]
And even if AnotherComponent.class=null, so the entitySet will have the Entity with only MagnetSubMesh.class and AnotherComponent.class=null.
I hope i wrote clear.

@mifth said: At present, i do all checks like this:

[java]
MagnetSubMesh subMesh = ed.getComponent(entity.getId(), MagnetSubMesh.class);
if (subMesh != null) {
DoWhatYouWant();
}

AnotherComponent anotherComp = ed.getComponent(entity.getId(), AnotherComponent.class);
if (anotherComp != null) {
DoWhatYouWant();
}
[/java]

@pspeed but i really think it would be cool to have possibility to get all components. I agreed with @simar.i3r . It would be easier and faster to write code like this:

[java]
if (allComponents.hasComponent(MagnetSubMesh.class)) {
DoWhatYouWant();
}

if (allComponents.hasComponent(AnotherComponent.class)) {
DoWhatYouWant();
}
[/java]

But that’s my IMHO. As i’m not an advanced programmer.

Edited:
It would be cool if EntitySet could put “null” for its specified components.
For example:
[java]entData.getComponents(MagnetSubMesh.class, AnotherComponent.class);[/java]
And even if AnotherComponent.class=null, so the entitySet will have the Entity with only MagnetSubMesh.class and AnotherComponent.class=null.
I hope i wrote clear.

You are no longer writing an ES based game with these idioms so maybe don’t use an ES.

and this: if (allComponents.hasComponent(MagnetSubMesh.class))
…is patently ridiculous. Why would you do a query for some 20-30 components when you are only interested in one.

These “rules” aren’t just arbitrary… they’re to protect you from silliness like the above.

@pspeed said: You are no longer writing an ES based game with these idioms so maybe don't use an ES.

and this: if (allComponents.hasComponent(MagnetSubMesh.class))
…is patently ridiculous. Why would you do a query for some 20-30 components when you are only interested in one.

These “rules” aren’t just arbitrary… they’re to protect you from silliness like the above.

I know, Artemis is not so good example, but the Artemis can get all components…
At least on server side it would be useful i think.

If we do wrong, then what should we do?
For example i have 20 entities and only 10 entities have MagnetSubMesh.class. But i need to parse all entities with different components…

@mifth said: I know, Artemis is not so good example, but the Artemis can get all components... At least on server side it would be useful i think.

If we do wrong, then what should we do?
For example i have 20 entities and only 10 entities have MagnetSubMesh.class. But i need to parse all entities with different components…

Why do you want to do this? It’s so hard to talk in general nothingness because I can’t offer the real way to do it. “Why do I have no direct opening to my stomach? I want to put the something right in there.”

@pspeed said: Why do you want to do this? It's so hard to talk in general nothingness because I can't offer the real way to do it. "Why do I have no direct opening to my stomach? I want to put the something right in there."

Because i have to do many checks. Possibly that’s not so bad… I just told you my opinion.

@mifth said: Because i have to do many checks. Possibly that's not so bad... I just told you my opinion.

What checks? Why do you need to make these checks? There is possibly a better solution but I cannot help you find it.

Person 1: “Why did nature not supply me a port below my chest to shove things into my body?!? I want to know!!”
Person 2: “Well, what do you want to shove into there?”
Person 1: “That’s the way I do it. I just told you my opinion.”
Person 2: “But what could you possibly want to shove in there? It makes no sense.”
Person 1: “I must have this apple in there now!!!”
Person 2: “Like, to digest?”
Person 1: “Of course!”
Person 2: “Then you will need to eat it… which will take care also of the half-dozen other things required for properly digesting the apple anyway. Take a bite and chew.”

@pspeed said: What checks? Why do you need to make these checks? There is possibly a better solution but I cannot help you find it.

Person 1: “Why did nature not supply me a port below my chest to shove things into my body?!? I want to know!!”
Person 2: “Well, what do you want to shove into there?”
Person 1: “That’s the way I do it. I just told you my opinion.”
Person 2: “But what could you possibly want to shove in there? It makes no sense.”
Person 1: “I must have this apple in there now!!!”
Person 2: “Like, to digest?”
Person 1: “Of course!”
Person 2: “Then you will need to eat it… which will take care also of the half-dozen other things required for properly digesting the apple anyway. Take a bite and chew.”

Good joke :slight_smile:
Well, we talked about getting all components for an entity. That’s pretty clear and i already explained my point.
My characters/ships can have many different components. That’s why i do many checks.

Yes… but so far “getting all components” is the equivalent of “can I shove objects directly into my stomach?”

I know you want to… but I’ve yet to hear a good reason why. And I can’t describe how to do it properly because I don’t know what the real need is.

In your case, you are missing systems or you have too many components. I can’t offer more advice than that because I don’t know anything about what you are doing. But your design is probably flawed.

i think that the whole point of having an entity system is precisely to avoid such thing.

I mean : if you have 3 different comportement, you must create 3 different class. If your ship can take damage, you attach a “damageable” comportement to it and nothing else. If you want to move it, add a “moveable” comportement. And if you want to move it BUT make it take damage when moving well … create a whole new comportement.

I think that the idea of entities is to have a very clear approach of each entity comportement, because none of its part is something that rely on inheritance tree, interacting comportements and stuff like that.

However, i am maybe wrong, as i didn’t see any BIG system using that approach (big = os or close to that).

@bubuche said: i think that the whole point of having an entity system is precisely to avoid such thing.

I mean : if you have 3 different comportement, you must create 3 different class. If your ship can take damage, you attach a “damageable” comportement to it and nothing else. If you want to move it, add a “moveable” comportement. And if you want to move it BUT make it take damage when moving well … create a whole new comportement.

I think that the idea of entities is to have a very clear approach of each entity comportement, because none of its part is something that rely on inheritance tree, interacting comportements and stuff like that.

However, i am maybe wrong, as i didn’t see any BIG system using that approach (big = os or close to that).

Yes, exactly.

So either there is a potential flaw in design as in @mifth’s case… or there is some meta-problem I’m not understanding which is potentially what OP was looking for.

@pspeed said: No, because a game using an ES should never need to know this information.

Can you say why you think you need it?

Although my case would be hard to explain, I can try a simple case if that makes sense.
Lets say my code attach components dynamically based on certain entries from database (say some bonus points etc). Now I may have different type of bonus points based on which I have different types of components that attach dynamically. Now I have a lot of these components (because we are contradicting theoretically so assume as big number as you can fascinate about) and for debugging reasons I want a dump of components attach to my particular entity. Should I write a million of those checks???

I can try to imagine some more usecases:: (totally imaginative)

  1. Suppose I want to attach another JUMBO power component if he has more than 100 components (special powers, irrespective of what they are) attached
  2. i will post if i get more…

I think you have too many component types and not enough entities. Hard to say how much without more information.

@pspeed said: I think you have too many component types and not enough entities. Hard to say how much without more information.

I created this use case out of imagination although logging is one of my concern…
What about logging thing??

Again I’m no expert and infact novice in both java and game and entitysystems. Just need your opinion…

@pspeed said: I think you have too many component types and not enough entities. Hard to say how much without more information.

In my particular case I dont have too much now but it may grow in future.
And our system should be scalable…

@simar.i3r said: I created this use case out of imagination although logging is one of my concern... What about logging thing??

Again I’m no expert and infact novice in both java and game and entitysystems. Just need your opinion…

The is the problem with manufacturing use-cases out of imagination… it’s hard to see if they are even valid. (Like the shoving an apple into the stomach thing.)

What kind of logging do you want to do? It’s just not something an ES game normally cares about. Sure, it might be interesting to see “Gee, what all components are attached to this entity?” But it’s just not important information. A system will care if it has the components it cares about… and then nothing else. If you have the proper mindset that systems are separate, then beyond curiosity, your brain should care little what all components an entity has out of context.

And the thing is, given the way the persistence side of Zay-ES works it’s really not easily possible to answer the question without a lot of code changes to support it. For debugging purposes I may add it (and I will slap a HUGE warning on the method and probably make you cast to some weird ThisIsOnlyForDebuggingBecauseOtherwiseItsDumb interface)… but unless someone has an “I was trying to solve this problem and needed this info” use-case, it’s not a high priority.

Having the information available encourages poor design and offers no real world benefit until someone points out a good use case.

@simar.i3r said: In my particular case I dont have too much now but it may grow in future. And our system should be scalable...

Yes, but to be scalable you have to design properly. Which means systems dealing with a subset of components and not “any random component it wants to”. That’s the point, really.

Also, instead of having 50 different damage components there is probably really only one damage component and perhaps some other attribute components that get attached to the same damage entity.

Again, I can manufacturer as many fake solutions as there are fake use-cases… it’s better if we deal with the real ones, though.

Actually I do something like this in my es often.

For example since the network system is only a system itself, it goes trough all components, and if they are network synchronized adds them to changemessages as needed.

Another case I use this for is slightly to large systems. Eg my physicsystem has to do a few checks additional if its a raycast vehicle and not only a rigidbody. This could be done in a different system, but the additional necessary synchronizing to the physicsspaces worker thread would lead to an additional tick delay before changes are registerd.

So it can be used for some usecases, but of course it’s noone 100% pure entitysystem anymore. (If you really need that is your own choice)

I decided for this because I will not haven more than 1million entities loaded t the same time. And the scalability does not start to suffer from this before that in my tests.

@Empire Phoenix said: Actually I do something like this in my es often.

For example since the network system is only a system itself, it goes trough all components, and if they are network synchronized adds them to changemessages as needed.

Another case I use this for is slightly to large systems. Eg my physicsystem has to do a few checks additional if its a raycast vehicle and not only a rigidbody. This could be done in a different system, but the additional necessary synchronizing to the physicsspaces worker thread would lead to an additional tick delay before changes are registerd.

So it can be used for some usecases, but of course it’s noone 100% pure entitysystem anymore. (If you really need that is your own choice)

I decided for this because I will not haven more than 1million entities loaded t the same time. And the scalability does not start to suffer from this before that in my tests.

But surely your second case does not need all of the components, right? Just one that isn’t necessarily used mainly by the system. And that’s fine for one or two things every now and then. Not pure but not too bad.

Zay-ES has more efficient networking than the first case and simply knowing all components would be an inefficient way to do what it does. There are other down sides (no writable components on the client no matter what, for example… which is desirable in many use-cases).