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.
there are some complications with coral plants due to the fact we're stuck with R12 worlds right now - and also coral fans are a major pain to implement due to how messed up the metadata is.
longer term I want to rip this crap out completely, but right now this provides minor maintainability benefits, while also making it slightly less nasty to deal with other containers which animate their blocks, such as barrels and shulker boxes.
closes#3910
the existing naming was misleading, and many plugin devs assumed that it returns an exact match. However, this is not guaranteed, and it's possible for two different players to match the same prefix.
- There is no defined behaviour for what happens when multiple players can equally match a prefix (e.g. 'fr' could match 'fred' or 'frog' equally, because the name lengths are the same)
- A prefix might match a different player at a different time (e.g. 'fr' could match 'freddie' before 'fred' joins, after which it will match 'fred' instead)
With these flaws in mind, it's better to break compatibility on this to make the intent more clear, and to make plugin developers reassess their usages of this method. In most non-command use cases, they should likely be using getPlayerExact() instead.
we only ever need the first entry, so there's no point storing all of them. In addition, the field is private, which guarantees that nothing else needs the array either.
This also fixes phpstan/phpstan@c50650c5dd.
