Resource (ACF - BETA) Annotation Command Framework

Discussion in 'Spigot Plugin Development' started by Aikar, Apr 19, 2017.

  1. @awsqed Upon reviewing the issue, it really seems like registerOptionalContext has no reason to exists once I fix this issue...

    so when I fix this, I'm going to deprecate registerOptionalContext, so that any param that has @Optional that is not sender aware, will just return null without calling the context resolver.
    • Like Like x 1
  2. @awsqed Seems I was wrong. Optional does have a more specific case.

    You simply need to register your context as .registerContext instead of Optional.

    I have however also added BigDecimal and BigInteger as properly supported contexts now too.
  3. @Aikar I also tried to register it as normal context, but other command that need an optional BigDecimal argument broke, so I'm current use a default tag for the command as a replacement.
    What you mean is in the next update I don't need to register it anymore?
  4. Correct, you don't need to register it anymore, its now provided.

    But what issue did you encounter? As .registerContext is the correct method for this.

    If you put BigDecimal/BigInteger, itll require input unless you put @Optional, in which the param will be null
  5. I have some command that has an Optional BigDecimal argument in it. For example:
    Code (Text):
    /modify <player> <rank> [multiplier]
    The command should execute normally without the 3rd argument, but when I register the BigDecimal as normal context (#registerContext), it throws an InvalidCommandArgument exception, which is return the error message about syntax thingy.
  6. if you don't want to be required, either use @Optional or @Default

    @Default("1") is probably what you want, but why are you needing a BigDecimal for a multiplier on a rank anyways? double is fine here.
  7. It seems like you don't understand the problem I encountered, anway, it doesn't matter anymore. Thanks for your help.
  8. @awsqed I do understand your problem. I'm saying you did not use it correctly.

    you were using .registerOptionalContext as a hack to avoid putting @Optional on the parameter, and thats not how its intended to be used.

    If you have @Optional on the parameter, you should not see the InvalidCommandArgument thing.

    If you did, please paste me your command definition code.
  9. Your code should of used .registerContext and /withdraw like this:

    Code (Java):

    public void withdraw(Player player, BigDecimal amount, @Default("1") int size) {
    Would of gave syntax message due to missing required parameter.

    Code (Java):

    public void modify(Player player, String otherPlayer,  String rank, @Default("1") BigDecimal modifier) {
    Would of worked too, though BigDecimal here is odd.
  10. Code (Text):

        public void modify(CommandSender sender, Prisoner prisoner, Rank rank, @Optional Long prestige, @Optional BigDecimal multiplier) {
            // code
    That's the point, I did use the @Optional tag, bug it still throws me the syntax message.
  11. @awsqed

    I'm not sure what you did differently, but everything is working as expected:
    Code (Java):
    public void onFoo(CommandSender sender, @Optional Long prestige,
        @Optional BigDecimal modifier) {
        sender.sendMessage("You gave " +
            (prestige != null ?  prestige : "null") + " prestige at " +
            (modifier != null ? modifier : "null") + " modifier");
    #232 Aikar, Mar 8, 2018
    Last edited: Mar 8, 2018
  12. I'll recheck the source, if it still happen, I'll PM you the code.
  13. MiniDigger


    • Winner Winner x 1
    • Useful Useful x 1
  14. Current progress of MiniDigger's help work has landed and been deployed.

    So recompile your plugins w/ latest ACF to get even better help system.

    New MessageKeys have been added for header/footers, as well as a HelpFormatter system.

    As a reminder, this is all UNSTABLE, and API compat is still at risk of being changed. So if you start using the HelpFormatter, please note that you may have to perform updates if we need to further change signatures.

    Though I did some work on top of MiniDigger's work to clean up the formatter method signatures to reduce risk of needing to break the signature.

    You may now put @Description on your parameters too to add docs on what the parameter is when triggered by detailed help.

    If your command is /foo kickplayer,
    then typing /foo help kick will show search results that lists kickplayer,

    but typing /foo help kickplayer will show detailed help about kickplayer


    Additionally, lots of progress has been made on Annotation Processors. I've been refactoring code to get it ready for this.

    These changes also improved performance, by pre looking up all annotations at registration time, and storing values.

    There should be very little to no annotation access during command execution now (Context Handlers excluded, they might still)

    This work is paving the way to allow you to register custom annotations that either "provide" existing core ACF annotations, or manipulate / post process annotations.

    The annotation processors are going to open so much potential for using any annotation and defining behavior of what it should do

    They will be like event Listeners per annotation, such as the following:

    Code (Text):
    @RequireConfirmation @NotifyOps @CommandAlias("ban")
    public void banPlayer(Player player, @FromPlayer UUID uuid) {}
    You could define a @RequireConfirmation annotation that automatically shows a Chest GUI confirmation prompt, confirming you really want to execute the command

    You can then define a @NotifyOps that says anytime this command is ran, notify all online ops of the command being ran

    @FromPlayer can hook into context resolution, as a "pre" step, and take input in the form of a player name (ie, it may even automatically forward the logic to another context resolver such as OfflinePlayer) to get the UUID of the player.

    The possibilities of what you can use annotations to do will be endless and up to your imagination.

    "Command Cooldowns" is a planned feature I want to provide, where I will start to provide additional "Feature packs" that you can add on and register to your command manager, so i don't have to bloat ACF core with these optional features.

    I'm excited for the future of what we can provide.
    • Like Like x 1
    • Friendly Friendly x 1
  15. This has really sped up my development time!
  16. long overdue bump!
  17. Is there any way to remove a subcommand from the tab complete suggestions?

    Background: I have some subcommands for clickable messages. The players shouldn't be able to see them via tab complete, but all subcommands are automatically added to the suggestions in getCommandsForCompletion.
  18. MiniDigger


    I mean, you could override that method I guess.
    Mmh, nur thinking about it, making a command not show up in tab and the help section would be kinda cool. Mind sticking up an issue on GitHub and tagging me? Maybe I can implement that later.