this allows plugins to request this data whenever they want it (e.g. to save offline any time they want, instead of being confined to the server autosave interval).
this exception is only thrown if the player is closed, which is already unexpected in the first place and will actually crash if it's not kosher. This prevents doing stuff like saving players during onDispose(), which crashes the server if a player is disconnected due to flagForDespawn().
requestChunkPopulation() respects the queue size, orderChunkPopulation() does not.
requestChunkPopulation() should be used for non-essential generation (which mainly includes generation for player use).
orderChunkPopulation() should probably be used by plugins.
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.
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.
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.
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????)
player knockback silently depended on the chunk packet broadcast system sending the player's motion back to itself, which broadcasting to hasSpawned will not do.
This change was made after exploring turning this into a permission. It occurred to me that this feature is entirely superfluous because it's non-vanilla, can be done by plugins, and is usually considered as a bug. In addition, disabling this behaviour required third party code just for this one thing because it was not able to be managed by a permissions plugin.
Instead, it's better to produce a plugin which implements this behaviour if it's desired, by making use of SignChangeEvent and PlayerChatEvent/PlayerCommandPreprocessEvent.
close#3856, close#2288
The motivation for this is to prevent passing a dynamic argument to cancellation, which in almost all cases is a bug in user code. This same mistake also appears in a few places in the PM core (as seen in this commit), but in those cases the mistakes were mostly harmless since they were taking place before the event was actually called.
closes#3836
this should never happen, but it could have happened if there was a bug in the code for some reason.
Readers note: I know this looks lik I'm undoing the changes I just did, but what really happened is a name change.
