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
{{ message }}
This repository has been archived by the owner on Jun 1, 2022. It is now read-only.
As per #175, mutating the query results array while iterating upon that array (e.g. via entitiy.removeComponent(), or entity.addComponent() in a Not() query) can result in unexpected behaviors, and at the moment it's easy to stumble into those mutations accidentally.
An alternative to documenting the work-around as suggested in #163, a custom object could be used for query results to work around the behavior by substituting iteration methods which iterate in reverse order by default, perform a .slice() prior to iteration, or some other means.
As @fernandojsg mentioned on Discord, any such solution should be benchmarked (pending #178) as using custom objects in place of arrays might come at a high cost.
The text was updated successfully, but these errors were encountered:
Hey! Just wanted to bump this. I've been working in ecsy for a few months now and I've run into this multiple times. It's really easy to forget and I think many new users will get tripped up by this.
IMO reversing iteration is just trying to hide the inherent complexity that queries are tied to entity mutations. There are all sorts of other issues that can come up as well, so we just need better ways of being able to think about that complexity rather than trying to hide it. Unity largely does this by making these mutations happen at more explicit points in the frame using EntityCommandBuffers, I think a similar abstraction could make sense and could also get rid of some of the weirdness and confusion around deferred entity removal.
After thinking on it more over the last few weeks, I've come to agree with @netpro2k's assessment - virtually any implementation adds unnecessary obfuscation.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As per #175, mutating the query results array while iterating upon that array (e.g. via
entitiy.removeComponent()
, orentity.addComponent()
in aNot()
query) can result in unexpected behaviors, and at the moment it's easy to stumble into those mutations accidentally.An alternative to documenting the work-around as suggested in #163, a custom object could be used for query results to work around the behavior by substituting iteration methods which iterate in reverse order by default, perform a
.slice()
prior to iteration, or some other means.As @fernandojsg mentioned on Discord, any such solution should be benchmarked (pending #178) as using custom objects in place of arrays might come at a high cost.
The text was updated successfully, but these errors were encountered: