a couple of usages of properties that no longer exist couldn't be migrated.
in addition, this revealed a couple of dead properties in the default file.
this is not an ideal solution (I'd much rather model the configs using classes and map them) but in the absence of a good and reliable library to do that, this is the next best thing.
* World: cache block AABBs directly in the world
this removes some indirection when fetching the AABBs, and also allows the AABB cache to live longer than the block cache.
In local testing this showed a 10-20% performance improvement, but it was difficult to properly measure.
* World: eliminate padding block checks in getCollisionBoxes()
this substantially improves the function's performance for small entities.
The padding of 1 block in each direction was previously necessary to account for blocks like fences, which might have an AABB larger than the cell containing them. However, by tracking this information in the collisionBoxCache directly, we can avoid the need to check this at the expense of slightly more complex code. This reduces the number of blocks checked for a moving item entity from 27-64 all the way down to 1-8, which is a major improvement.
Locally, this change allowed me to simulate 2100 item entities without lag, compared with 1500 on the previous commit.
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.
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.
BlockPlaceEvent no longer extends BlockEvent, since it's now a multi-block event
getBlockReplaced() is removed
getTransaction() is added
to be honest, BlockPlaceEvent should be something like PlayerBlockPlaceEvent...
this simplifies usages of safe spawns, since the caller doesn't need to know which chunks will be needed for the spawn to be selected.
We'll need this in the future, because safe spawns may also get diverted horizontally as well as vertically, which might require loading adjacent chunks as well as the chunk the position is actually in.
in vanilla, it appears to behave as if the player always clicked on the up face if a block was replaced.
In PM, we were still using the original face, which caused bugs when, for example, placing a button next to a wall by clicking on the side of tallgrass. The button would replace the tallgrass, but stick to the wall, instead of placing itself on the ground like vanilla expects.
This may appear unusual to anyone who also happens to implement canBePlacedAt(), since the facing behaviour will be different. However, this behaviour appears to match vanilla, and even slabs (which I feared might break because of this change) work perfectly.
In the future, it may be desirable to pass some other value here, such as null, to indicate that the clicked block is being replaced. However, that's a BC break and therefore outside of the scope of a stable bug fix.
