Conflict when IComponents from different pools assigned to a single entity

[ghost]

Let's say I have 2 pools named A and B, with 1 component each.

using Entitas;
[A]
public class AComponent : IComponent {}
[B]
public class BComponent : IComponent {}

Code generation creates two arrays, one for each Pool. AComponent will be assigned at index 0 of his pool, BComponent will also be assigned to index 0 in his own pool's array:

    public const int A = 0;
    public const int TotalComponents = 1;

    static readonly string[] components = { "A" };

    public const int B = 0;

    public const int TotalComponents = 1;

    static readonly string[] components = { "B"};

Therefore, it results in conflicts when we want to group by AComponent and BComponent.

        var entity = Pools.a.CreateEntity ();
        entity.isA = true;
        Debug.Log ("Entity isA?: "+entity.isA);
        Debug.Log ("Entity isB?: "+entity.isB);

entity is incorrectly considered as both A and B.

[sschmid]

Yes, that is completely true. You mustn't add components from different pool to the same entity. Different pools have a specific set of components, depending how you attribute your components (e.g. [A] or [B]). When you create an entity with pool A, you can only add components of set A. Personally, I have a pool for UI, Meta Game and the Core Game. Adding Core Game Components to a UI Entity doesn't work, and doesn't really make sense. The different pools work on specific aspects in your application and do not mix.

[sschmid]

The introduction of multiple pools originally was a part of performance optimizations when the amount of components grow. Each created entity will have a array of capacity components count to store the components. To avoid creating large arrays for each entity, it can make sense to have multiple pools focusing on specific aspects like UI or Core Game, and therefore reducing the array capacity for the arrays in the entities. As a result, you run into the issue you described, since components from different pools always start with index 0.

[ghost]

It makes sense performance wise but I wish there was a mechanism at compile time to formally link entity and pool. In the current state, I would have to remember which component belongs to which pool in order to not mix them up in the same entity and introduce a bug. This mechanism should be inexpensive, otherwise it defeats the purpose of separating the pools.

I'll give it some thought and come back to you if I come up with a good solution.

[sschmid]

I already had a few discussions about this topic. In the future the might be some safety mechanisms to address this issue, e.g. generating pools and entities based on the specified pool names. Like: APool and BPool and AEntity and BEntity, only offering code completion for their supported components.

[sschmid]

Fyi, the next release will have support for components with multiple PoolAttributes. Regarding your example of adding AComponent and BComponent to entities in different pools, you can now do this by attributing the components with all the pools they should be supported in

[A, B]
public class AComponent : IComponent {}
[A, B]
public class BComponent : IComponent {}