this is pretty much always going to cause unexpected behaviour, as most execute() implementations don't expect empty strings, and it can also pad the args with dummy entries, breaking argument count requirements (e.g. aliasing say and using the alias with no arguments will confuse the target command).
Instead:
- Drop arguments that cannot be resolved (leave them unspecified)
- If they are at the end of the argument sequence, this is OK - it will behave the same as if some optional arguments weren't specified.
- If they are in the middle of the argument sequence, this will generate an error - this is preferable to having the target invoked with an empty string, which might cause unexpected behaviour.
fixes#5379
getName() essentially serves as an ID for the command for CommandExecutors. It has no other sane use case.
Since it's not unique (multiple commands with the same name may be registered, and the fallback alias will be used on conflict), it cannot be used for array indexing. It's also not correct to use it for any display purpose, since the command may not be able to be invoked by its 'name' if there was a conflict.
There is an open debate about what to do with getName() and the wider CommandExecutor ecosystem, but that's a topic for another discussion.
closes#5344
This allows plugins to modify the entity via setters in EntitySpawnEvent without their changes getting overwritten by setter calls directly after the 'new YourEntity' statement.
As well as benefiting plugins, this also clears a path for a BC-breaking change in PM5 (to have the programmer use addEntity() to spawn entities, instead of the constructor doing it, which will improve on a number of data handling aspects).
fixes#4973
This targets next-minor because it has some side effects on plugins that depended on the old behaviour, such as VanillaHopper, so it's not suitable for a patch release.
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 has a number of implications:
- Console command outputs are now (obviously) not logged. This is consistent with every other type of command sender, be it RCON, players, or anything else.
- The assumption that the console command sender must be able to see the logger output is now broken, since the command sender can receive output separately from the logs.
In the future, it might be desirable to send the console command output to stderr instead of stdout, so that stdout can be silenced while still allowing commands to be used.
closes#2543
