Bukkit

<<reply 731685="">>

The comment is basically that "groupSpawn" behavior is local to a world, not global across all worlds. This has more to do with the history of permission systems and how this feature was designed.

To enable something like what you described, you'd have to use the "spawnGroupSpecificWorld" strategy. Say you have Group 1 and 2. And you have worlds A and B. You define groupspawn for group 1 and 2 on A. Which, as you say, when on A, works fine. In order for the same to work on B, you need to use the strategy "spawnGroupSpecificWorld:A". You don't even need per-world or per-permission strategies, just use this instead of "spawnGroup" and now whether they are on world A or B, they will spawn at the groupspawn set for them in world A.

<<reply 731910="">>

Regarding random spawn, HSP has a 'spawnLocalRandom' strategy that will pick a random spawn on the local world. The advantage is that you can integrate that in whatever way you like in your event strategies, rather than the blunt tool of "either HSP or anther plugin wins". If you do want to turn down HSP's priority so that another plugin can "win" the event location, you can do that too (there's a config option for it).

Regarding your question of per-permission/per-world precedence, HSP uses per-permission as the highest precedence because permission systems can turn permissions on/off for specific worlds. An example of how this could work is that instead of tying your per-permission strategies to a group, you might instead group them (to minimize confusion) into just 2 or 3 policies and tie them to a permission like "hsp.policy.1". For example:

<>
events:
permission:
policy1:
permissions:
- hsp.policy.1
onJoin:
....
<>

Now assign "hsp.policy.1" permission to the 2 or 3 groups that share that policy (it doesn't look like it's different for every group in your config). Or if it is different for each, consider using something like "hsp.group.supervisor", so the player can still be in "group.supervisor", but you can disable the "hsp.group.supervisor" permission on worlds you don't want it on.

Now on this other world where you want something else to happen (such as your other plugin to work instead), just use your permission system to remove the "hsp.policy.1" permission for that world.

I'll say right now that I won't help you with permission systems, they are their own set of problems/issues that I don't support, but suffice to say that most permission systems support this per-world permission concept and if you need help with that, you should ask the permission authors/supporters how you would go about doing that in your chosen permission system.

@deathwing911

Someone else had the same question a few pages back, so linking the answer here:

http://dev.bukkit.org/server-mods/homespawnplus/?page=6#c328

@empathdemon

Note that it's certainly possible to use per-permission strategies to emulate /groupspawn behavior in a more deterministic manner. For example:

events:
  permisson:
    entry1:
      permissions:
      - my.group.permission
      onGroupSpawnCommand:
      - spawnNamedspawn:groupSpawn1

in this example, rather than using /setgroupspawn, you would use "/setspawn groupSpawn1", and then assign the permission "my.group.permission" (which obviously is whatever permission you want it to be) to the group you want to use it.

I think this is actually a great example of where HSP's flexibility shines. While the core "/groupspawn" behavior doesn't map well to your use case, you can re-map the /groupspawn command to do whatever you want, in this case assign per-permission strategies that will work regardless of what the primary group is.

Note that HSP's per-permission strategies evaluate in deterministic FIFO order: the entries are evaluated in the order listed, so the first entry to match (a valid permission and strategy) will be the one executed for the given event.

@empathdemon

Regarding a 'primary group designation', I'm not aware of such. However, if you read the Permissions page for HSP, it documents how to specify a permission system. HSP includes support specifically for PEX (since I use it), so you could move that higher in the list to use direct PEX api calls instead of the Vault abstraction. The direct PEX integration just grabs the first group PEX returns, which should at least be a determinate ordering, so you can order your PEX groups according to which one you want returned (probably the first one in the list is returned).

Regarding the use of permissions, this pattern is generally followed throughout HSP, for example you'll note all the by-permission settings for events, costs, cooldowns, etc. The "groupspawn" feature was inherited from the original SpawnControl, which was based on the Perm2 notion of groups, which was a single primary group construct. I've never ported over this "permission" vs "primary group" concept to groupspawn; and while I certainly could undertake such an endeavor, you would immediately have challenges such as, what if a person is a member of 3 different groups, which one do you pick? It would require a different implementation to address this concern than what is there today.

I may tackle that some day, but for now, it is an interesting data point that you are the first user in about a year of HSP to ask for multiple groupspawn groups, so the feature finds itself among a small userbase considering the large amount of issues it raises to be done properly.

@empathdemon

A few questions there.

First regarding costs, yes the settings you pasted + Vault are all you need (of course an economy plugin behind Vault). If you are having problems, try turning on "core.debug" and see if the debug messages (in plugins/HomeSpawnPlus/debug.log) help you diagnose the problem further.

Regarding groups, HSP punts the handling to Vault or WEPIF (WorldEdit), so it supports whatever they do. The general case for HSP "groupspawn" is that it checks only one group. To say another way, HSP asks the permission system "What is this user's primary group?" and will act accordingly.

@GrumpleStache

Though I'm not sure of the root cause, the stack trace is saying there is a bug when trying to print the "insufficient funds" message. This is either a bug in the string localization that has never been encountered before (possible) or a problem with Vault and your economy plugin of choice. I'll look into it more later when I have the chance, please open a ticket, paste the stack trace there and include the details about your economy setup and also your HSP config.yml.

@HammyHavoc

The admin commands page documents the '/hspconvert' command:

http://dev.bukkit.org/server-mods/homespawnplus/pages/admin-command-reference/

@EndyHUN

Update what? HSP runs fine with the latest versions of Bukkit.