Plugin Command Standards

Discussion in 'Bukkit Discussion' started by Atroxide, Jan 5, 2011.

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


    In hMod there was many plugins following many different structures on how the commands were writen, some just had say /preview and /reset (which tells nothing of what it does) while others had /invsee and /invrevert which helped a bit more
    My suggestion is to structure it by giving the plugin a prefix, then a command, and then arguments if needed. In this example I will use BigBrother because it seems to have half/half on naming
    Here is the current list of commands
    I think we should change it to be
    The actual name of the commands don't matter, I changed some just because I think it would be eaiser to type but thats besides the point.
    This way we specifically know which command goes with what plugin and we won't have the issues of plugins using general broad-term command names and interfering with each other.

    I also suggest we use the /help feature to only print out the prefix of each command, so in this case using "/help" will just print out "/bb - BigBrother"
    Also using "/help bb" will list off all commands and using "/help bb rollback" will print out specific instructions for this command

    I think if we used plugin.yml or a specific file to list the help commands it will also help. Maybe even a help.yml for every plugin formated like this
    Blok and rayman86 like this.
  2. Offline


    I like this it should hopefully reduce collisions with overlapping mods
  3. Offline


    Also its already started with bukkit, The first plugin I look up has a /register command, which could mean ANYTHING and will most likely collide with other plugins if anywhere else uses general worded command names.
  4. Offline


    This could be enforced in bukkit, requiring all plugins to provide a prefix perimeter. When used Bukkit then strips it and passes the rest of the string to the plugin.
  5. Offline


    I like this! Maybe even have plugins provide a secondary and tertiary prefix in case the others are used?
  6. Offline


    I really like this idea. It would be great if this could be enforced by Bukkit, but at the very least it should be a convention among the community.

    And in cases of overlapping prefixes, the best solution would be a first-come first-serve basis (although plugins probably shouldn't have 1 letter prefixes), with the community there to call out where there are overlaps.
  7. Offline


    I like this, it reminds me more of an actual command line, like on a linux shell.
  8. Offline


    We're still working out the best way to go about doing this. Just bear in mind that regardless of what "system" you follow, you most likely will be required to recode your plugins to fit ours.
  9. Offline


    as long as there IS a system then that is fine by me :) Just stating my opinion on the best possible solution.
  10. Offline


    To also have it so you can put in "-s", "-a", etc. would also be nice for those of us who like to save time when writing out a command.
  11. Offline


    +1 for adding plugin prefixes to commands, or having each plugin only have access to one base command with arguements.
    With about 20 plugins my /help page was a rediculous 16 pages in hmod with no way to see the commands just associated with one plugin.

    To make rewriting each command less tedious I think bukkit should support the 'recent Command' command '//' as well as require plugins to all use one base command, a shortened version of said command, and support for flags to allow commands to be shorter.

    /LongPluginName <subCommand> <someArguement>
    could also be accessed by:
    /LPN <subCommand> <someArguement>
    and after /LPN was used once you could use:
    // <subCommand> <someArguement>
    lastly using flags instead of the sub commants the whole thing could be further shortened
    // -c <someArguement>
    Would be awesome if all plugins are required to support these.
  12. Offline

    Bill Hiers

    Yes this a great idea name space per plugin
  13. Offline


    fully agree to johannes, there should be a command like /help [pluginname]
  14. Offline


    IMO what would be ideal would be supporting the up and down arrow keys for browsing through previously issued commands (how it works in any shell).

    How about if each plugin got one command, the full plugin name, and bukkitt then supported an /alias command so individual users could alias their frequently used commands to whatever they want.

    /cuboid fill grass
    /alias c cuboid
    /c fill grass

    /cuboid fill grass
    /alias cf cuboid fill
    /cf grass

    /foobar with alot of arguments 1 2 3 4 5
    /alias foo foobar with alot of arguments 1 2 3 4 5
  15. Offline


    True, but that's client side, nothing that Bukkit could change, or would since notch has said he doesn't like people inserting stuff into the client code.

    However I wouldn't be surprised that either notch will add this himself, or once official client mod support is in, there will be mods for better chat that have this.

    Ah yes, that is quite a bit more elegant.

    There absolutely needs to be built in support for aliases, maybe both globally as defined by admins, and on a per-user basis. there was a plugin for hmod that did this that worked very well.
  16. Offline


    This kind of breaks things for something like the General Commands plugin. If everything is really going to be plugin-based, this will make it very annoying to do basic things. As an administrator and a user, I don't want to have to /basic spawn to go back to spawn, and I REALLY don't want to explain this to my users 8000 times. It would also be nice to do /motd instead of /basic motd. Likewise for other commands that were simple to do in hmod. I suppose the idea is to make a plugin to do every single little thing, but the reality is that this probably is not going to happen, and in addition having too many plugins is still going to affect efficiency.

    Just something else to keep in mind when making this decision, I guess. Aliases could solve the problem if implemented right. It would be good to give plugin developers a way of having some default aliases that administrators could disable or remove if they did not like.
  17. Offline


    Yeah, there would have to be default aliases for sure for the basic commands.
Thread Status:
Not open for further replies.

Share This Page