lack of permission calculation means that child permissions might not have been set correctly, so this might lead to users being able to access things they aren't supposed to.
it also doesn't provide stuff like isOnline() (you had to have a Server reference to get an OfflinePlayer anyway, just ask the Server if the player is online ...) and getPlayer().
to obtain an OfflinePlayer instance you had to have a server instance to start with, which means getServer() is pointless, and also that isOp() and setOp() (which can be removed thanks to the fact that OfflinePlayer is not a Permissible) can be done by just asking the server.
relying on permission subscriptions for this was unreliable (a permissible is not always subscribed to a permission even when it does have it), and also difficult to control (for example there have been various bugs in the past where a Player ended up subscribed to broadcast permissions when it didn't expect to be, thanks to permission recalculation happening too early).
In addition, we might in the future want to have broadcast receivers which are not permissibles (i.e. a more general interface than CommandSender (why does a broadcast receiver need to also be a command sender, anyway?)), which the permission system wouldn't be suitable for.
for example, Player->recalculatePermissions() was not called when a player's op status changed, nor when a permission attachment altered permissions (potential secvuln for broadcasting).
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.
