feat: minecraft brigadier argument types

[Grabsky]

Lamp currently supports arguments provided by Brigadier library directly. There are, however more Minecraft-specific arguments included in game internals. All of them are handled by the client to support completions etc. (see wiki)

They can be accessed with a bit of reflection or NMS on supported platforms. Do note there is a Paper PR (PaperMC/Paper#6695) open to expose them directly to the API which may, or may not be merged in the future.

Notes

• Some existing arguments would need to be handled differently to mimic their brigadier parser behavior.
  • Lamp uses StringArgumentType for String which expects validation (see this)
  • EntitySelector<T> should refer to internal minecraft:entity type to support rich client-side completions.
• Supporting some arguments (eg. minecraft:vec2 and vec3) could be a bit hacky and would most likely require internal changes.

Thoughts

Since that have more side effects than it sounds, I think that addition of BrigadierCommandHandler (or similar) is necessary. This would keep current users unaffected by these changes and also make brigadier easier to maintain.

Sponge

I know nothing about Sponge and can't really suggest anything in that regards. I can only say that since all (minecraft) platforms can use Brigadier, maybe a new module structure is needed. (example)

MinecraftCommandHandler<T> extends CommandHandler<T> { ... }
BrigadierCommandHandler<T> extends MinecraftCommandHandler<T> { ... }

MinecraftCommandHandler<Bukkit> handler = ... // for simple commands
BrigadierCommandHandler<Bukkit> handler = ... // for brigadier commands

MinecraftCommandHandler<Sponge> handler = ... // for simple commands
BrigadierCommandHandler<Sponge> handler = ... // for brigadier commands

[Revxrsal]

Lamp already uses some reflection (through commodore) to access custom Minecraft argument types, EntitySelector being one example. Unfortunately, as you pointed out, arguments like Vec2 and Vec3 are not supported by the nature of Lamp, therefore they could be challenging to add, and simply registering them would serve no purpose.

[Grabsky]

This is super weird because last time I tried, I couldn't get EntitySelector<T> to play nicely with completions. I'll try it once more in the coming days since it's most likely an issue on my end. Thanks for pointing that out!

arguments like Vec2 and Vec3 are not supported by the nature of Lamp, therefore they could be challenging to add

That's totally understandable, their syntax is pretty complex and could be complicated to handle, I agree.

Although, what do you think about drawing a line between Bukkit arguments and Brigadier arguments? They're both different in some ways and sometimes you want them to be handled differently from each other (like the String one I've pointed out before). I can't really think of a good structure for that stuff since I don't know Lamp source much.

I'd really like the ability to override existing, or even register my own brigadier argument handlers with a type reference for the client (eg. brigadier:long or minecraft:message)

[Revxrsal]

Should be fixed. Thank you for the report.