CommandAPI
CommandAPI copied to clipboard
v9.3.0-mod
Added a new option: skipListValidation This allows me to use ListArgumentBuilder for complex tab suggestions and simply passing all input so I can do my own validation.
This allowed me to create this command: https://youtu.be/q03_paw9Vzk
Just a note that the command you implemented seems to have similar functionality to the FlagsArgument proposed by #483. Development on that is currently in progress on the dev/command-build-rewrite branch https://github.com/JorelAli/CommandAPI/commit/22c2ffac8b4ac9f3e0ac47f63cbe82c88729e44d.
Also, dev/argument-exceptions #476 currently provides the API for developers to manually suppress the exceptions thrown when the CommandAPI parses the ListArgument.
This latest iteration doesn't work. I tested this command:
new CommandAPICommand("test")
.withArguments(new ListArgumentBuilder<String>("list")
.skipListValidation(true)
.withList("test")
.withStringMapper()
.buildGreedy()
)
.executesPlayer(info -> {
List<String> list = (List<String>) info.args().get("list");
info.sender().sendMessage(Component.text().content(list.toString()).build());
})
.register();
I then executed this command:
/test hello test police
The output I got was [test], the expected result would be [hello, test, police] if the validation is skipped.
This latest iteration doesn't work. I tested this command:
new CommandAPICommand("test") .withArguments(new ListArgumentBuilder<String>("list") .skipListValidation(true) .withList("test") .withStringMapper() .buildGreedy() ) .executesPlayer(info -> { List<String> list = (List<String>) info.args().get("list"); info.sender().sendMessage(Component.text().content(list.toString()).build()); }) .register();I then executed this command:
/test hello test policeThe output I got was
[test], the expected result would be[hello, test, police]if the validation is skipped.
Yeah it's not the most intuitive since the list basically is only good for suggestions. Afterwards you have to use the rawArgMap and it returns everything in one string.
.executes(CommandExecutor { sender, args -> processCmd(sender, args) })
# ...
.withOptionalArguments(
ListArgumentBuilder<String>("values")
.skipListValidation(true)
.withList { info -> buildTabSuggestions(info) }
.withStringMapper()
.buildGreedy()
val values = args.rawArgsMap["values"]
val args = splitStringWithQuotes(values) # split into array and treat quotes as one element
Here's how I used it https://github.com/ArcanePlugins/LevelledMobs/blob/4.0.0-dev/levelledmobs-plugin/src/main/kotlin/io/github/arcaneplugins/levelledmobs/commands/subcommands/SummonSubcommand.kt#L56
Nope, that's not how it's going to work when merged; the List returned has to contain every relevant value. As I said, it would be best to have a separate parsing method when list validation is skipped.
Also, make sure to also update the ListTextArgument constructor so this also can work with this parameter.
I'll probably just cancel this PR and wait for FlagsArgument proposed by https://github.com/JorelAli/CommandAPI/issues/483 since it likely works better and is more intuitive.
I'll probably just cancel this PR and wait for
FlagsArgumentproposed by #483 since it likely works better and is more intuitive.
I mean, do what you want to do, but again, this, despite being a really niche feature, can be useful. It just needs a bit more attention since there are expectations when using the list.
Yeah it's not the most intuitive since the list basically is only good for suggestions.
Also, not true. The list, if validations are not skipped, provides the player or any other command executor with a list of options. The items in the suggestion list are there to tell the user the valid options. The command sender can then choose which of these items should be used (compare the GIF in the ListArgument's documentation page, there the materials are suggested iirc). The list that you then can get in the executor contains the chosen values. If not all values are selected, the list that provides suggestions and the list returned by the argument can be very different in size.
@stumper66 Are you still working on this? If not, it might be better to close this PR since I don't think we want PRs sitting here that are not active anymore.
Cancelling the PR