this has the most reliable behaviour, because some stuff like respect/validation likes to include files unconditionally which declare functions that are already declared, which breaks due to the lack of function autoloading.
this was used for 2 things:
- to notify parent permissibles on recalculate permissions (not needed anymore thanks to callbacks)
- subscription to chat broadcast permissions (now handled separately, again using callbacks)
therefore, it's no longer needed for PermissibleBase to reference its parent, meaning that we can have one less circular dependency in our lives.
since the only way to obtain PermissionAttachmentInfo via the API is from the Permissible API, it makes zero sense to ask the attachmentinfo for its permissible, since we obviously already had it to be able to get the info in the first place. Therefore, this is just another useless reference stopping Permissibles from being garbage-collected.
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.
