[Request] Add TryToAdd/TryToSet/TryToRemove to ECBCommand

Hi,

After several implementations of ECS system, I notice that IJobParallelFor and EntityCommandBuffer can be difficult to managed,especially concurrent ECB.

For example, If I want add a tag to an entity targeted by my datas in IJobParallelFor. If several datas target same entity I will have errors.

But with just 3 new methods in ECB and EntityManager, life can be easier :

  • TryToAdd : Check if component exist, if yes skip command else add component. ( Add throw a error if component already exist)
  • TryToRemove : Check if component exist, if no skip command else remove component
  • TryToSet : Check if component exist,if yes set it else add new component to entity

What do you think of that, guys ?

3 Likes

What I figured is if I add a component to an entity that already has said component and I get an error, I simply did not implement my system correctly.

Since my systems act on entities that I either KNOW have X,Y,Z components or if for example I use a Query where I can check if it has some A,B,C “extra” components I don’t have to rely on ECB to tell me whether or not Components already exist on the Entity.

I’m not sure if tryadd, tryremove, etc would just be a band-aid on a “badly” designed system.

what a difference between use ECB or use a extra query and implicitly a another job for fix this problem ? Aside performance, I don’t know why one solution is “bad design” and another not.

But maybe targeting an entity is not a good design in ECS perspective.

I use the term badly very vaguely because I’m not sure if it’s the right answer or not, I don’t mean to assume your design is bad.

Without more details about what you’re trying to do in your System & Job it’s hard for me to justify the need for a try-methods when so far I haven’t seen the use for it in any pattern that I use.

I’m not suggesting targeting an entity in particular. I’m suggesting that you could assume that an Entity has X,Y,Z components already from what you’ve injected.

I apologize if my English is a bit confusing.

It’s true when job begins, but after that not.

Imagine a storage system. Theses storage have to say when they want resources. Need for resource can be triggered from very different others places . If you want to allow parallelism, you create a barrier for synchronization and in the barrier you add NeedResourceFlag. but when you apply theses commands the flag can already be added by an another system or before and you get an error.

Again, maybe it’s my reasoning which is false from the start and I’m happy to discuss about that too :wink: