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
Entity.teleportTo is largely stable and correct. CraftEntity.teleport,
however, still cannot properly handle cross-world teleportation. Fix it
to defer to the better code in core Minecraft.
Commit c576054539790bdeb35285f62863d74b48c0782d removed the chunklist collection stored in ChunkProviderServer, however it has been partially restored in some places by 7e1ac0a77129b169704c1e222ff2deb3ab6cd2d2. As not all references to this were restored, this has caused the chunklist and chunks collections to become out of sync, resulting in a memory leak.
There is very little reason to keep track of Mineshafts as the only persistent behaviour within them is through the use of mob spawners, which are of course stored within the map itself. As such we can disable them from being saved, indefinitely, until there is reason to do so.
This brings back the option that the Spigot version of netty saw. By default Netty will try and use cores*2 threads, however if running multiple servers on the same machine, this can be too many threads. Additionally some people have 16 core servers. If 32 Netty threads are allowed in this setup, then the lock contention, and thus blocking between threads becomes much greater, leading to decreased performance.
Useful for larger servers who want a nice performance boost at the expense of a little bit of gameplay mechanic changes. I believe this brings the mechanics of zombie vs villager back in line with 1.5.
Now we maintain a new list of blocks to replace with ores in engine mode 2, to ensure that we only update when players mine blocks that are potentially not an ore. We could perhaps even elimate this slight lag from mode 2 by reducing the need for calling update(x,y,z)
As of 1.7, Mojang added a check to make sure that only chunks which have been lit are sent to the client. Unfortunately this interferes with our modified chunk ticking algorithm, which will only tick chunks distant from the player on a very infrequent basis. We cannot unfortunately do this lighting stage during chunk gen as it appears to put a lot more noticeable load on the server, than when it is done at play time. For now at least we will simply send all chunks, in accordance with pre 1.7 behaviour.
This is a lightly tested build. You are encouraged to keep backups at all times. Please attempt to report all issues to IRC. The following features are intentionally missing from this build and will be added as soon as humanly possible.
- BungeeCord IP forwarding
- Firing of AsyncLoginEvent in offline mode
- A few custom kick / other hardcoded messages
As always this build comes with no warranty.
Thanks for your support.
~md_5
