You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason this happens is because disabled components are still stored in the same array as enabled components. Each array is made available once to the system, and so when you have a query with an optional component, you will get a pointer to that array from ecs_column, even though some values in that array are disabled.
I agree that this is not ideal. To fix this, queries that iterate an optional column with disabled values should iterate the column twice: once for entities with enabled values and once for entities with disabled values. In the latter case I could make ecs_column return NULL, which would make this behavior transparent for the iterator.
FYI it's not pressing for me, just saw the change & thought it might be better for a case I have. I'd say in the short term maybe just a note in the docs about it would help.
This has been fixed in v4. When a query has an optional term and iterates a table where a component is toggled, it will first return the entities with the component, and then the entities without the component.
Describe the bug
[edit] I was wrong in thinking the example was working - I was checking the wrong thing.
I'm not sure if this is intended behavior or not. If I modify example 50 to add an optional component to the system like this:
The result is:
I would expect the 2nd run to include
e2: no position
.Is this the expected behavior when disabling components? I was assuming they'd act the same as
ecs_remove()
in this case.The text was updated successfully, but these errors were encountered: