This function is not declared in any useful places (like the CommandSender interface) and it is not present in Player (!!!). Additionally, an is-player check is better done with an instanceof so that type safety is enforced and IDEs can give auto-complete.
This is a BC break, but this is such a pointless function that it's probably not even worth mentioning.
This is completely unnecessary and adds extra complexity for no good reason. Maybe it was used historically, but nowadays it is only used to identify players to send async-prepared batch packets to.
There are two alternative ways to do that:
1. use spl_object_hash() as the targets array in CompressBatchedTask
2. use ServerScheduler's object storage to retain references to the Player[] array.
I've opted for the second method.
Removing these identifiers allows great code simplification in removePlayer() and removes the need for those old stupid hacks.
This also includes a backwards-compatibility break by removing the $identifier parameter of Server->addPlayer().
https://bugs.php.net/bug.php?id=75992
When plugins do time-limited bans and users enter stupid time values, a shitty bug in ext/date gets triggered, but only when reading the ban entries from disk. DateTime->format() is able to produce formatted strings which have more than 4 digits in the year, which are then considered invalid. This works around it by trying to parse a formatted version on the fly to ensure that it is valid.
This also cleans up and improves ban list loading and handling.
This cleans a lot of mess out of the bootstrap file, and also has the added bonus that threads which do not inherit functions can now get access to them by autoloading Utils.
Currently an ItemBlock is created for every Block requested, but this will need to change in the future (for Anvils because they have stupid bitshifts on the meta instead of a nice bitmask). This allows registering items in the ItemFactory with IDs lower than 256 and having them recognized.
This allows retrieving the name of an item without the custom name being plastered over the top. This will also allow weird things to have special functions for their names.
This convention is used throughout the code to allow plugin developers to alter the behaviour of the event. In this case, it would instead produce unexpected behaviour when the event is not cancelled by a plugin.
