How should components be updated in the context of prefabs?

[arcanis]

I started by writing something like this:

ecs.system<Body, Position>("PositionSystem")
    .kind(flecs::OnUpdate)
    .each([](Body& bodyC, Position& positionC) {
        auto position = bodyC.BBody->GetPosition();
        positionC.Position = {position.x, position.y};
    });

However I noticed that all entities instantiated from a prefab were sharing the same components. Should I instead use set? Isn't it slow?

ecs.system<Body, Position>("PositionSystem")
    .kind(flecs::OnUpdate)
    .each([](flecs::entity& entity, Body& bodyC, Position& positionC) {
        auto position = bodyC.BBody->GetPosition();
        entity.set<Position>({position.x, position.y});
    });

[copygirl]

I believe you could add AlwaysOverride to Position to ensure an instantiated prefab gets its own copy of a Position component.

Or what I think might also work is to make sure the position term is marked with out or inout to ensure writes go to its own copy, not the shared component. I believe in C++ that would look something like .term_at(2).inout(). (Or .term_at(1) in Flecs v4, since they'll be zero-indexed going forward.)

I remember inout is the default for owned components, but in is the default for shared / inherited components. Though unsure how that's supposed to make sense for components that aren't defined as const in the system.

[arcanis]

AlwaysOverride is exactly what I was looking for, thanks! Would it make sense to support setting them through traits, in the C++ interface? It'd make it easier to collocate the components with their flag specificities.

[SanderMertens]

There are no plans to add C++ traits as a feature to the library. What you could do (and what I've seen other projects do) is wrap component registration in a function where you could check the traits yourself.

[arcanis]

Fair enough - for my own curiosity, is there a particular reason why traits are discouraged in the default interface?

[SanderMertens]

No particular reason, besides that it would be another interface to maintain, and that it could cause confusing behavior (what if user code tries to specialize on an AlwaysOverride trait, but it wasn't specified as type trait).