we already had this anyway, and it's already being reflected into.
Instead of DevTools checking for FolderPluginLoader instances, it
could just check if the file is a directory instead.
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
it never occurred to me that this was misleading until I read some Devin documentation,
noticed that Devin misunderstood was the class was for, and then realized actually
Devin understood correctly, and it was the name of the class that was wrong. Funny
how that happens...
I want to do the same for items, but items are going to be a pain in the ass.
For items there are multiple possible entry points and all of them will need to be checked:
- dropped items
- inventory contents
- lecterns
- item frames
I don't see a good way to deal with all these. We can't check for registration in the constructor
because we need to fully construct the item in order to register it.
Blocks are also a potential issue in other areas, but setBlock() is definitely the biggest offender.
as written in the comments, it's not reasonable to propagate this limitation, since it
ultimately comes from a shortfall in the Mojang save format, not a limitation of PM's
capability. It's also not obvious how this would be propagated to the likes of setOnFire(),
as this would translate into a max time of 1638 seconds, a value no one is going to
remember.
There's a case to be made for truncating this on save rather than on initial set, but
this is at least better than having Fire Aspect level 1000 cause crashes and whatever
other gameplay logic that would have to work around this stupid limitation.
instead of skipping queues and forcing sync compression as previously seen.
this maintains proper packet order and allows immediate-flush to be used to reduce latency in-game.
Small servers won't notice any difference, but for larger ones it may make a difference, since the buffer time effectively depends on the amount of load RakLib is under.
closes#3325
