EntityCommandBuffer.AddComponent()

Hi Unity dev team!

Is there any chance EntityCommandBuffer will gain an AddComponent method that takes an Entity and a ComponentType? For example, I'd like to write a component, like this:

Code (CSharp):

1. struct AddTagCommandComponent : IComponentData
2. {
3.     public Entity entity;
4.     public ComponentType tagTypeToAddToEntity;
5. }

..then, in an early system, OnUpdate():

Code (CSharp):

1. PostUpdateCommands.CreateEntity();
2. PostUpdateCommands.AddComponent(new AddTagCommandComponent(){ entity = fooEntity, tagTypeToAddToEntity = barTagType });

...and then later, in "AddTagsSystem.OnUpdate():

Code (CSharp):

1. AddTagCommandComponent command = commands[i];
2. PostUpdateCommands.AddComponent(command.entity, command.tagTypeToAdd);

I'd rather do something like this, than write a different system to add each tag type.

Why would I do it this way, instead of just calling PostUpdateCommands.AddComponent<T>() from each system? I've left out that example for simplicity. But I can reply with it if it would be helpful.

Thanks for any info!

 

Unless you remove thread, please don't delete the initial posts, and share results if you found solutions.
Others may find it helpful too.

 

Undeleted, for posterity.

 

The short reason why I wanted to do this:

1. So I could add some logic before actually adding the tag, to avoid multiple systems attempting to add the same tag to an entity.

2. I've been postponing the creation or destruction of my Entities until the end of the update loop, after most other systems have run. So, rather than immediately destroying an entity, I would 'mark it for destruction' by adding a "DestroyEntityCommand" component to it.

The arrangement in the OP would let me add some logic to avoid adding tags to Entities which are scheduled for destruction.

- - -

What I'm doing now:

I'm looking into giving up those checks, and just calling EntityCommandBuffer.AddComponent<T>() from systems, as needed. I wanted to investigate this as an implementation before deciding it wouldn't be just fine.

 

Why not just create a simple event with a reference to the entity to destroy?

This way you have no concerns about adding the same component multiple times and also you don't have the performance issues of moving entities between chunks.

Again, if you simply used an event instead of adding the component via entity command buffer you could easily verify if the component didn't exist before adding it.

I personally advocate for where possible, never allowing more than 1 system to be able to add a specific component to an entity but where not possible, to me this is the safest approach. Otherwise you need multiple barriers, checks and system ordering to ensure 2 different systems don't add the same component in the same frame.

 

So that later systems (systems that run after the entity has been marked for destruction) can filter their component groups to avoid doing work on these entities.

 

But if later systems doing work on a component is an issue, why aren't you just destroying it instantly?

(I made some edits to my original post)

 

There are different ways to approach this, and destroying them immediately might work great in your project. There are also times when deferring entity changes might help simplify your logic.

That said, I don't want to stray too far away from the OP topic. Please PM me if you want to dig into this one more.