3 is absurdly small. 8 is a more realistic estimation of what the average player's render distance will be (it's also the default server.properties limit).
3 doesn't even fill the default spawn-radius setting, meaning that delays during player connection would occur anyway due to generation.
this makes PermissionAttachment more and more like Permission, except that it doesn't have a name.
Right now, the only value of this API change is that it allows breaking references to dead Permissibles, but in the future it should be possible to reuse a single PermissionAttachment on multiple Permissibles.
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.
