Search Unity

EntityCommandBuffer.AddComponent()

Discussion in 'Data Oriented Technology Stack' started by orionburcham, Jan 19, 2019.

  1. orionburcham

    orionburcham

    Joined:
    Jan 31, 2010
    Posts:
    491
    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!
     
    Last edited: Jan 19, 2019
    chris_schubert likes this.
  2. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    6,428
    Unless you remove thread, please don't delete the initial posts, and share results if you found solutions.
    Others may find it helpful too.
     
  3. orionburcham

    orionburcham

    Joined:
    Jan 31, 2010
    Posts:
    491
    Undeleted, for posterity. :)
     
    Last edited: Jan 19, 2019
    Antypodish likes this.
  4. orionburcham

    orionburcham

    Joined:
    Jan 31, 2010
    Posts:
    491
    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.
     
  5. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    1,907
    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.
     
    orionburcham likes this.
  6. orionburcham

    orionburcham

    Joined:
    Jan 31, 2010
    Posts:
    491
    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.
     
  7. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    1,907
    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)
     
  8. orionburcham

    orionburcham

    Joined:
    Jan 31, 2010
    Posts:
    491
    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.
     
    Last edited: Jan 20, 2019