Command creation

There are two ways of creating commands:

• Implement the CommandCallable interface.
• Use the parametric builder and annotate methods of a class with @Command.

This page describes the former way, but if you are interested in using annotations, read about the parametric builder. Nevertheless, this page is good reading regardless of what you do because even the parametric builder merely generates its own dynamic CommandCallables.

CommandCallable

The interface currently defines three methods:

• call(arguments, locals, parentCommands): Execute the command.
• getDescription(): Return an object that describes the command:
• testPermission(locals): Given a command locals object, test if this command can (likely) be called.

The arguments do not contain the called command. For example, /tp eduardo timothy would result in arguments equating to eduardo timothy. That said, if the command wanted to see what the parent command was, it could check parentCommands and see that it is ["tp"]. If this command was a deeper sub-command (such as under an "admin" command), then the parent commands array would look like ["admin", "tp"].

The locals argument is an instance of command locals.

The getDescription() call needs to return a Description. More information is about what you could return is explained in the Descriptions page

Lastly, the purpose of testPermission() is for a quick cursory check. While Intake actually doesn't do anything with this data (as of writing), it will come in handy if you want to implement a /help command and you don't want to show commands that the user can't use (see Implementing help).

Remember, the contents of the locals object is up to you. You may want to put the caller of the command in it.

Parsing arguments

If you want to make use of flags (-f value) and more advanced constructs, see the page on argument parsing.