This reverts commit a5418a019dc2a83210084632130db8ce06f529ea.
The more I assessed this, the more I realized that this implementation
doesn't actually offer any value. Since modcounters don't persist after
chunk unload + reload, they can't be reliably used to detect changes in
chunks without additional event subscriptions.
For the purpose I actually intended to use them for (population task
cancellation) there's a) another solution, and b) modcounts are
unreliable for that too, because of the aforementioned potential for
chunks to get unloaded and reloaded.
For the case of detecting dirty chunks within PopulationTask itself,
they are also unnecessary, since the dirty flags are sufficient within
there, since FastChunkSerializer doesn't copy dirty flags.
In conclusion, this was a misbegotten addition with little real value,
but does impact performance in hot paths.
setPopulated() sets dirty flags on the chunk, causing the autosave sweep
to think they've been changed when they haven't. We now pass
terrainPopulated to the constructor to avoid this ambiguity recurring in
the future.
making this nullable was based on the invalid assumption that global sounds have no position, but it turns out they _do_ still use the position to make the sound come from the correct direction.
in PM4, all blockupdates are buffered, so the old 7x performance penalty that used to be incurred by doing this is no longer a problem.
Also, this actually reduces the overhead of explosions themselves by moving the onNearbyBlockChange() burden off explodeB() and into the main world ticking function.
isChunkGenerated() merely checks if the chunk can be loaded from disk, if it's not in the runtime cache already.
This is pointless in all of these cases, because the check is prefaced by an isChunkLoaded() check, which already limits the possibility anyway. If the chunk is not generated, it'll also be considered not loaded.
this raises false-positives during shutdown if players were online.
The fact that the player entity leans on the World to clean up after it is slightly problematic, but I'm not sure what else to do about it for now.
this allows entities to exist outside of generated chunks, with one caveat: they won't be saved in such cases.
Obviously, for player entities, this doesn't matter.
fixes#3947
this fixes 2 problems:
1) Blocks which set themselves to something else during onNearbyBlockChange() would not receive any block update
2) A memory leak when blocks in unloaded chunks were scheduled for an update.
I'm a little uneasy about this change, because there must have been some reason why I put this at the end of the block and not at the start, but whatever it is, I can't reason about it, and there's reasons not to put it at the end too.
the only reason to use getCollidingEntities() instead of getNearbyEntities() is if you have an entity that may or may not be collidable depending on certain conditions.
Really, I don't think this logic belongs in World at all, but for now it has to stay, because some other stuff depends on it.
