Bukkit

Giving it some more thought, I really like @necrodoom's suggestion. The idea for command usurping predates the Bukkit alias system and I think the alias system is a reasonable way for admins to accomplish the same objective. It's also less code for me to support and I expect it will work with Essentials without any headaches from their own custom remapping system.

In the next version, HSP will have the prefix "hsp" for ALL of it's commands. Thus if you have a conflict and decide you want "/home" to be mapped to HSP, you can simply make an alias for "/home -> /hsphome". Your users won't know the difference and you don't have to monkey with anything when you upgrade plugins; set and forget.

So for those handful of HSP users still on 1.6.x and waiting for a 1.7 fix for Essentials, give me a few days and I'll add some FAQ docs and give you a test build to let me know how it works.

@Necrodoom

An interesting suggestion, Necrodoom. HSP does have aliases, such as "hsphome". Hanger, perhaps you want to try that: add an alias in bukkit.yml from "home" to "hsphome"?

Khobbits, you've been by once before and I appreciate your sincere desire to help. However, your statements are in conflict. At the end, you say: "I think the whole idea of trying to modify the standard way of doing things, and messing around with bukkit internal command handling is a bad idea, even with the best intentions in mind." At the beginning, you say: "To help with this, Essentials 'gives up' commands by default." (aka messing around with command handling)

I recall looking into Essentials code a month ago, you have a whole giant class dedicated to trying to "help" the user, messing around with Bukkit commands. The only difference might be your use of the qualifier 'internal'. That aside, the goals between HSP and Essentials are exactly the same, to help the admin not have to deal with hokey things like editing plugin.yml files or having to manage aliases. Each plugin tries to do the "right thing" as directed by the admin with a minimum of fuss.

Regarding 'forcing plugin to take priority': this is only done at the request of the admin - they must turn on a config option - and actually uses the exact same mechanism you do in Essentials, modifying Bukkit API Executors. The two plugins approaches are no different in this regard; there is no "opposite approach" here. So if your classifying HSP as these evil "other plugins" by your definition, Essentials is exactly the same. (Just so we're on the same page)

You mention sk89q's command system, which conceptually was the icebreaker that I modeled after (he showed it was possible to get it working, I wanted similar easy configuration for my users). I actually tried to use his first, but his was very specific to CommandBook/WorldEdit and not easily exportable by use for other plugins. However, my impl is no different in interaction with bukkit.yml, aliases should work fine.

TL;DR I will give figuring out this problem one more detailed pass now that I have a users configs who has the problem and can hopefully reproduce it locally. If I cannot figure out the conflict, I will suggest users use the bukkit.yml alias method. It's not the original easy configuration goal I was after, but it is a concrete way for the admin to tell Bukkit what they want done without having to monkey with plugin.yml files that get blown away every update.

Thank you both again for your sincere interest in resolving the problem, hats off to you both for your commitment to your users.

ps. to be clear, there are two mechanisms in HSP. 'commandUsurping', an admin configured option (off by default), works using Bukkit API in the same way Essentials does and has been in HSP since 1.0. The 1.7 command features work much like sk89q's system, there are no command definitions in plugin.yml, it is all dynamic and as a result, there are no DRY violations and my users can also define custom commands in their configs and fully disable HSP commands if they wish (again, similar to CommandBook).

@Hangar

Yes, it seems there are still issues between HSP 1.7.2 and Essentials in some cases. It has been this way since 1.7 and I've tried gathering information from users to track it down, but I've never been able to reproduce the issue and the two work fine in all my tests. User @ccman972 recently sent me all his configs, so I'm hoping that using his configs I will be able to reproduce the issue locally and finally debug and fix it. As you've read, once you know you are an "affected" user (most HSP users seem to be fine), you should stay on 1.6.x until the issue is resolved.

Regarding the issue with usurpCommands and Essentials syntax, this is because Essentials does not actually turn off commands. It jumps through hoops to "hide" it's commands and pass control to other plugins. Very similar hoops I jump through with commandUsurping to map commands from other plugins to HSP.

The problem is really that Bukkit doesn't offer any system for dynamically controlling commands: a plugin author statically puts something into "plugin.yml" and very little control is offered beyond that. I'm optimistic the official API from Mojang will improve on this situation and give us a solution that gives devs and Server Admins much better control over commands so we can all stop jumping through hoops to accomplish this, such as server admins editing plugin.yml every upgrade. Which, btw, editing your Essentials plugin.yml would probably get you up and running since HSP & Essentials wouldn't conflict anymore. But of course you have to remember to do it every Essentials upgrade.

Stay tuned while I try @ccman972's configs to see if I can reproduce the problem, if not I will definitely take you up on your offer to help so I can hopefully resolve this pesky issue.

@ccman972

Yes, 1.6.3 is the last version before the dynamic command system was introduced in 1.7. It seems even as of 1.7.2, some people running Essentials still have issues with conflicting commands between Essentials and HSP. I've run the latest versions of both in local test environments and have never been able to reproduce the issue.

Since you've uploaded your configs for both, I should be able to locally test your exact environment and if I'm lucky, I will finally be able to reproduce the issue. If so, it should be a straightforward debugging exercise for me to track down and resolve. Feel free to try 1.7.2 to see if you have success, but if not, sit tight on 1.6.3 and hope I'm able to reproduce the problem with the information you've given me.

@Q2Lummox

As I tell most people who post ideas in the comment stream, please open an enhancement request on the ticket tab. I frequently look over the ticket tab for outstanding bugs or enhancement requests as I'm doing new releases. If you post it here in the comment stream, I may have seen and even commented it on one time, but I forget if I don't see it in the enhancement list.

Your request seems reasonable so please open a ticket and I will get to it for next time. I usually post dev releases as I'm building the next one so you'll get access to early testing as soon as the feature is built.

@JohOply

Yes. Use the backup & restore features (documented in admin commands).

First, run a backup with your sqlite database. Then verify your data is in the "backup.yml" file. Now change your bukkit.yml over to MySQL (beware this is a global setting, you might have other plugins that switch also) and restart Bukkit. HSP will detect the missing MySQL database and create a new (empty) one. Now just run /hsp restore OVERWITE (exact case is required) and HSP will restore your backup.yml into your new MySQL database. No restart required.

@diannetea

The first issue is related to economy. I'm not sure from your list of plugins which economy plugin you're using (Essentials, perhaps?), but it's failing to print the "money display" properly when charging the player money. I will build a better protection into HSP to give a more clear error message in the future, but the issue is out of HSP's hands. I'm not sure if the issue is with Vault or your economy plugin. To workaround for now, set your costs to 0 in your HSP config.yml. Or you can play with different economy settings to try to fix now that you know the source of the problem.

The second issue is the same one you already reported: there is some sort of bug in your environment related to the Multiverse integration. The line of code it's breaking on should never NPE, because there is no valid condition under which the variables involved should be null. Consequently, I'm not able to reproduce the issue, because that variable is never null in my test environment. That said, it's possible there's some sort of error when HSP starts up that is causing the variable to be null, so if you can restart your server and look for any errors from when HSP starts up, that might help me find the cause. If there are no errors when it starts up, that would be useful information also.

Also, since I'm getting a lot of activity in the comment stream and it's hard to carry on multiple threads here, please feel free to open a ticket for these issues and I can deal with them individually there. Thank you for using pastebin, that's a big help!

@diannetea

Thanks for the stack trace and details. I'm unable to reproduce the issue. According to the stack trace, the issue is related to HSP's Multiverse integration. I setup a test server with your exact plugin versions (Bukkit/HSP/Multiverse) and am unable to reproduce the error.

>version HomeSpawnPlus
20:24:51 [INFO] HomeSpawnPlus version 1.7.2
20:24:51 [INFO] Author: morganm
>version Multiverse-Core
20:24:55 [INFO] Multiverse-Core version 2.4-b527
20:24:55 [INFO] Authors: Rigby, fernferret, lithium3141 and main--
>version
20:25:09 [INFO] This server is running CraftBukkit version git-Bukkit-1.3.2-R1.0-b2377jnks (MC: 1.3.2) (Implementing API version 1.3.2-R1.0)

I've also poked through the code and am not entirely sure how the error is happening unless there is some other error happening that precedes this one. Can you see any other stack trace closer to startup of the Bukkit server from HSP that might indicate the root cause?

Do you know what is happening that causes the stack trace you posted; such an /mvtp command or some other teleport event?

Please open a ticket with your NPE exception and upload your HSP and Multiverse configs there, maybe there's something unique in your config that is causing an issue.

@ccman972

Using your configs, I setup a server and confirmed:

>pc hsp.command.home xxx
17:55:52 [INFO] Player xxx DOES NOT HAVE permission hsp.command.home on world world (perm system in use = PEX).
>pc hsp.full xxx
17:56:09 [INFO] Player xxx HAS permission hsp.full on world world (perm system in use = PEX).

Thanks for the detail, it was very easy to reproduce and confirm the issue. I will test with other permission systems and see if this issue is unique to PEX.

EDIT Confirmed, this bug is unique to PEX. I installed both PermissionsBukkit and bPerms and both worked fine with hsp.full whereas PEX did not. I will add a note in the FAQ and Permissions documentation to save future folks the headache.

@diannetea

The stack trace and plugin info are a huge help. I will look into it. In the future, please use pastebin to share lots of information like this, it's much easier to read and doesn't flood the comments with walls of text. Or if you have a stack trace, consider opening a ticket here which also has a paste mechanism for stack traces and such.

I'll let you know what I find.