this allows chunks locked for population to be modified. If the PopulationTask detects that the chunk was modified during the onCompletion(), the result of the population will be discarded and rescheduled, so that it includes user modifications.
This reverts commit a5418a019d.
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.
instead, just ungate this and allow the provider to decide what to do.
Any chunk that contains entities or tiles is already always considered dirty, so the only thing the flags are good for is flagging chunks that previously had tiles and/or entities but no longer do.
In those cases, it's just removing keys from LevelDB anyway, so it's already very cheap.
Avoiding these redundant deletions is not worth the extra complexity and fragility of relying on flags to track this stuff.
this makes more sense overall from a reader's perspective.
and also provide a rug-jerk for any idiots using World->close() when they aren't supposed to? ....
a non-generated chunk is now always represented by NULL. This forces the case of ungenerated chunks to be handled by all code, which is necessary because ungenerated chunks cannot be interacted with or modified in any meaningful way.
in cases like PopulationTask it makes more sense to store the coordinates separately where they can be stored more efficiently (once instead of 9 times)
In addition, PopulationTask shouldn't need to serialize an empty chunk just to copy coordinates.
I've made changes like this in other areas already in preparation for the day when chunks no longer contain their coordinates, so this brings us one step closer to that goal.
this allows injection of arbitrary ChunkManagers into a single Generator instance.
The objective here was to remove the requirement to cache a SimpleChunkManager instance in worker-local storage, because that requires that the chunks it stores be manually removed to avoid memory leaks. However, there are some other obstacles, primarily the worldHeight which is not retained anywhere else.
this restores SimpleChunkManager's behaviour to PM3, removing the need for GeneratorChunkManager (although I'm dubious whether SubChunkExplorer makes any sense in there any more now that we have morton in the mix).
non-populated chunks shouldn't be light-populated anyway, but in some cases they are (bug or plugin interference).
chunks which were already populated might get modified by adjacent chunk populations, which should invalidate their lighting because generation doesn't track which blocks were changed, so the whole chunk should be recalculated.
this new form allows skipping some useless checks during sky light calculation and also allows getting rid of the last hard dependency on core Block classes.
We're getting real close to native light now.
