CommandBuffer API for relations?

[Danon5]

Are there any plans to support relations in the CommandBuffer API?

[friflo]

hi @Danon5,

thought about this feature whenever dealing with the CommandBuffer topic.
For now I am not sure if the effort is worth it.

The main reason for a CommandBuffer is to add or remove components inside a query loop.
This is necessary because components are store in archetypes.
Adding/removing components will move a component to a different archetype. Aka a structural change.
Without a command buffer adding/removing a component within a query loop will screw up the iteration.
So a command buffer apply these changes when the loop is finished.

Relations a not stored in Archetypes. They a stored in a separate independent data structure.
This decision was made to a avoid archetype fragmentation.
If storing relations in archetypes each relation would requires its own archetype instance which create many objects on the heap.
In this ECS the data structure storing relations requires only require a ~ dozen objects on the heap independent form the amount of relations.

There are two properties which enable to iterate all relations using EntityRelations

• Entities
• Pairs
  Adding/removing relations within a loop using these API's will screw up iteration also.
  In this case a common buffer for relations is required.
  Is this a common use-case which justify the effort? At the moment I am not sure.

As components and relations a stored in different independent data structures the following use-cases are fine

• Add/remove relations within a query loop iterating components
• Add/remove components within a loop iterating Entities or Pairs of relations mentioned above.

[Danon5]

Avoiding archetype iteration errors is not the only use case for command buffers. In the case where you are iterating over a set of entities and are making changes to them, the other important feature of command buffers is simply that all the actions are deferred. Let's say you are iterating over 2 entities (contrived example). On the first iteration, you make a change to some component data using the command buffer, and also happen to make a change to the relations. Perhaps this first entity makes a change in relationship status specifically to entity 2. By iteration 2, if you for whatever reason rely on the incoming links or any other aspect of relations really, the component data on entity 1 will not have been changed by this point in the iteration (it is being deferred still), but the relation data will be changed, possibly creating an invalid simulation state. Obviously you would keep this in mind and work around it using custom buffers, but this aspect of deferment is worth noting.

[friflo]

Right, deferring relations changes by using a command buffer make sense.
This justify this feature.
I assume the demand for this feature is very low. So I will prioritize its implementation very low.
It can be added in the future without breaking anything else.