Command Conflicts

The problem

You run another plugin that already has /home or /spawn defined (such as Essentials or CommandBook) and when you install HomeSpawnPlus, you get the other plugin's home/spawn instead of HSP's. Typing /home gives you one result (the plugin you don't want) and typing /hsphome gives you HSP's result, presumably the result you DO want if you're reading this.

If you just want to fix it, skip ahead to What to do about it. If you are wondering why this happens and are thinking "it used to work" or "Essentials seems to work with other plugins, why not with HSP?", then read on.

Why does this happen

Bukkit's command conflict system is very rudimentary. The usual answer is for admins to resort to editing plugin.yml files or even renaming their JARs since Bukkit loads them alphabetically. And of course you have to remember to do these hacks every time you update your plugins - what a pain. This is a sad state of affairs, one that I hope the MC API resolves, it's one of the first few tickets developers submitted: MCAPI-7.

But wait, doesn't Essentials do something here? Essentials uses a hack, one that HSP also used previously that I called Command Usurping; it works by using the very limited Bukkit Command API to try to re-map Command Executors in some intelligent way. The downside is this depends on implementation details that the Bukkit team leaked (such as plugin.yml definitions), which are not required parts of the API, so any plugin that adheres only to the Bukkit API contract falls outside the visibility of hacks such as the one Essentials uses.

I think the better way to go is CommandBook's example. CommandBook dynamically defines commands; it's plugin authors don't have to maintain a separate plugin.yml from their codebase and better still, in CommandBook, when you turn a command off, it really is OFF. This is where the MCAPI will go and HSP follows this example. Since Essentials depends on the implementation detail of plugin.yml, it doesn't play nice with plugins like CommandBook and HomeSpawnPlus.

What to do about it

HSP has added an alias prefix /hsp in front of all of it's commands, so you can always count on that existing regardless of how you change your plugins around. So you can use /hsphome, /hspspawn, /hspgroupspawn, etc: every command has an alias with /hsp in front of it. This means you can consistently map your Bukkit aliases, for example:

# bukkit.yml
aliases:
  home: hsphome
  spawn: hspspawn

So just map the commands that are in conflict, usually command like /home, /sethome, /spawn, etc.

If you are using the excellent CommandBook plugin, another approach is to use CommandBook's facilities to disable the modules you want HSP to use instead. Since CommandBook does dynamic command registration, it actually won't register those commands at all, so HSP will work just fine. Further, CommandBook's changes are in it's config file, instead of plugin.yml, so they will persist even if you upgrade it to newer version.

# CommandBook config.yml
components:
  disabled:
    - homes
    - spawn-locations