Sorry if anyone wrote one already, remove the return type please.
Really don't want to bump version when very low chance anyones using
this system yet.
This completes and fully enables a new feature called "Conditions"
We already had some forms of conditions built into @Flags such as
on the Player for itemheld.
However, letting end users add additional restrictions to existing context
handlers such as players is not possible without redefining the context.
That's not friendly nor scalable.
Flags will now be primarily only for controlling how to resolve a context,
and then Conditions will then be the way to validate the context and trigger
a failure if the condition is not met.
Conditions can be placed on Command Class, Methods, or individual Parameters.
```java
@CommandAlias("foo")
@Subcommand("bar")
class FooBarCommand {
@Default
public void onFooBar(CommandIssuer issuer) {}
}
```
Will now pass `/foo bar` to onFooBar.
Previously this required @Subcommand("") which was unintuitive
This adds the ability for plugins to define completion handlers as async safe (not on games main thread)
When they are defined async safe, and ran on a Paper 1.12.2+ server, with a Paper ACF manager,
completions will be handled mostly async, letting you safely do heavier operations in tab completions.
Apparently doing it in the ctor is a different order.
The addReplacements call in CommandReplacements checks registeredCommands in the constructor
This was being called before Bukkit manager even fully loaded, and the registered commands was still null
I don't know why java can't treat this the same code wise....
@Subcommand("list") @Default
public void onFoo(CommandSender sender, @Default("1") Integer page) {}
type stuff will now work with /cmd list 2 and /cmd 2
* 'feature/help' of https://github.com/mrkirby153/commands:
Generify help generation
Rework how help is generated
First revision of help system
Wire up command descriptions
Aikar
