Improve help output for commands split over multiple base commands
Fix help last page detection
Fix missing argument on Player Context Resolve
Expose registered root commands
* annotations:
Default empty descriptions
fix annotation lookup
Fix Bukkit Description being null, supply usage/description to Sponge/Bungee
fix looking up annotations without value methods
More cleanup and refactoring
move annotation lookup methods into their own file to declutter class
clean up code more, break out methods
Refactor all annotation lookups in prep for processors
* Add support for per issuer locale in Sponge and BungeeCord
* Added Optional<UUID> getUniqueId to CommandIssuer
* Added update task and delayed join listener in BungeeCord
* Added settings change listener in Sponge
* Moved setLocale method up to the CommandManager to remove the
amount of duplicated code
* Remove Optional usage
* Remove player terminology in core
* Added support for loading message bundles from other ClassLoaders, and made the Bukkit & Bungee locales attempt to load from the ClassLoader that ACF is apart of, and the ClassLoader that the CommandManagers plugin belongs to
* Added the ability to add/register a ClassLoader to be scanned for Locales. The Locales automatically adds its own ClassLoader to the list, and the Bungee, Bukkit and Sponge implementations automatically add the plugins ClassLoader to the list
* Fixes the issue with conflicting bundle names although they may belong to two different ClassLoaders
* misc improvements (as suggested by intellij)
* first draft of the DI functionality (#85)
* address review
* reenabled disabled inspections
* overload registerDependency method
* inject fields of superclasses two and remove invalid sponge default dependency
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.
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.
A RootCommand is shared between any BaseCommand that all use the same root.
We should not unregister the root command until all sub commands are unregistered.
* '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
Slight risk of API breakage but risk is minimal enough that I'm not bumping versions.
0.5.0 Migration guide suggested (Platform)CommandManager, which will set the generics for you.
Only if you stored the ref as the Abstract CommandManager would you now run into generic issues.
Also, cleaned up the sendMessage API's to not need Object now since we know the Generic type.
This is technically an API break, but considering Locales was only released last night and
the likelyhood someone overrode that method, is unlikey.
If you did, just fix the method signature! Sorry <3
Gabik21MC