it doesn't make sense to have to parse the string every time we want to verify permissions, nor to expect that people will somehow know to use ; to separate them without it being documented anywhere...
I'm not quite sure this is the best way to enable such functionality, but it's already used for some other stuff, so I'm not too worried for now.
This allows the following commands to have their usage limited to self or others:
- /effect
- /enchant
- /gamemode
- /give
- /spawnpoint
- /teleport
- /title
I envision this being useful for creative mode servers, and test servers such as test.pmmp.io.
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 isn't specced up with some of the finer features of LegacyStringToItemParser such as metadata parsing, but those are still a work in progress (and probably limited to specific items like durable stuff).
The goal is to unbind these aliases from legacy internal IDs, while also providing a nice flexible way for plugins to add their own items and aliases to the existing system.
This system allows mapping a string to any item at all, irrespective of state, internal IDs, or any of that nonsense. This means it's finally possible to have stuff like lapis_lazuli and bone_meal aliases in commands.
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)