Bukkit

@fragger505

Yes this is easily possible and no, there are no performance implications to this. The performance implications are if you use a superperms plugin (such as PermissionsBukkit) without a wrapper interface like Vault and you want to use the "groupspawn" feature. Superperms has no concept of groups, so the only way to "ask" superperms what group a person is in is to iterate through every single permission (of possibly hundreds) checking for any node that starts with "group.".

To accomplish what you're looking for, something like:

#config.yml
homeLimits:
  permission:
    limit1:
      permissions:
        - homeLimits.1
      perWorld: 1
    limit5:
      permissions:
        - homeLimits.5
      perWorld: 5
    ...

After this, assigning homeLimits.1 or homeLimits.5 to a user or group will result in the matching limit being applied. Please note that the first one found wins, so if you want a user who has both a ".1" and ".5" permission to have the 5, then you need to list the limit5 first in your config.yml

@Zazeca

This message (with respect to 5.2) is actually a bug that is fixed in the next version (dropbox link in comments below, release soon). The intent of the message was to tell people running on old 4.7x versions that WEPIF was no longer supported on those versions, since the authors of WorldEdit changed the way WEPIF worked between versions. Unfortunately, there was a bug in HSP that results the message printing on release versions (5.1, 5.2) that has since been fixed; your version of WE is plenty current.

Separately, instead of getting snippety with the authors of plugins ("I don't need to be told when to update my other plugins, I am quite capable of browsing all the BukkitDev pages of the plugins ") who spend their free time writing plugins that you enjoy using, I suggest a more productive course of action would be that you learn to code and fix these "irritations" yourself and send a patch. Not only would that fix the issue but it would be a nice way of saying thank you to the authors by contributing back to what they've given you freely.

@dogbig

There is a ticket open for adding MyHome support, but it's only ever been voted down. I think the general consensus is people would rather I spend my time building new features than working on that import.

That said, there are imports from Essentials and SpawnControl which would serve as great examples for someone that wanted to write a MyHome import; the only think you really have to code is the ability to read the MyHome data format to do the import, everything else is already there.

@andune

In fact, I've gone ahead and bundled it up as 1.4.2-dev for now, you can access it at the Dropbox link. I understand the latest Bukkit dev builds are already breaking the old event model (ie. R5 pre-release), so if a few folks want to test this new version against the latest dev builds and report back here, I will promote it to the release version if it's A-OK.

@thernztrom

The released version (1.4.1), is not R5-ready no. However, I've already made and checked in the necessary changes to the github repository so I will release a new version when needed.

@SouthPark16

This means there will be a stack trace in your server.log. Please use pastebin.com to upload the stack trace and put a link here. I can then take a look at the problem and begin to tell you what might be going on.

@LEOcab

I haven't tested the Essentials conversion since Essentials 2.3. It's entirely possible/likely the format has changed since then. I used to be an Essentials user long ago (oh the shame), which is why I wrote the conversion in the first place.

The class that manages the conversions is well-encapsulated, so if you want to take a crack at updating it for Essentials 2.8, please feel free:

https://github.com/morganm/HomeSpawnPlus/blob/master/src/main/java/org/morganm/homespawnplus/convert/Essentials23.java

You're also welcome to post an enhancement request for an updated conversion if you can't write it yourself and if I get enough votes I might consider updating it.

@LtSich

It's possible that's a bug with fresh install. HSP has code that helps existing users upgrade from one version of the DB to others. I haven't tested fresh install in a bit; last I tested it worked fine, but perhaps a bug creeped in.

It's a little odd that this would be the first report since I've seen since it's been a while since I last upgraded the DB, but looking at your error, that shouldn't happen in any case. What I would recommend is deleting your "plugins/HomeSpawnPlus/HomeSpawnPlus.db" file (while the server is offline) and restarting; I'm assuming you're not using MySQL in your bukkit.yml.

If, after doing that, it's still returning the error, then please report back and I'll do some testing on my side and see if I can reproduce the issue.

@jefe323

HSP "by-permission" sections are "first found permission wins". This is the documented behavior, however a bug a previous version (<1.3 I think) had this backwards, such that it was looping through all permissions and the last permission won.

It's likely if you are using PEX group inheritance (most people do), that all permissions are propagating upward and this is usually what you want. However, this also means "group.Guest" is inherited by every group up the chain. This can be a good thing, but in this case it means that even your Admin group has "group.Guest" permission, so HSP starts evaluating per-permission, sees "group.Guest" on your Admin user, and thus your Admin has 0,0.

The way to fix is just to reverse the order listed. Start with your highest precedent permission first (Owner, Admin, Moderator, etc). You don't even have to change the "limit" names, HSP doesn't care about those. Just put limit14 at the top and so on down and it should work as you are expecting it to.

Also it's worth noting you can simplify your config (if you want to) like so:

# config.yml
homeLimits:
  permission:
    limitX:
      permissions:
        - group.Moderator
        - group.Admin
        - group.Owner
     perWorld: -1
     global: -1

Which is just pointing out that if the perWorld/global are the same (as in this example), you can just list all the permissions in one entry. Both work fine so up to you how you want to manage it. :)