Table of Contents
Custom commands can be easily defined by creating methods in a class with the given name and the needed parameters. This is supported both for Minecraft and for other platforms as well. In Minecraft, it also comes with automatic tab completion.
Minecraft commands can be defined via custom classes extending ICommand2MC with a @CommandClass annotation. They also need to be registered to the plugin or component. For that, use registerCommand(new CustomCommand()) in the plugin/component (when using ButtonPlugin) or ButtonPlugin.getCommand2MC().registerCommand(new CustomCommand()).
For non-Minecraft commands, you can extend ICommand2 (commands) and Command2 (command handler) and implement Command2Sender (to receive messages). An example of this is in the Discord plugin. To handle commands run command2.handleCommand(new CustomSender(user), fullCommandString).
Command classes
By default, the command name is taken from the class name, removing any Command from it. A command class should look like this:
@CommandClass(helpText = {
"Command name",
"Some information about the command",
"What it does and why"
}) //Usage is added to the end
public class SomeCommand extends ICommand2MC {
@Command2.Subcommand
public void def(CommandSender sender, String someArg) {
sender.sendMessage("You added " + someArg);
}
}
This will create a /some command that takes one String argument and says "You added <arg>". If you run the command without the argument it will display the help text, the first row being the header, and a usage row based on the parameter names. For example:
---- Command name ----
Some information about the command
What it does and why
Usage: /some <someArg>
Subcommand methods
The return type can be void or boolean, if you return false it will display the help text. You can use any simple type (primitives and String) as parameters, and can add more types using command2.addParamConverter(). Plugins are also supported via a builtin param converter. Command2 instances can also be obtained using getManager() from a command class.
You can define optional arguments or text arguments (that can take spaces) and define custom tab completion instead of one based on parameter type. @CustomTabComplete lets you define constant strings while @CustomTabCompleteMethod lets you use a method to figure out what options are available based on previous arguments.
@Command2.Subcommand
public void def(CommandSender sender, @Command2.OptionalArg int index) { // This is /maincommand (or whatever class this is in)
if(index == 0) sender.sendMessage("No index");
else sender.sendMessage("Index: " + index);
}
@Command2.Subcommand
public boolean subcmd(CommandSender sender, @Command2.TextArg String someText) { // This is /maincommand subcmd
sender.sendMessage("someText: " + someText); // Can have spaces
return someText.length() > 2; // Show help text if arg is 2 chars or less
}
@Command2.Subcommand(helpText = {
"Another subcommand",
"You can have help texts for subcommands as well."
})
public boolean another_subcommand(CommandSender sender, @CustomTabcomplete({"enabled", "disabled"}) String enabled) {
if(!enabled.equalsIgnoreCase("enabled") && !enabled.equalsIgnoreCase("disabled")) return false;
sender.sendMessage("You ran /maincommand another subcommand " + enabled + ". What a strange command.");
return true;
} //Subcommands can have multiple words in their names, they should be all lowercase
The path option of @CommandClass can also be used to overwrite the inferred name with a custom command path. This can contain spaces so you can define a subcommand as a separate class as well (if you only define subcommands then the main command will show the subcommands).
Command permissions
You can use the permGroup setting of the annotations to require a chroma.<permGroup> permission to access the command. In addition, all commands get a chroma.command.<commandName> permission. The Command2.Subcommand.MOD_GROUP is provided as a simple way of restricting access.