[ENHANCEMENT] Alias API

Bukkit and the plugins are great and all people concerned (developers, bukkit team, people helping in the forums) are doing a great job. But bukkit is on a rocky road and the usuability for the admin and user isn't at the point where it should be.

This thread is ONE part of several threads, please do me the favour and read them all and only reply in here with information which help this thread become productive. Thanks..

Bukkit has the following issues:

Permissions... different plugins, different concepts, complicated, error prone and shattered
Help.. complicated, not to the point, not really translatable / customizable.
Aliases.. Complicated and plugin specific
Forums.. Difficult to navigate and missing structures
Plugins.. Plugin Standards allow for to many issues

A lot of problems for admins and users come from commands which are complicated, not self explenatory or duplicate. There is already a basic approach to register two commands like /tp and /dctp or /dc tp for the same command, but that can still generate issues when you have 2 plugins which use the same command, sometimes even for different things.

Some plugins like DefaultCommands from Vildaberper use a quite good approach to make all commands alias able.

I would like to see the alias function as an API in bukkit and make it a requirement to support it by approved plugins.

The alias api should support:

registering of plugin command and alias from pluginalias.yml
conflict handling if command is already registered (either automatic (first come first served), semiautomatic (aliasorder.yml which contains hirachy of plugins, higher plugins will have the command),manual (error message in log and chat or via option dialog in chat)

Using a pluginalias.yml file in the plugindirectory would allow for full translation to other languages than english.



What do you think?

 

why post the damn thing a second time? sorry some type of bug on the forums caused me to see multiple of the post....

 

@chernobyl360 what do you mean? did I post the text 2 times in different threads? or did you just read the first paragraphs?

 

wow wierd it showed [ENHANCEMENT]Permissions- api twice on plugin development... sorry about that..

 

You can set aliases in the bukkit.yml, can't you?

 

no probs... I guess caused because I was editing 4 threads at the same time..

don't know... you mean the bukkit.yml in the server directory?

but how do you implement "collision detection" and predefined easy commands if every plugin can register /help ?

If you want to fallback to ONE bukkit.yml you would need to require that not plugin can register a /command but only /plugin command otherwise you would end up again at the point where we are.

 

From the wiki

Never did that myself, though.

 

You can also edit the plugin jar and change the plugin.yml, but the bukkit.yml way is much neater

 

There's two things I have to say about this.

One is that the bukkit.yml probably solves the majority of issues related to command aliases; however, I'm not certain it'll work to solve a command conflict. Do bukkit.yml aliases override command-provided registrations? I'm not sure, but they should. Anyway, the main issue is, suppose two plugins try to register the same command. One wins, the other loses; typically it's the one that's alphabetically first that wins, but you can't rely on that, because what if you later installed another plugin that registers the same command even earlier? So, bukkit.yml should have a mechanism to specify which plugin you want the command alias to be sent to. For example, if you have CommandBook and Tele++ loaded and CommandBook stole the tp command, you could then do something like this to force Tele++ to handle it instead:

Code:

aliases:
  tp:
    plugin: TelePlusPlus
    command: tp

The other thing I'd like is an API to register a new alias for an existing command at runtime. It could be a method in the Command class, or something in the Server class; either is fine. This would allow plugins to let users customize their command names by editing the config.yml; in some ways it does duplicate the mechanism in bukkit.yml, but as it currently stands I don't think this is fully possible with just bukkit.yml

It may be that just one of the two above enhancements would be sufficient to get the desired behaviour. However, I think it'd be nice to give a choice between the two.

It might also be nice to have something which would allow plugins like CommandHelper to register their user-defined aliases, but since PLAYER_COMMAND_PREPROCESS still exists, that's not all that important.

 

i actually was thinking about creating something like this...

 

I really like the manual command override idea in the bukkit.yml file (or any file for that matter). However, I raise my concern again that complex yaml configs always cause problems in the long run...even though it allows knowledgeable server owners to take full advantage of what Bukkit could be offering.

 

Bukkit already handles everything you listed:

If a plugin's commandname is already registered it defaults to pluginname:commandname
on top of that you can alias specific commands via bukkit.yml using the same method.

CommandMappings are done per-Plugin not server-wide. It just defaults to the last registered command when using the non-plugin specific alias. You CAN have multiple plugins that use identical aliases/commandnames they just end up needing to be references like the example above.

I don't see what the issue is here, as everything you say you want in an alias system already exists. Except for maybe changing the 'hierarchy' on overlapping commands, which can be made obsolete by just changing your own aliases.

 

well nice to have bukkit.yml which allows aliases but it doesn't help with the hierachy and you can expect an admin to make changes to a plugin.

Also this isn't just about having an alias api (may it via bukkit.yml or otherwise) but also about what it should be able to do. @Celtic Minstrel brought up some good points / ideas.

And I would like to add another one:

Integration into the help api so that if you rename a command that command is displayed correctly in help.

@Supersam654

DefaultCommands use a different syntax, don't know if it is better than yml though.

Let's recap:
We already have some way to alias commands
This way is lacking features, like hierachy and runtime registration
It doesn't integrate with the "nonexisting" help api to display the correct commands in help
It requires the admin to know all the pluginname:commandname to manually map those

Anything else?

 

I think I have an idea, however I need to know one thing first. If I specify "tp" as an alias to a command in my plugin.yml file and another plugin has "tp" as a command in it's plugin.yml file, will the other plugin always take priority when executing the command? Or will it still resort back to the name/order of registration process?

 

I don't see how this is bad though. They need to know the commands to use them anyway! How else are they going to know what the commands are in-game? And they don't need to know pluginname:commandname specifically. You can remap any of the aliases from the plugin like this not just the base command.

 

I believe my proposal in the Help thread covers this.

Correct.

Not sure what you mean by hierarchy. Runtime registration is lacking though. I know the Bukkit developers don't want runtime registration of commands, but they weren't quite so adamant against runtime registration of command aliases.

It does integrate with the limited existing "help api", which is to say the usage notes in plugin.yml.

Not in itself an issue.

Actually, your first sentence there is basically preventing the bukkit.yml method from being fully effective. The issue here is that pluginname:commandname is only registered in the event of a command conflict. So, you can't use bukkit.yml to give it an alias when it may not even be defined depending on which plugins you install. True, it would work for a given configuration of plugins; but it would be liable to breaking if you changed plugins.

I don't think this is true. See my response to Supersam where I'll be explaining how command registration works.

I also heard that pluginname:commandname is broken. Not sure if that's true.

When registering a command, Bukkit first attempts to register the primary command name, falling back to prefixing the plugin name if the command is already registered. Then it registers the aliases in the same manner, but marks them as being aliases. When resolving a conflict with the primary command name, if the other is an alias it is overridden.

So if one plugin registers the tp command, and another has tp as an alias to some other command, the first one wins no matter what order they load in.

 

well one of the ideas was that there is a programmatic way to have the pluginalias.yml being created or that it is supplied by the developer.. which would make it very easy for the admin to make changes. (yeah I know, more work for the developer)

but let's face it... bukkit and the plugins are done for the admins and the users... we should make that experience as good as possible.

What do you mean with remap? I'm not a developer and I'm in the lucky position to use DefaultCommands which allows aliasing or are able to edit the jar files to remove the "default registered command" like /tp from the plugin IIRC..

I think so yes... still need to read and understand it

The part you and @Sleaker posted about giving the /tp command to a plugin you choose.

Yeah, but that doesn't has the full function set I'm suggesting for help, e.g. translation... I don't want to edit plugin.yml to change a output of a command to my language.. well I don't need to because I run an english speaking server but other do..

in which case the existing way needs to be improved as it is complicated and not always the way an admin would like it to work.

so this would be an enhancement needed for the process atm?

perhaps we should flesh out more how we expect an alias api to work (which could be bukkit.yml together with changes on the command registration process, just use alias api as a placeholder for a working easy way for an admin to customize the commands)

and don't forget the integration into the help api... I hate it when I do a /myowncommand and get an error message /originalcommand does require a value...

hmm that would be errormessage handling... is that inside the plugin? if yes the alias api would need to support the developer to display the correct command in this case.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

I don't like the idea of adding ANOTHER file to configure as a server admin. bukkit related stuff should be in bukkit.yml - even if it has to do with commandmappings etc. Just my thoughts.

 

Ah, that. It's related to the plugin:command fallback system and the bukkit.yml registration system. Provided bukkit.yml takes top priority and the registration system always registered the fallback even when there was no conflict, it would be easy to use bukkit.yml to pick which plugin you want to handle a given command when several all provide the same one.

Translation is quite a different issue and only tangentially related to help. At this point it's up to individual plugin developers to write their plugins in a way that supports this; I recently refactored General to make translation (relatively) easy, for example.

Generally I think this is because the plugin didn't properly use the usage field; they put /originalcommand instead of /<command>. The latter is automatically replaced with the actual alias used.

 

so we need an enhancement in the command registration process

good to know that this is a problem with the plugin and already possible

... so that would be perhaps something for the plugin release rules

your thought is as good as mine, it would even have the benefit that it wouldn't be overwritten by the plugin if there is a change..

 

I don't think that we need to really change anything with the command registration, we simply need all devs to follow a couple basic rules. 1, if a plugin is an "all encompassing" plugin (Essentials, CommandBook, DefaultCommands, etc), all the "generic" commands need to be aliases and all of the " unique" commands should be the actual command. For instance, "tp" should be an alias of the "cbteleport" (CommandBook) command. This still allows general plugins to function perfectly, however it means that if a more specific plugin (that only does a few things really, really well) comes along, it can simply set the generic command as the command and either have a "unique" alias or no alias at all. If 2 unique plugins have overlapping commands, then you are doing something wrong (you shouldn't need 2 teleporting plugins).

 

so that would be stuff for release rules and screening of plugins right?

and I agree you normally don't need more than one tp plugin... well I use 3 atm kinda, DefaultCommand has tp and I use it for tp override (admins), teleconfirmlite for confirmation of teleports (users), and tele++ for teleport to x,y,z.. sigh...

but it works, thanks to defaultcommand alias system, but this is NOT normal.. my setup I mean..

concerning overlapping commands it will happen though... like /search for /search player or /search item etc..

so having the /plugin1search and /plugin2search commands register normally and the /search alias register later would fix that? How would you configure than that ONE specific plugin will have the /search alias.. via bukkit.yml?

BTW: @Shamebot How do you find that information about aliasing in bukkit.yml? I think I did oversee it.

 

@Don Redhorse http://wiki.bukkit.org/FAQ#How_do_I_rename_a_command.3F