grab entity pair components un system term ?

[sigzegv]

I didn't found any examples nor documentation about that, but how could I grab a pair with system terms conf, something like :

    ecs_entity_t e = ecs_new_id(ecs);
    ecs_set(app->ecs, e, position_t, {});
    ecs_add_pair(app->ecs, e, controller_t, ai_t); // one kind of controller

    ecs_entity_t e2 = ecs_new_id(ecs);
    ecs_set(app->ecs, e2, position_t, {});
    ecs_add_pair(app->ecs, e2, controller_t, input_t); // another kind of controller

    ecs_system(app->ecs, {
        .entity = ecs_entity(app->ecs, {
            .name = "UpdateSystem",
            .add = { ecs_dependson(EcsOnUpdate) }
        }),
        .query.filter.terms = {
            { ecs_id(position_t)},
            { ecs_id(controller_t)}, // I don't know what to do here
        },
        .query.filter.instanced = true,
        .callback = update_system_cb,
    });

Or is there another clean way for that ?

[copygirl]

How to deal with relationship pairs is explained in the Queries section, specifically Pairs.

If you want to match a specific pair:

.query.filter.terms = {
    { ecs_id(position_t) },
    { ecs_pair(ecs_id(controller_t), ecs_id(ai_t)) },
},

If you want to match every controller:

.query.filter.terms = {
    { ecs_id(position_t) },
    { ecs_pair(ecs_id(controller_t), EcsWildcard)) },
},

This will match the same entity multiple times for each wildcard matched.
And you can get the matched target like this from the iterator:

ecs_id_t ctrl_pair = ecs_field_id(&it, 2); // index = 1 is position, 2 would be the controller pair
ecs_entity_t second = ecs_pair_second(world, ctrl_pair);

Hope this helps.

[sigzegv]

That's fine, sorry I thought that those terms weren't suitable for systems, I didn't understood correctly the doc.

[sigzegv]

ok so I actually supposed I could do and ecs_get in my system callback, seems to not be the correct operation, knowing that I already defined the input_t struct globally (just in case) :

void
update_system_cb(ecs_iter_t* it) {
    position_t *pf = ecs_field(it, position_t, 1);
[...]
    ecs_id_t pair_id = ecs_field_id(it, 3); // get the pair ID
    ecs_entity_t eid = ecs_pair_second(it->world, pair_id);

    printf("%s\n", ecs_get_name(it->world, eid)); // fine, returns input_t
    
    const input_t* i = ecs_get(it->world, eid, input_t); // segfault ?
}

[copygirl]

The current call to ecs_get would get the input_t component of the input_t entity. Unless that is a singleton component, I don't think that will work. I'm not entirely sure what you're aiming for by creating a relationship pair like this.

Relationship pairs can hold data if one of the elements is a component.
Assuming controller_t is just an empty type, and input_t has a value, you can either do the following:

const input_t* i = ecs_get_pair_second(it->world, eid, controller_t, input_t);

.. or, if the relationship has a known type in the query (you're not using a wildcard), it will become one of the accessible fields:

void update_system_cb(ecs_iter_t* it) {
    position_t *position_field = ecs_field(it, position_t, 1);
    input_t    *input_field    = ecs_field(it, input_t, 2);
    [...]
}

However, it looks like you're using a pair for no particular reason. Are you sure you don't just want an input_t component on the entity? What purpose do component_t and the relationship pair serve here?

[sigzegv]

You're right I'm still not really sure about my design, my idea was to hold a pair for an entity that must be handled by a controller, either an input controller or an AI (a non human input handler), or anything else.

So in my first idea, to avoid having multiple mechanics in a single component, I use a pair that defines the master type (controller_t) and the data type as the second in the pair (anything that will have custom rules as input controller will be second). Of course using 2 systems filtering explicitely the pair is like having a single component, but in other way, with that pair I could find easily any entity that is handled by any controller type, and handle its rules with the associated pair. Maybe there's a better design for that, I don't know yet.

[copygirl]

You can have both a controller_t component that holds common data, as well as a input_t or ai_t that holds data related to only input or AI. Then create a system that matches all entities that have controller_t and input_t, and a separate system that matches controller_t and ai_t. These systems could take information from input or simulate AI, and fill controller_t with information. A third system could then match only controller_t that then, for example, moves the entity around, without needing to know how that controller data was filled.