This decouples Command from CommandMap, and moves the burden of tracking registered
aliases to CommandMap. This allows lots of simplification, and also solves a few
weird usage message issues.
- Active (registered) aliases are now tracked via CommandMapEntry
- Commands overriding other commands' aliases now update the original command's registered alias list properly
- Command alias lists now include prefixed aliases
- Prefixed aliases are now included in command data provided to the client
- Server-side /pocketmine:help is now visible on the client
- Permission testing can now provide context that's more relevant to the command invocation - e.g. if a user doesn't have /time set permission, it'll now show a more specific message where previously it would just show that the permission for /time was denied
- User-specified label is now used for permission messages instead of command name - this is more consistent with user expectations
- /help can now see prefixed aliases
- Removed magic alias registration behaviour for VanillaCommand that I don't think anyone expected
- Aliases are now provided to CommandMap via register() parameters, instead of being retrieved from the provided Command
- Command->get/setAliases(), get/setLabel() and getName() are removed
- Command->getName() pushed down to PluginCommand, as it's only useful for CommandExecutors as a command ID and shouldn't be used anywhere else
This function adds "base" format to a string. The given formats are inserted directly after any RESET code in the sequence.
An example of where this is needed is in the logger.
Without this change, the following code:
$logger->notice("I'm a " . TextFormat::RED . "special" . TextFormat::RESET . " cookie");
causes the "cookie" part of the message to show as grey, instead of the expected aqua for NOTICE level messages.
There are also many workarounds for this problem throughout the server, mostly in command outputs, being forced to use WHITE instead of RESET to avoid breaking the logger output.
this resolves many security issues, as well as removing a ton of boilerplate code.
It may be desirable to react to permission denied; this can be done by overriding Command->testPermission(), or by using setPermissionMessage() to set a custom permission denied message.
this makes translation usage much more statically analysable.
The only places this isn't used are:
- places that prefix translations with colours (those are still a problem)
- places where server/client translations don't match (e.g. gameMode.changed accepts different parameters in vanilla than in PM)
