Bukkit

@heliastein

Then don't use op. Think of op like 'root' on a unix machine, or 'admin' on Windows. The whole point is that it has all admin access. If you don't like that, don't use it. That's what permission systems are for, it gives you more granular control over exactly what access individual players or groups have.

So if you already have a permission system (since you're asking for a specific permission), then just stop using op and use your permission system instead; problem solved.

@xX_VETERAN_Xx

This is covered in the Advanced Cooldown & Warmup docs.

A short example:

cooldown:
  permission:
    entry1:
      cooldownPerPermission: true
      permissions:
        - group.groupA
      home: 30
    entry2:
      cooldownPerPermission: true
      permissions:
        - group.groupB
      home: 60

@Talidorn

Timer functions on respawn are not possible with the current API, it would require some sort of client modification. Bukkit does not provide the facility to 'cancel' the respawn event; if plugins such as HSP do nothing with the Respawn event, which is fired after the player clicks respawn on their screen, then Minecraft logic would take over and the player would be sent to their bedhome or default map spawn.

Your best bet would be some sort of custom plugin that started a timer on the death event and then tied into a sign-based teleport or some such. You could then have HSP send them to a purgatory world or a WorldGuard region on respawn, where they have to wait for the timer and then click on the sign when the time is up.

Of course you wouldn't have the advantage of being able to trigger HSP strategies in that case. One workaround could be using modeInRegion and make it so onHomeCommand does something special when they are in your respawn region. Then with this separate timer plugin you could do something like:

onDeath -> timer plugin starts timer onRespawn -> HSP sends player to 'purgatory' region times up -> player clicks sign and is sent to 'respawn' region /home -> player types /home in 'respawn' region and HSP keys off the region to do your strategy processing

That's probably as good as it's going to get, Bukkit/MC just doesn't offer an API to build the feature you want in a more direct way.

@Gunnerrrrr

This is because HSP checks per-permission, per-world and global strategies until it finds a successful match. In your case, per-world parkour doesn't produce a successful match, so HSP moves on to the global strategy homeMultiWorld.

To fix this, modify your parkour entry like so:

events:
  world:
    parkour:
      onHomeCommand:
        - homeLocalWorld
        - default

The default strategy is considered a match and tells HSP to stop processing and just do what the Bukkit default is. Since this is for the /home command and not a Bukkit event, there is no "default" action, so this will result in processing stopping there and the behavior you want will happen.

@Gunnerrrrr

There's no option for a "No home set." message, however you could just set the per-world events for that world to homeLocalWorld and it will accomplish the "this world home or do nothing" effect.

If you want the message specifically, please open an enhancement option for sendMessage functionality. Wouldn't be too hard to add and then you could send any message you want at any point you want. Something like:

events:
  world:
    mySpecialWorld:
      onHomeCommand:
        - homeLocalWorld
        - sendMessage:No home set.

With a sendMessage strategy added, this would have the effect of sending them to local home if they had one, or else it would fall through to the next strategy which would end up sending the message "No home set." and then with no other strategies to test, it would finish and do nothing just like it does today.

@Talidorn

If you use WorldBorder and set your border to 6000, HSP will tie into that automatically to spawn people within the WorldBorder range.

If you have your WorldBorder set larger (say to 10k) and you want HSP to limit people to only 6k of that, then no that is not currently possible.

One solution is if you use WorldGuard, you can make a region that covers the distance you want, and just set the region as pass-through, so it doesn't do anything except define the region. Then you can use HSP's spawnRegionRandom strategy to spawn players randomly inside that region.

Update: to clarify, if you DO have WorldBorder defined as +/- 6000 and your requirement is simply that you want the random spawn to be at Y=6 within that, then all you have to do is use modeYBounds like so:

events:
  world:
    SuperFlat:
      # or whatever event you want
      onSpawnCommand:
        - modeYBounds:6;6
        - spawnWorldRandom

@KisukiKasegane

Open an error ticket and print out the /version, /version HomeSpawnPlus and /plugins into the ticket. I'll see if I can reproduce it or surmise what is wrong from that info.

@Favorlock

Favorlock, your case sounds like you would benefit a lot from using verboseStrategyLogging. It will tell you exactly what HSP is doing.

The other thing which I notice in your config is that you list your "highest rank" last in your HSP config. You mention using PEX, which is known to propagate permissions upward. So you should list your highest perms first: ie. Veteran should be limit1 and Guest should be limit4.

@cheracc

The 0-nodes not working is somewhat of a bug/feature. HSP goes through the "per-permission/per-world/global" checks and looks for a value, and uses the first one it finds. In the 1.7 codebase, this is done repeatedly in different sections of the code and isn't consistent. In some places, it checks for the existence of a key (even if 0) and works like you describe. In others, the 0 (which is the default value if no key exists) is the same as no key existing and so it keeps looking.

This is fixed in the 2.0 codebase which utilizes common methods for processing the tiered results, so it's done once right and leveraged throughout the rest of the code (events, costs, homeLimits, etc).

In the mean time your best bet for 0-limits is the permission exemption, which of course you've stated isn't working for you in Bukkit 1.4.6. I will see if I can reproduce this issue and if so, I might be able to debug it, or if it turns out to be a Bukkit issue, perhaps work around it.