Bukkit

@InfroCZE

Also I just watched your video, thanks for taking detailed notes. It looks like your /spawn and /setspawn commands are being consumed by another plugin. Try using "/hspspawn" and "/hspsetspawn", you'll probably see different results. If the HSP results are the one you want, then read the FAQ about permanently remapping your command aliases to spawn/setspawn point to HSP instead of the other plugin.

@InfroCZE

Glad you like the plugin. Bukkit offers six priorities, LOWEST through HIGHEST and one final priority, MONITOR. Though, to my recollection, the Bukkit API doesn't guarantee particular ordering if two plugins share priority, in practice I recall it works out to be FIFO, such that the last plugin to register for an event "wins". Bukkit loads plugins alphabetically, so in this case if both HSP and SkyBlock are registering HIGHEST, SkyBlock is loaded second and therefore has "final say".

The most immediate fix is to just rename HomeSpawnPlus.jar to something like "zHomeSpawnPlus.jar", it will now be registered last and have final say. Of course the downside is every time you update HSP, you have to remember to make this change.

Another fix is that since HSP allows you to change the priority, you could change to priority MONITOR, which is higher than HIGHEST, though technically MONITOR priority is not supposed to change the event. In practice, nothing bad happens, but this is a violation of the API contract so it's always possible someday this could cause an issue or Bukkit might actually prevent MONITOR from changing the event.

The last fix is to ask the author of SkyBlock to add in dynamic priorities similar to what HSP has, so that as an admin, you could easily change your config to not be HIGHEST priority. Unfortunately, the Bukkit API does not make this easy at all for plugin authors to do, but I've done it in HSP and HSP is open source so he is welcome to look at the source and copy it for his own use. (assuming that plugin is GPL, if not, he can write me to ask for an exception to use my code in non-GPL plugin).

@Hangar

Over the weekend I set up a test server with the latest dev 1.7.2 CraftBukkit as well as the latest dev builds of plugins like WorldEdit, WorldGuard and CommandBook. Of course I installed the latest HSP Jenkins build #47.

Everything checked out fine for me. I didn't do an extensive test of every HSP option, but I was able to login fine, access and use my homes and excercise a couple of my test event strategies. No issues that I could see.

If you are still having the issue, I would recommend two things. First, setup your own test server with just HSP and some minimal plugins (such a permissions plugin and WorldEdit/WorldGuard) to validate your configuration. If you get an error in this environment, please open a ticket with the stack trace and a list of the versions of CraftBukkit and all plugins and also include your HSP config and what you did to create the error. Since this is a minimal environment that's easily reproducible by me, there's a very high chance I will be able to reproduce and therefore find & fix the issue.

If you're unable to do that, for whatever reason, your second option is to open a ticket with all the same information for your production server, for which I will assume the list of plugins is much larger. The downside is in order for me to reproduce, I have to install all of those plugins and configure/set them up and even then I may not be able to reproduce since I don't have your exact configurations. But you're welcome to upload the info anyway, sometimes something obvious jumps out once all the information is available to me.

@ImminentFire

While there is no direct support for this (ie something like spawnPlayerName where you could set a spawn for the playername), HSP can remember a spawn for each individual player. The intended use case for this was the idea that you have a random spawn and you want to remember where the player spawned so they can return there (instead of some other random spawn).

However, there is no command-based way to manipulate this spawn as an admin. But if you are familiar with SQL or are using a YAML back-end, you certainly could manipulate it there.

Another approach, if you're only expecting to do this for a handful of players, is to assign specific permissions to those players and set per-permission spawns. For example:

events:
  permission:
    bob:
      permissions: [player.bob]
      onJoin:
        - spawnNamedSpawn:bob

Using this setup, you would use your permission system to assign 'player.bob' (which I just made up, you can call it whatever you want) to your player 'bob', and then you would go to wherever you want bob to spawn and run /setspawn bob. Now whenever bob joins, he'll spawn there. You can do the same for onSpawnCommand and onDeath events, or whatever makes sense for what you are trying to do.

One advantage to this method is if you want to setup groups of players to spawn at specific locations (so 3 players all spawn at spawn X), you can easily do that without having to manage a spawn for every single player: you manage the spawn for a permission and then just give out the permission to the players you want to spawn at different places.

@Hangar

On a brief inspection of the stack trace and HSP code to narrow down the problem further, I find a lot in your stack trace that might not be HSP-related, but one that is and is particularly interesting is:

Caused by: java.lang.NullPointerException
        at org.morganm.homespawnplus.listener.HSPPlayerListener.onPlayerTeleport(HSPPlayerListener.java:409)

The line of code here is checking the PlayerTeleportEvent "getTo().getWorld()", as well as "getFrom().getWorld()", so one of those calls is returning null. I don't think it's possible for getTo() to be null (teleporting to null doesn't make sense, Bukkit should not let that happen), but it's possible that getFrom() is now null when logging in, which was not the case previously. Previously, as soon as the player logged in, they were given the default spawn location so getFrom() was never null. If that's changed in the latest release of Bukkit, I will have to fix HSP's code to handle the new condition.

However, if this were the issue, you would see this regardless of whether or not you were using WorldGuard or WorldGuard strategies, so this is not consistent with your statement that it worked fine until you used WorldGuard strategies. It's possible WorldGuard (or another plugin) is changing the Teleport events in such a way that getTo()/getFrom() are now null.

In any case, HSP should be coded defensively to protect against this condition without throwing NPEs, it's just surprising that suddenly getTo()/getFrom() are returning null when they never have before. It's all guesswork really until I get a test environment to see the problem in action for myself, so unless this issue solves itself (other plugins or Bukkit fixes), I'll have to do that to do any more research on the issue.

@Hangar

I notice now that you mention you started using spawnRegionRandom when the problem happened, so this makes me happy that at least those not using the WG integrations are probably unaffected. To answer your question, any strategy that depends on the WG integration (such as spawnRegionRandom) won't work if the integration is broken, as it appears to be with the latest WG dev versions.

I'll have to get a test environment up and running and all the latest dev WG code in order to reproduce the issue. In the past, any WG fixes are usually quite obvious and simple, the work is in me getting everything up and running to test with. Until then, don't use WG integration strategies.

If your HSP configuration depends on WG strategies (ie. you can't imagine possibly upgrading without it), then 2 things: 1) Don't upgrade to CB 1.7.2 yet and 2) post here to let me know, if enough people have the issue I'm more likely to try to get to it sooner rather than later.

Quick list of strategies that depend on WG integration: spawnWGregion, spawnRegionRandom, modeInRegion. In addition, the onRegionEnter and onRegionExit events will not work without the WG integration.

@draccydragon

Unix file perms are not set and "passed along" when downloading a file from a website such as dev.bukkit.org or Jenkins; the permissions will be set by whatever program you use to download the JAR file. Check your umask. For example, if your umask is set to 077 and you use wget to download the JAR, the local permission on your system after downloading will be 700 and you will have the problem you described.

@pilvimaa

As best I can recall, I don't believe there is any facility for spawning at the "last death location". It's a great suggestion, though and wouldn't be too hard to implement, however I'm not actively adding new features to the plugin. Feel free to open an enhancement ticket and when/if I ever feel so motivated to get back to feature enhancements, at least it'll be on the list.

@Hangar

It looks to be a problem between HSP and WorldGuard - it looks like a new version of WorldGuard was released and since HSP has an integration to allow functionality between the two, that is breaking. I'll have to see what changed in WorldGuard and update HSP.

Sadly, I see I added a core.multiverseEnabled option for disabling the MultiVerse integration, since I considered that the most risky (in terms of possible breakage) integration, but I never added such an option for WorldGuard. So looks like it'll be broken until I fix it (unless it's a WorldGuard issue that needs to be fixed on their side, always that chance).

@Hangar

Thanks for the heads up. HSP build for CB 1.7.2 just went up on Jenkins a few minutes ago, give it a test and let me know if there are any issues.