TheyCallMeRyan

Might take a little longer - I ended up finding a bug in this related to workspace.SignalBehavior.Deferred - For some reason, in some cases, an instance will never be passed...

I'm not sure if you want to close this pull request, but the only thing I found was to use CollectionService which works as expected.

Another comment related to the way the new nextItem is implemented - the new version removes the previous hasSeen set to determine if the next value can be returned, so...

Might be worth noting for issue 147 - the warning in the docs that removing entities with world:clear() won't be reported by queryChanged is still valid; this just makes it...

Two possible fixes: 1. Remove the if not willBeDeleted then - this will make size inaccurate until the next commitCommands 2. Add in executeDespawn a check that it's still markedForDeletion...

I'm not sure what people use _size for, I just noticed this while trying to find the indexInArchetype bug yesterday.

As mentioned in the discord, I think the best solution is to include an if archetype == oldArchetype then return Another possible solution would be to prevent this in executeDespawn...

This may have existed in 0.8.4 as well, but the root of the issue is I used world:clear() and expected to be able to continue using the world in systems....

As a side note, once this happens, it forever breaks commitCommands and everything else because commitCommands doesn't table.clear until after all commands have been processed. Might be good to provide...

It might be possible to do something related to setting unique topoRuntimes for each world in Loop; however, I think a better solution might be to have each world store...