Repository navigation
ecs: systems with disjoint archetype filters should not conflict on a shared component key #246
Description
Summary
Two systems that both access the same component key conflict by key even when one only writes a different set of entities, and a system that writes row[key] is ordered against every other accessor of that key.
Case (mecs, @adobe/ecs 0.2.4)
deriveCells writes cell on voxels (to follow their position). The hover mark is another entity that carries cell too (a face-marker archetype). Having showHover write the mark's cell by row, as intended, conflicted with deriveCells by key, though the two never touch the same entity (their with/not are disjoint: voxels are [voxel, position, ...], marks are [mark, ...]). So the mark moves by commands.add, a frame later, until drawFaces was ordered after it.
Requested
Treat two systems whose matched archetype sets are disjoint (from with/not) as non-conflicting, even when they access the same key. If the sets can overlap, keep the current rule.
Notes
The check needs only the archetype filters the build already reads.
Activity
krisnye commentedon Nov 1, 2026
Addressed in #250 (Adobe-Firefly/ecs#9), with one correction to the premise.
[voxel, position, …]and[mark, …]are differentwithsets but not exclusive ones: nothing stops an entity from holding both, and a schedule is built without a world, so it can't look at the archetypes there are.Two systems now don't conflict on a key both reach through their rows when one requires a component the other's
notlists. Lookups,up, index and order keys still conflict. For this case,deriveCellstakesnot: [mark]. The conflict error says so where it would help: "…or, if they never match one entity, add a component of one to the other's not."