Bukkit

@ThisUsernameIsMine

Yes it shows home names, if set. If you type "/homes" and see your home names, then try typing "/hlo player" where player is yourself. The listing should be almost exactly the same.

If you're not seeing names listed, it's probably because that player has not set any named homes. HSP allows users to set a home with no name (ie. just /sethome), so to easily distinguish between multiple homes with no name (on different worlds), HSP also prints the unique id of the home. It does this for all homes, whether the have a name or not.

@Mayhem777

If HSP is returning default, as you show, then its event handler is essentially this:

public void onPlayerRespawn(PlayerRespawnEvent e) {
  return;
}

Yes, it's doing NOTHING. The fact that you're going to Bukkit's default spawn is because it's Bukkit doing the teleporting, not HSP.

You said when you uninstall HSP it suddenly works, though? The only thing I can think to explain that behavior is your other plugin/script is detecting the presence of other listeners to the respawn event and doing something different in that case. As you can see from the above code example, there's no reason in HSP to explain the behavior you are seeing, it's not doing anything to change or modify the event in any way.

As I mentioned in my previous comment that if you arrived at this juncture (HSP is doing nothing but you're still seeing the strange behavior), you need to work with the other plugin author to find out if s/he's doing something weird such as detecting other listeners.

@Mayhem777

Have you turned on verboseStrategyLogging as I suggested? That will tell you exactly what HSP is doing. Given your strategy, assuming the player dies outside of a WG region with a spawn flag, you should see something like:

2012-10-05 [INFO] [HomeSpawnPlus] Attempting to respawn player xxx (joining).
2012-10-05 [INFO] [HomeSpawnPlus] Strategy evaluation started, type=onjoin player=CraftPlayer{name=xxx}
2012-10-05 [INFO] [HomeSpawnPlus] (strategy spawnNewPlayer) player is detemined to NOT be a new player
2012-10-05 [INFO] [HomeSpawnPlus] (strategy spawnNewPlayer) result is [loc={null}, home=null, spawn={null}]
2012-10-05 [INFO] [HomeSpawnPlus] (strategy default) result is [loc={null}, home=null, spawn={null}]
2012-10-05 [INFO] [HomeSpawnPlus] Evaluation chain complete, result = explicit default

In this example I'm showing my login with strategies spawnNewPlayer and default. The key part is the last two lines, which say that the result location is null and the chain result is "explicit default". This means HSP does NOTHING.

If your other plugin does SOMETHING, whether it's before or after HSP and HSP spits out a null location like above, then HSP isn't changing anything, it's just passing through silently.

Since the behavior you're describing doesn't match the above, I'm guessing your HSP verbose output looks different. If it does look the same (your HSP is doing nothing) and you're still getting the same behavior where the other plugin isn't doing anything, then it's possible there's something really bizarre going on in your other plugin and you may have to get that author involved to figure it out.

@ThisUsernameIsMine

Use the /homelistother command (alias /hlo). The output looks exactly the same as /homes except it shows it for other players.

@Mayhem777

Follow the FAQ to turn on verboseStrategyLogging. That will tell you exactly what HSP is trying to do. Compare that to what you want to have happen.

Now, you need to decide how you want things to work. You say you have a plugin that respawns them in a certain location: presumably this means onDeath? Does this mean you no longer want HSP to handle onDeath events? If so, it's a simple matter:

events:
  onDeath:
    - default

Or just comment out onDeath altogether - same effect.

Now you might be thinking, but wait, I don't want my HSP onDeath commented out - I just don't want it used when people are supposed to be going through this script in some-other-plugin?

There are two ways to do this. One is that HSP provides direct support for some-other-plugin, like it does for WorldGuard. In this case, you can make strategies (like the ones for WG) that allow HSP to yield control to the other plugin. It seems unlikely I'd make this for you unless it was a large plugin with a lot of users. Of course HSP is open source, so you could make it yourself.

The second way is that you give HSP some way to know when this is happening. The easiest would be to set a permission. So if someone starts on this script in some other plugin, you might set the permission "playerOnTutorial". Then you can use HSP's per-permission strategy to do nothing when the the permission is set, and use your default onDeath chain when is isn't.

@Hangar

Hangar, I used to have this alias, but it was only on a few commands and it was lost in the conversion to the new command system. The current dev release (available on Changelog page) add an "hsp"-prefixed alias for all HSP commands (ie. /hsphome, /hspspawn, etc). Give it a go and let me know.

@ThisUsernameIsMine

The permission should be: "hsp.command.guest", using one of your examples. However, looking through HSP code, as best I can see this isn't functioning as intended (I'll need to do some testing).

What should work is defining your own permission, as in:

commands:
  guest:
    class: CustomEventCommand
    event: rang_guest
    permission: hsp.command.guest

Or just call it "hsp.command.customspawn" and give them al the same permission, however you want to do it. The permission is supposed to happen automatically so I'll do some testing locally and fix it if it's not, but for now this should workaround the issue. Let me know if you find otherwise.

Note that being an op is irrelevant, HSP only checks op if you're using "op-only" permission system. A lot of people seem to expect that op should be equivalent to the old "*" node regardless of if you're using a permission system; maybe I'll change it to do exactly that.