having them be clean by default makes no sense. It only makes sense for them to be clean if they were loaded directly from disk without any alterations.
Default clean is a footgun.
this information will allow us to correct for any bugs introduced by past versions.
however, we still need to propagate this information to permit actually using it when loading data.
to be consistent, these shouldn't be exposed in the API like this...
I'm not very happy with the whole 'type ID map' paradigm (particularly its lack of static analysis guarantees), but the most important thing right now is to get this stuff out of the API so that plugin devs don't try and abuse it. We're not going to change the whole system days before PM5 release.
while I could implement server-side ability to disable entity movement, I don't think that's particularly useful. However, the intended function of this (disabling client sided AI) is useful, so it makes more sense to rename it to match its functionality, rather than changing its functionality to match the name.
closes#3130
TreeType includes a bunch of stuff that don't have regular saplings associated with them, such as mangrove and azalea trees.
Mangrove has a dedicated propagule block with different behaviour than the others, and azalea trees are grown from azalea blocks, which are solid and have different behaviour to saplings.
We may also want to account for crimson and warped 'trees' in TreeType too, although I'm not sure if those belong there or not.
we can use SubChunkExplorerStatus to decide whether or not to update the local light array reference.
We also dereference some properties into local variables, because dereferencing properties is slow. Indirect property dereferences add an extra performance penalty for every layer.
often, protocol updates are done without consideration for the current world format version. We don't want to require the world support to be updated at the same time, since this might delay updates.
Since light population is required to make a chunk tickable, a chunk may not be tickable for some time if the async workers get backlogged.
The previous version of this system only cached the eligibility result if the result was a "yes", but we can also track it when it's a "no", rather than rechecking it every tick.
This change should improve performance in factions and similar gamemodes, which involve large maps with sparsely distributed players, where each player likely has an independent, non-overlapping ticking chunk circle.
We also ditch TickingChunkEntry in favour of multiple arrays to track the eligibility states. This allows us to avoid rechecking the (even cached) readiness of potentially thousands of chunks. If there are no ticking chunks to recheck, this reduces the cost of the selection process to zero.
This API is much more flexible than the old, allowing any arbitrary set of chunks to be ticked.
These changes also improve the performance of random chunk ticking by almost entirely eliminating the cost of chunk selection. Ticking chunks are now reevaluated when a player moves, instead of every tick.
The system also does not attempt to check the same chunks twice, leading to further improvements.
Overall, the overhead of random chunk selection is reduced anywhere from 80-96%. In practice, this can offer a 5-10% performance gain for servers with sparsely distributed players.
I decided to scrap the max schema ID stuff, since it just adds extra places to forget updating. Instead, it's better to use minor version locks and version metadata, as we do for BedrockData and BedrockProtocol.
