Commands

Warning, there's a high chance the below is outdated. It'll be updated soon.

The command API in RPF is simple and intuitive, providing an extensible system that can be integrated into many different types of user interaction. There's two important things in the command system, handlers, and the commands themselves.

Handlers

Multiple handlers are a necessity for interaction-type specific commands. For example, console commands and commands inputted through a game's chat. You may want a stop command in the console, but having such a thing available to ingame users (even with the permission system) could be devastating, therefore, multiple handlers.

Handlers can be created via the AccessManager, which can be gotten via an injection.

// get an instance of AccessManager
@Inject private AccessManager accessManager;

// make the handler
accessManager.newHandler("handler", injector);

Notice it needs an instance of injector? That means ideally, you'll only be making handlers in startup registerables, where an instance of injector is readily available.

Commands

There's two things to do with commands. Making them, and running them. Running them is pretty easy, and if you're using the premade command handlers, like JDA, Bukkit, or Console, you don't even need to worry about this. Start off with getting an instance of AccessManager, the same way as shown in the Handlers section above. You can then invoke:

accessManager#processCommand(String commandHandler, User user, String message)

The commandhandler is the handler you want to attempt to process this command in. User should be your implementation of a user (or the ones provided by whatever modules you're using), and the message. The message will be the entire raw input of the user, bundled together, including the command prefix, the command itself, and any arguments.

Making a command is a little less trivial. First, create a class that looks something like this:

public final class ExampleCommand extends BaseCommand {
    public ExampleCommand() {
        super("example");
    }

    @Override
    protected boolean execute(User user, String[] args) {
        user.sendMessage("Example message");
        return true;
    }
}

The super constructor should be populated with the command instead (the text after the command prefix, but before the arguments). The execute method will return a boolean, which signals whether a usage message should be sent. If it returns true, no message will be sent, if false, a usage message will be sent.

Commands also have a plethora of customizable metadata, currently including handlers, default command, description, usage, and permissions. All of which can be set by accessing the options field, and using the functions provided.

public ExampleCommand() {
    super("example");
    options
                .handlers("console")
                .description("An example command.")
                .usage("")
                .permissions("application.default-set", "application.example")
                .def(false);
}

This example shows all the functions being set, but remember, you don't have to set all of them. Every field has a default, only set the ones you want to set!

Handlers:

• Which handlers should this command be stored in. By default, the command will be runnable in all handlers.

Description:

• A description for this command, ideally keep it short so it fits on one line. Default usage of it is in the help command.

Usage:

• A message sent when false is returned in execute, is also included in the default help command.

Permissions:

• A list of permissions the user needs to execute this command. No permissions is default.

Def:

• Should this command be ran when no other command is specified after the command prefix? This is useful if the command you're making is a help command.

On startup, RPF will scan the package for all command classes, and add them to their respective handlers.