these methods have better pathways through Server directly.
Also, setBanned() does not allow customising the reason for banning or the duration, nor does isBanned() account for IP bans because the code is so old ... better to force dependence on a central code path to avoid these inconsistencies.
I want to do the same thing for OP, but that's a separate problem due to its effects on the permission system.
this method has an explicit dependency on permission subscriptions, which I plan to eradicate.
The method's functionality can be replaced using Server->broadcastMessage() with a custom recipients array.
Bukkit CCC at its finest... what the fuck this was doing anyway I have no idea
an addChild() method would have made far more sense, especially considering that addParent() doesn't actually mutate the child.
it's now possible to cancel the banning by cancelling PlayerKickEvent.
In addition, the disconnect message will now properly explain why the player is banned instead of just saying 'You have been banned',
and also banned-players.txt will show 'Died in hardcore mode' as the reason instead of being completely blank (seriously, we couldn't tell the difference between real bans and hardcore bans????)
this is an impressively dumb idea.
the playerdata is not used here in any capacity so it doesn't make sense to load it, especially considering that it takes a significant amount of time.
I think we should probably get rid of this considering the potential for inconsistencies within a chunk, but not retaining this is a bug nonetheless, even though it doesn't have any effect in PM itself since we always use BlockLegacyIds << 4 as the empty block ID.
so, this is only really aiding (ab)use cases which weren't intended anyway ...
this better describes the purpose, which is to identify air.
though, it might make more sense to make air just always have zero as air's runtime ID, since this parameter is apparently making plugin devs think that this is suitable to fill a chunk with a specific block ...
closes#3907
this reduces the impact of compression on the login sequence by about 90%; however, since compression only accounted for about 30% of said overhead at most, it's not really a massive difference.
