now supports splitting commands over multiple BaseCommands better
should now only match probable @Default handlers, so @CatchUnknown
can still work in obviously wrong scenarios.
@HelpCommand no longer implies @Default as @CatchUnknown will pick it up
This context was conflicting with each other over multiple
ACF modules, so if someone wanted to use multiple ACF's in same jar,
it would clash and not work.
The PR to move these was incomplete and this finishes fixing the
context handlers to support new and old.
ACF's permission tree can go more complex where a single root command
may have multiple dependent perm nodes.
So essentially ACF does not assign permission nodes to root in bukkit
and the such in a reasonable manner.
With this commit, we try to identify a single unique permission node,
and assign that permission node as the node to use where applicable.
In Bukkit/Sponge, we implement testPermission instead, which does a smarter
look up of all potential commands that root command might execute for the
given issuer, and if they have permission to any of them, then pass as true.
This is much more accurate, so if the issuer has access to no subcommand
then the root command should not be revealed anymore in Bukkit or Sponge.
In bungee, we are best guess at the unique perm node, and if there is
any ambiguity, it will be null and seen by everyone (but still enforces
permission checks)
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.
chickeneer