Uh, the JavaDocs are pretty clear. The actual explanation, however, resides in SpongeDocs.
To properly use it, make multiple CommandSpecs for each subcommand, then add them as children to the main /ru command. So for instance:
CommandSpec check = CommandSpec.builder()
.arguments(GenericArguments.playerOrSource(Text.of("player")))
.executor(new RUCheckCommand())
.permission("rankupper.check.self").build();
CommandSpec cs = CommandSpec.builder()
//...
.child(check, "check")
By the way, note the permission change. A permission automatically inherits things that look like child permissions, so granting rankupper.check automatically grants rankupper.check.others as well. It is explained in SpongeDocs that you should append .self to permissions for commands that require an extra permission to operate on others.
Each subcommand gets its own CommandExecutor. You can use lambdas to simplify this.
RUCommand commands = new RUCommands();
//...
.executor(commands::check)
And you would have a method just like execute() but named check(). This way you can fit multiple ones in one class.
In your command executor for /ru check, youâd get the player like so:
Player player = args.getOne("player").get();
If youâre targeting a User instead of a Player, you can use GenericArguments.userOrSource() (which I wrote! :3) instead of GenericArguments.playerOrSource().
A couple of other things:
You know that CommandResult you created? Take a look at the method name. CommandResult.success()
This indicates success. If the command failed, donât return a success, throw a CommandException. Thatâs what theyâre for. The argument for the constructor is a Text, this will be shown to the player. You can also put a boolean after the Text, and if itâs true, itâll show the usage to the player.
Also, for things that show numbers to the player, maybe try returning a more descriptive result.
return CommandResult.builder().queryResult(minutes).build();
This can be used in command blocks and such by mapmakers.
Essentially, the high-level API is about having Sponge do everything for you. Instead of doing a switch statement on a string, make subcommands. Instead of checking UserStorageService, say that you want a User. Instead of returning success at every point, do things relevant to what actually happened.
In fact, you seem to have skimmed over a lot of SpongeDocs. Things such as injection.
@Inject Game game;
@Inject @ConfigDir(sharedRoot = false) File file;
@Inject PluginContainer container;
Assets.
game.getAssetManager().getAsset(this, "default.conf").get().copyToFile(configFile);
Things like that.
Iâd recommend a read of basically all the docs before writing more plugins.
