Bukkit

@fragger505

And just to follow up, I have backup copies of old versions of the database I keep around just for testing the upgrade, here's an upgrade test all the way from the very first version of the database (v0.6.2) to the most current version:

# server.log
2012-02-25 [INFO] [HomeSpawnPlus] Loading HomeSpawnPlus v1.4.2.
2012-02-25 [INFO] [HomeSpawnPlus] Loaded 64 locale strings (1 overrides)
2012-02-25 [INFO] [HomeSpawnPlus] Upgrading from version 0.6.2 database to version 0.6.3
2012-02-25 [INFO] [HomeSpawnPlus] Upgrade from version 0.6.2 database to version 0.6.3 complete
2012-02-25 [INFO] [HomeSpawnPlus] Upgrading from version 0.6.3 database to version 0.8
2012-02-25 [INFO] [HomeSpawnPlus] Upgrade from version 0.6.3 database to version 0.8 complete
2012-02-25 [INFO] [HomeSpawnPlus] Upgrading from version 0.8 database to version 0.9.1
2012-02-25 [INFO] [HomeSpawnPlus] Upgrade from version 0.8 database to version 0.9.1 complete

@fragger505

Looks to be MySQL? I'm not sure, I worked hard and tested the DB upgrades extensively, they've worked in all my tests and that code hasn't changed. If you can take a backup of your hsp_* tables (there are 4 of them) and zip/tar them up and send me a file, I'll be happy to test the same thing locally and see if I can pinpoint the issue, or at the very least tell you what to run to manually fix any issue.

@HeavenMc

Sorry, I'm not sure what's going on then. I have seen weird issues where PEX doesn't return 'true' to permissions nodes that are listed in the permissions.yml file (I run PEX myself and this is a very annoying bug). There is a PEX command for checking that.

The other thing you might try is monkeying with the 'permissions:' config item, you have 4 options for interacting with PEX: Vault, WEPIF (WorldEdit), PEX and Superperms. It's possible HSP is using one of those (say, Vault, for example) that has a bug with PEX. You can try changing the order to use a different one of the 4 and see if you see different results.

What I can tell you from the debug.log is that the user "HeavenMc" is returning "false" when the permission system is asked if that user has the permission "group.Admin", "group.Neuling", etc. I don't know why that is, but if you figure that out, things should start working for you.

@HeavenMc

According to the debug.log you posted, none of the permissions are matching and so it is picking up the default value of 1. I don't know what permission system you are using, but you need to be sure to assign the actual permission "group.Neuling" to your "Neuling" group; no permission system (that I'm aware of) does this for you automatically.

Imagine for a moment, instead of using permission "group.Neuling" you instead called the permission "homeLimit.1"; you'd still have to assign "homeLimit.1" to the groups you wanted to have that homelimit. (btw, that's perfectly valid; HSP doesn't care what you call the permission or how you set it up, it just checks for what you tell it to)

@HeavenMc

Must be a permission issue, then. Use your permission system to confirm the players have the matching permission.

If that all checks out, another thing you can do is add a "core.debug" flag in config.yml and set it to true, HSP will log debug messages into "HomeSpawnPlus/debug.log". Try the /sethome command as one of the other permissions, you should see it evaluating the "per-permission" home limits and it will very verbosely describe checking each permission. Messages like: "found limit section limit5, checking permissions for section" and "checking permission perm for player player".

@HeavenMc

Heh, well if it worked, then you have it right ;) And yes, looking at your pastebin, that is exactly what I was saying. Should be good to go.

@HeavenMc

Reverse the order of your limits definition in your config.yml. HSP matches on the first one it finds. It's most common that your "group.XXX" permissions propagate upward, so members of "group.Admin" also have your "group.Neuling" permissions. HSP sees the match for "group.Neuling" and stops. Put your "group.Admin" definition first and so on, and you should be fine.

@fragger505

The short answer from my perspective: yes. Superperms was well-intentioned but fell short of the goal. Fortunately, Vault stepped in where it fell short and has mostly smoothed over the rough spots; but now that's 2 plugins instead of 1 that has to be maintained and kept up to date (your permission plugin of choice + Vault).

Of course, I'm biased here; as a developer and administrator, superperms has caused me extra work with no benefit over the whole length of the transition; whereas Perm2 was just a single, simple JAR that just worked and did so well. I regularly get people complaining about a plugin not working and it ends up being some incompatibility with the newest bPerms, or PEX or Vault or whatever. I never had that issue with Perm2, it either just worked or they had it configured wrong.

Now that we're through the "rough spot" where we had two competing Permission standards (Perm2 and superperms), I'd say for the average admin things are about the same. But it seemed like a whole lot of churn in both the dev & admin community to just arrive at "things are about the same".