Doraku
Fixes and improvements
Oh and, those changes are actually tested by me and my colleagues for some time, the reason commits marked as new is because i did a bit of clean up today before making this PR and basically rewritten commit history in my fork.
I have no great desire to rewrite all my systems classes constructors to manually define false useBuffer parameter. Wiki clearly states rules how to work with entities within basic system ancestors Update method. See no reason to use worse performance case as default behavior. If I need safe context, then I set useBuffer manually. But that's my personal opinion.
The thing with no useBuffer param is that when it does go wrong, trying to detect it is a real pain. So chances are, you wont even know you need this safe context.
What's more, the potential perf gain doesnt even matter most of the time, because your system has to have a very light update to care about such overhead and do so in single-thread (useBuffer is not used in multi-thread, after all), on a great number of entities. That's the only situation where you might reasonably want to disable the buffering, but such systems are not that common in my experience. Unless you trying to write game engine of your own or something, with DefaultECS as the basis.
Debugging ECS is really painful, totally agree on this. But buffering systems updates isn't only thing that matters. We're developed a bunch of instruments for debugging, and each time we're forced to think out something new(eg. last time I wrote wrapper for ReanOnlySpan which I return from EntitySet::GetEntities() and which tracks changes made to EntitySet while ReadOnlySpan is enumerated - that solves all my problems with incorrect Updates within my systems). UseBuffer situations could be detected by switching default parameter value to true - if that solves the problem, then definitely some of your systems violates rules.
@Doraku So i take it this repo is abandoned since there is no reply after a whole year?