since a while ago, we're anyway just discarding the internal buffer anyway when the packet is repeatedly encoded, so this doesn't serve any advantage anymore.
We do need a system to be able to reuse encoded packet buffers, but right now we're not reusing them anyway.
-1 is a PM-specific thing. Right now there is a hack in the NetworkBinaryStream which prevents this from becoming a problem, but that might not be the case in future.
we can't get the safe spawn location of a set of coordinates if the coordinates are in an ungenerated chunk. This can happen if doing /setworldspawn <somewhere ungenerated> and then having a new player join the server.
this can fire while the player has the inventory window open, because it also gets sent when the player swaps their held itemstack for something new.
We already had a special-case for mouseover with entity ID 0, but since
this isn't just a zero problem, a more general fix suits better
(particularly since we might need to handle the 0 case anyway).
closes#4140closes#4141
If allowFlight was toggled by the server (e.g. due to gamemode change), a race could occur due to network latency where the client could try to enable flight, and then get kicked for cheating.
Since this can happen in legitimate, non-cheating cases, we can't make any assumptions about whether a player is cheating, so instead we just revert it, like we do with every other bad input.
the notify() to flush the buffer might arrive in between the writeLogStream() and synchronized() calls in the thread body, resulting in a deadlock if the logger thread managed to call wait() before the main thread did.
Plugin is the interface by which the server core interacts with plugins, so it should be limited only to the stuff that the server actually uses.
These methods are still provided by PluginBase, so in 99.9% of cases there will be no BC break.
