Plugin Gremlins, and how to command them

Discussion in 'Bukkit News' started by Dinnerbone, Feb 1, 2011.

Thread Status:
Not open for further replies.
  1. Offline


    No, alias will not work as they are part of the compiled yaml included in the jar from what I am reading.
  2. Offline


    make a TUI console :)
  3. Offline


    This is why we need to have access to the commandMap instance. That would solved all the problem related to the new command system.
  4. Offline

    Don Redhorse

    I like it, but the major issue atm is that most plugins DON't use a structure like this, they mainly go for /sweet instead for /mc sweet.

    So if there is another plugin developer who also uses /sweet there is a problem. And as long as bukkit doesn't enforce the above mentioned structure or at least make it a requirement AND allows aliases to map long command to simple one it will not change ;-(

    Unfortunalty several of the most used plugins have these problems, WorldGuard, WorldEdit, Essentials for example.
    --- merged: Feb 5, 2011 7:17 PM ---
    I doubt, as it would create a race condition of which plugin register the command first, so every developer needs at least to define two commands for example /god and /mp god (mp here for myplugin) to have a fallback. It would be a pity if /mp was also already taken..
  5. Offline


    I think this is the problem aliases are meant to solve- so the admin would add an alias for one of the other. There has to be some way to disable the "default" alias for a command, though, so you can choose which plugin uses it, I guess.

    I write all of my plugins to stick to one basic command that is near to the plugin name. Then I use sub-commands. If you're plugin isn't a "grab bag" of unrelated commands like ScrapBukkit, I really think this is the right way to go- it goes a long way toward avoiding this problem altogether.

    It's only a problem if plugins are allowed to write to the store- which is, I imagine, why it's not directly exposed. We need an API to look at it, and maybe auto-add aliases. But adding new commands or modifying the names of existing commands would really break things, I imagine, both internally and for plugins- which are not set up to have the base name of their command modified, generally.

    Anyway, given just the ability to register aliases, plugins could resolve conflicts on their own, if they had chosen "backups" for commands they knew may be in conflict- like if you wanted to make your own "/spawn" for some reason.

    Of course, if this were just handled internally with the YML file, and there was some way Bukkit could auto-resolve conflicts gracefully, I'm not sure we'd need this at all, anyway.
    --- merged: Feb 5, 2011 8:43 PM ---
    I had this same reaction- I always have/had a properties file entry to let admins modify the command my plugins listen for.

    It's not something I really want to give up. But if Filler is to know about commands, they have to be statically assigned- I don't really see a way around it that's not overly complex.
  6. Offline


    I dont want to give it up, its limiting our features. And nobody has responded with the answer to the question "what happened if multiple people need to register the /time command"
  7. Offline


    Filler shouldn't be statically assigning commands, if only for the possibility of regional language support in the future. Although there are many more reasons.

    Having several plugins nominate the same command isn't a problem if they have the same function, as most servers will use one or the other. It only becomes an issue when they have a different function but want to use the same command.

    Instead an approach that handles conflicts at runtime might be a better solution, with an option for the admin to assign aliases from config. This would naturally lend itself to easier regionalisation.

    For example if we have two plugins who want to use the same command name (eg /list & /list), the default action might be to suffix the commands (/list.1 & /list.2 or maybe /list.<pluginname>) and warn the admin that a conflict has been resolved automatically. The admin can then choose to assign aliases of their choosing (/list.1 = /listitems & /list.2 = /listplayers).
  8. Offline

    Don Redhorse

    atm you have a problem. and btw: you shouldn't give up and push that matter.

    In general I think registering "easy" commands like /time, /info, /save etc is one of the major ISSUES we have with plugin development.

    It shouldn't be allowed and only unique commands should be allowed which are based on a CommandBase and an addon.

    The Admin should than decide which plugin should get /time. Which require aliases... which would also allow for translation.

    Also it is not very nice to assume that everybody will use /give to give blocks to somebody because we will always have new players which aren't already "tarnished" by usage of commands (sorry I can't figure out the correct english atm), so they would even go with /es give because they don't know it any other way.

    Moving Plugins to unique commands and allowing a customizable alias structure for the admins is the only way to go. The plugin developers could even supply a helping list of aliases which could than be edited by the admins.

    See my thread about it and tell me it doesn't make sense, no problems with duplicate commands, easy to administer and even easy to translate (inkl. help).

    Ofcourse the framework is missing.
  9. Offline


    The thing is, this is really to support Fill, and the other items it will be using. I have my thoughts on where this is going, but even if I am correct, supporting the community by allowing us to have aliases. etc is all the more important.
  10. Offline

    Don Redhorse

    I agree, and it make totally sense to fore plugin developers to do so.. but the above mentioned structure would minimize the issues from the beginning. The only problem which could arise is that a plugin has the same base command like an other, in which case the plugin developer would need to thing about a new one. The help this process there should be a basecommand directory available which holds the mappings between plugins and basecommand.

    I mean it would be not very fullfilling for a plugin developer to code everything, write docs etc just to figure out when he submits the plugin that the basecommand is already taken.

    Unfortunatly I haven't really seen a lot of communication from the bukkit team about this or feedback about the concerns and ideas put forward here.
  11. Offline


    The users are already angry; the /time command seems to be one of the few fought over commands... and nobody has told me how this is supposed to work.
  12. Offline



    This doesn't work for dynamically created console and other commands. We either need events or a revamp to the plugin model (or at least commandmap) as discussed here:

    What are your thoughts on how dynamically created commands will work in the future? What is the team's plan on supporting them?

    The model currently is a bit java-centric and ideally we can get back to the core philosophy of being language agnostic and support (inherently) dynamic languages.
  13. Offline


    I'm supporting this. The commandMap instance should be available to manually add command after the server/plugin load. And, it will be also nice to have an access to a getAllCommand() method who return all registered command in the commandMap. This will allowed us to make a custom /help command or other stuff like that.
  14. Offline


    Another flaw in onCommand: error messages are useless. Messages in onPlayerCommand at least gave line number, where problem appears, but here you get only "Unhandled exception executing command 'jail' in plugin [plugin name]".
  15. Offline


    I remember there's a way to add other "commands" that call the same command in the yml file. How do I do that again?
  16. Offline


    Dinnerbone, you posted somewhere that there are aliases for commands (I have to find out how to add them, but that's not the point here).

    I had the idea to implement commands like /tp using the main command /PlgEssentials_tp and then aliasing it to /tp. Why So anybody can just open the .jar an remove the /tp alias if t collides for them without the need for me to edit anything or add a config file.

    Is that good/bad/feasible/allowed/recommended?
  17. Offline


    I want alias/customizeable commands yeh.. ; )
  18. Offline


    Well I used it in my plugins in current revisions, just if it is the best way to do it etc...
  19. Offline

    Don Redhorse

    well perhaps you should look into and for some suggestions I made... hacking a file internally of a plugin is not a good approach, allowing plugin developers to step on eachothers feet without giving the admin a way to fix it without editing a plugin neither.

    my suggestions would have probably solved most of the issues which came up since the implementation of this and which lead to people now breaking their plugins into functionality which is just a mere workaround.
  20. Offline


    For compatibility sake, plugins should NEVER be allowed to register commands on the fly. Every command needs to be defined before the plugin is loaded; this makes sense from a compatibility standpoint. Fill can tell what commands your plugin means to provide, and in some ways this is an interface for your plugin to call other plugins independent of their internals/provided interfaces.

    However, developers and users alike are finding reasons to want command aliases. Besides, typically there are only a certain amount of reasonable command labels that can exist.

    How can we make both sides happy?

    YAML registered commands automatically get registered as /<PluginName> <command>. For example, If you're running General AND Essentials for some reason (maybe you like some commands from one and some from the other - just an example) both can have a /time command, but they would need to be called like this:
    /essentials time <arguments>
    Now, we have no conflicts for any commands a plugin wants to hard-register, because they're all relegated to their own namespace.

    On the flip side, now everything is a pain to type, because you need to type the plugin name first! Therefore, a command alias system should be implemented (as suggested by many), but with the following features:
    • The first plugin to register a command gets that command auto-aliased to the version without the plugin name; i.e. /essentials time would auto-register /time if it was the first to load.
    • If another plugin registers a command with the same name, it does not receive an automatic alias. A warning is logged to the server log.
    • In a config file ( or perhaps Permissions configs?), server admins can define their own aliases, which take precedence over automatic assignments. For the most flexibility, perhaps these can be set as part of user and group permission definitions.
    • Plugins can use API calls to request their own aliases. User-defined aliases and auto-assignments overrule any plugin-requested changes. Plugins can modify any aliases associated with their own plugins
    I had also considered a system for multiple commands per alias, and while that is a worthwhile feature to include, it is outside the scope of this functionality, and it goes against the minimalist-implementation that Bukkit strives for (i.e. provide a framework and let the plugins create a behavior). This is also a good example of a plugin which will benefit from being able to define it's own command aliases at runtime. Fill will still need to look for conflicts and warn developers, but now it won't need to prevent showstoppers, because they won't exist (in this scope).
  21. Offline


    i disagree, plugins could register commands on the fly as long as you either threw an exception or returned false to say that it was unsuccessful

    and this hard coded command system plain sucks as we can't allow people to customize the commands
  22. Offline


    I'm not sure if you're responding to me or not since you did not include a quote; if you are responding to me, I think you did not read my post.
  23. Offline



    You're not supposed to quote the post above you as it wastes forum space, fyi.
  24. Offline

    Don Redhorse

    well honestly.. I like bukkit it lot but it also allows TOO much freedom IMHO.

    look at permissions... the developer stops coding it.. and it needs to be forged...
    we get an update of minecraft and bukkit gets updated... but all the plugins break..
    and you have to wait till the other developers find time to update their plugins again..

    and I'm only talking here about CORE plugins or better functions:

    - permission
    - help
    - persistance
    - aliases
    - Plugin manager

    you can't expect that one developer will always stay with minecraft.. hey0, niijki and some others already showed that they did turn their back on minecraft.. but I guess a team which handles the core of bukkit will. So bukkit should also supply the core functions most plugin developers need so that those plugin developers can write plugins the admins need.

    it doesn't make sense to have 4 different permission or help systems, it just adds work to the plugin developer or restricts the admin.
Thread Status:
Not open for further replies.

Share This Page