this causes some breakage to the behaviour of Terminal, and for that reason this is going on 4.0.
Terminal::hasFormattingCodes() will no longer auto-detect whether colour codes are supported.
garbage collection does need to be implemented, but I was looking at this code and found so many fucking bugs I decided it wasn't worth the effort of fixing.
This filters out over 200 invalid states which were previously considered just fine, including zero-width cakes, buttons with broken facing values, furnace/chest with crazy values, and more.
This breaks down the handling of tile creation even further.
- Introduced a static Tile::override() method to allow overriding the construction class for a specific type of chest. This applies to classes as opposed to save IDs, so you can override Chest::class with MyCustomChest::class and it will take effect for any Chest save ID.
- Removed MCPE stringy save ID constants from public Tile interface. These are now only used for creating saved tiles from a stored chunk, and saving them.
- Renamed Tile::registerTile() to register()
- Tile::create() and Tile::createFromItem() now accept a class parameter instead of a stringy save ID.
- Tile::create() and Tile::createFromItem() were changed to throw \InvalidArgumentException on unknown/unregistered tile types. They also now never return null, but always (except in exception cases) return an object which is an instanceof the base class specified.
This allows plugins to more easily control the behaviour of server-full, whitelisting and banning. A message can be assigned for each, with a plugin custom reason taking the final priority if set.
This system solves several edge case problems in the Bukkit version by allowing kick reasons to be combined, so that removing one kick reason will roll back the final reason to the next highest, instead of just allowing the player through completely.
Only one message will be shown at point of disconnection, for consistency with the old behaviour.
The message priority is as follows (for all cases, only if set):
- Plugin reason
- Server full
- Whitelist enabled
- Player is banned
This also brings us one step closer to separating Player and NetworkSession.
Previously the only way to deal with this was to cancel the PlayerKickEvent generated by lack of authentication. Now, plugins can decide whether auth should be required for a specific player. The default is whatever xbox-auth is set to in server.properties.
cc @Johnmacrocraft
I don't know why this would be missing, but in some cases it is, as seen in the crash archive. Whatever the case, we shouldn't be shitting the bed because of this.
