Resource (ACF - BETA) Annotation Command Framework

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

  1. Well, I really like this idea. It makes everything easier for the developer.
    But, I have a question...

    Some time ago we heard that Minecraft will be getting a command syntax stuff on chat.
    Will you update ACF to support that ?

    (Sorry if this has been asked before, but I don't follow this thread)
  2. Yes, the plan is for ACF to implement the 1.13 Command Spec to the best of its ability when ran on 1.13+ servers.

    So you can use ACF and the goal is that ACF will translate its state into the respective state.

    Also, note that 1.13's command is about client UX for syntax/completions, and not about server side utility of command management, so its unlikely to ever be a 'replacement' to ACF (plus, ACF will let you still support older MC versions :))
    • Like Like x 1
  3. I got a stupid idea for ACF.
    When 1.13's command syntax stuff is available to the public, you could try to bring that feature to legacy servers(1.13-). You could try to detect when a player tab-completes a command and *maybe* send the syntax to the client using the action bar.

    Sorry if this idea seems stupid...
  4. Maybe in future there would be more extendable capabilities in the core that users can extend, then you could implement such an idea, but i dont see that being in ACF itself.
    • Friendly Friendly x 1
  5. Hi, it's me again, how is @ Default supposed to work?

    I have tried this signature
    Code (Java):
    public void onTestCommand(CommandSender sender, @Default(1) Integer number)
    but I get this error:

  6. @Default("1") would parse it as an int of 1.
  7. electronicboy

    IRC Staff

    Just played with ACF last night after being one of the few people who was asking him to make the framework public (oops), in Kotlin you will need to write a few context resolvers for the Kotlin objects (not all that hard as you can basically just grab them from inside ACF), however; my one concern is a replacement for Player[], My only current idea would be to create a small implementation of List or something that will try to provide a means to pull out players unless somebody knows a way to deal with this in Kotlin nicely
  8. OnlinePlayer is suppose to be used for any OTHER player lookup. Player itself is for the sender.

    OnlinePlayer[] already exists as a context.
  9. Good news for those waiting on this...

    Support for per-player locales for Bukkit has landed.

    To enable, call manager.usePerIssuerLocale(true);

    One caveat is if you use login messages, the game will not have sent the clients language yet in the PlayerJoinEvent.

    So for best results, delay your On Login Messages for at least 2-3 seconds.

    for Paper users, you can use manager.onLocaleChange((issuer, old, new) -> {});
    and print login messages when old == null and new == something

    Only paper starts with locale = null, so if a player logs in with English, no locale change will even trigger.

    The system will start a timer and automatically detect language changes, and call that callback anytime a players language has changed.

    Also, news for Paper server users - I am working on an AsyncTabCompleteEvent, so that Tab Complete Handlers can be marked async safe. Then if the handler is defined and async safe, we can skip going to the main thread all together.

    This will be a huge gain if you need to make DB queries or disk IO for items such as Offline Player tab completion.

    This work is still pending though.
    • Like Like x 1
  10. Async Tab Completion has landed!

    In order to make use of this amazing new feature, you must:

    1. compile your plugin to use acf-paper instead of acf-bukkit, with PaperCommandManager
    2. run the plugin on Paper Server build 1268+ (which as of this post, is the latest build)
    when both conditions are met, you should see:

    [01:01:35] [Server thread/INFO]: [Empire] [ACF] Enabled Asynchronous Tab Completion Support!
    [01:01:35] [Server thread/INFO]: [Empire] [ACF] Minecraft Version: 1.12

    If you have registered any custom Command Completion Handlers, that are safe to be ran async (doesn't touch game state, and uses concurrent collections for any persistent state), then change .registerCompletion() to .registerAsyncCompletion()

    That's all you need to do.

    If you .registerAsyncCompletion and its ran on a server that does not support async completions, the completion handler will still be ran sync.

    If you need to know if you are truly executing sync or not for your completion handler, the completionContext.isAsync() exists to find that out.

    A lot of code changed for this release, so please let me know if any bugs are encountered.
  11. There's been a few bug fixes to Async Tab Completion, so be sure you're running the latest ACF build (aka: compiled recently)

    But in other news. md5 has announced he will NOT be exposing Brigadier (1.13's command system) to Bukkit Plugins...

    This means ACF will be your easiest way to tie into Brigadier support once we have added support for it.

    My goal is that users wont even have to do a single thing for it.

    I will simply detect if Brigadier is available, and if so, insert the appropriate metadata into its registry and send it to the client, enabling a better user experience.
  12. Few more bug fixes, including Bukkit sent up today.
    Get your update on!

    @CommandCompletion now works on your @Default/@UnknownHandler

    Bukkit Command Completion/Execution context has a .getPlayer() method.

    As a reminder of previous updates, Per Player Locales has been added to Bukkit.

    So if you can make your spanish players receive spanish text, english english, french get french, etc!

    See above post for details. Ensure you load up appropriate custom language tables.
  13. Made some progress on "Conditions"

    This would let you add stuff like
    Code (Text):
    on a command to validate that the user is in creative

    A similar check like that could of been done inside of a Command Context, but it would of required you to redefine the base CommandSender context, so not clean.

    Conditions can be applied on a parameter to apply a condition in relation to the parameter itself, or on a method to validate when that specific command is ran, or on the entire class (or any parent class) to apply a condition to every command in the class.

    Cooldowns is an example of something you could build a condition for (would require you to maintain state though)

    However, I do want to explore, as ive mentioned before, "feature packets", that could handle that state management and provide the cooldown as a generic feature.

    I'll update when this feature is done.
    • Like Like x 4
  14. bump for command greatness
  15. How are we able to modify the format for the usage? I saw theirs some message thing within the foot, but didn’t quite understand it
  16. In which context, missing/invalid parameters?

    There is this language key:
    Code (Text):
    acf-core.invalid_syntax = Usage: <c2>{command}</c2> <c3>{syntax}</c3>
    Override it per
    • Useful Useful x 1
  17. Thank you! I've always wanted to customise that (I have my own server core, looked cleaner to be in my chosen colours).

Share This Page