This is currently set at the Vanilla default value of 5, however initial testing seems to suggest there could be good performance / usability / bandwidth gains by setting it to its maximum value of 32768. Testers are welcome to experiment with this option, beware the placebo though!
Whilst the new behaviour was technically correct as it prevented the possibility of the chunk tick list actually increasing over time, it introduced a few issues, namely the fact that it slowed growth to unreasonable levels, and interfered with the values which server admins have finally tuned, and come to enjoy over the last few years.
If it is absolutely essential that growth be halted and ticking reduced as much as possible, the config option is there for power users.
If we wish to 'fix' this by default in the future, a new chunk ticking algorithm, which actually has meaningful config options should be designed.
The problem here is that MinecraftServer.save(..), will attempt to sleep whilst all pending chunks are written to disk, however due to various and complicated bugs, it will wait for an incorrect amount of chunks, which may cause it to sleep for an overly long amount of time. Instead we will mimic the save-all command in its behaviour, which is both safe and performant.
This fixes the server incorrectly moving the player out of an anvil when touching it on the side. The server used the rotation of the last placed anvil instead the of the rotation of the anvil the player was touching.
Send a Packet103SetSlot to client when a BlockPlaceEvent is cancelled.
Fixes BUKKIT-5284
Currently, whenever a player places a block in a protected area the
equipped itemstack size on client is never updated properly since the
client thinks the block was placed. The reason this happens is because
ItemStack.matches returns true since the server does not decrement stack
size if a BlockPlaceEvent is cancelled. This causes
PlayerConnection.a(handlePlace) not to send the appropriate packet to
client which causes the bug.
Update chest animation after cancelling InventoryOpenEvent. Fixes BUKKIT-1440
Currently if a plugin cancels an InventoryOpenEvent for vanilla chests,
the chest animation for clients is stuck in the open state since
IInventory's closeChest method is never called. To fix the issue, closeChest
is called before exiting the display GUI method.
More info can be found here
https://bukkit.atlassian.net/browse/BUKKIT-1440
