@MiachBiatch

WorldGuard 5.4 should work but i wil lcheck what with 5.2.2...

@MiachBiatch

That looks like the WorldGuard version is ?older...

What version of WorldGuard are you using ?
I might add compatibility for an older version...

Which CraftBukkit version are you running?

@MiachBiatch

I would not necessarily call it a tutorial :)

Had to add something though - the definitions look quite ok, though the permdef name need not resemble a permission name it is just used internally to uniquely identify a permdef (...to reference it in the configuration with links, and for it could be queried by other plugins via the API, potentially).

I am not sure how about dotted keys, to be 100% sure you could use 'x.y.z' instead of x.y.z as key for the permdef to make sure it is interpreted as a string of characters, but this is probably just lack of knowledge on my side about YAML. (If this was a problem, RSP might complain while enabling, anyway).

@Flenix1

Ah, 0.7.0 *is* the hot beta/dev build...
I just call it hot because i decided to release it early, having a slight uncertainty about a) bPermissions at that time, and b) if users would make complicated setups that differ too much from the (so far) intended use.

Currently it seems to run very stable ...

If you are using bPermissions and are still having trouble you should post your rsp.yml and maybe the corresponding permisssion group definition - also check the server log for entries of rsp, it should state if it has hooked into bPermissions.

@ASWeiler

Test with the latest bPermissions version 2.7.8 (with auto-save on, which usually should not be recommended for world-specific saving to yml-files) and CB 1808:

• PASS: Startup, hook into bPermissions
• PASS: Adding and removing a permission group by configuration of RSP, no filter-perm set.
• PASS: Adding and removing a permission group by configuration of RSP, with filter-perm set.
• PASS: Deny adding permission group due to filter-perm not present.
• PASS: Deny adding permission group because the ignore perm is set.

It seems that 2.7.8 does not pose any problems, at first glance.

So, you are using bPermissions 2.4.. ? A short test showed to me that it too works.

Are you sure you did not mix up permission group definition with RSP configuration (permdefs, links) ?
I might give more permission definition examples...

@ASWeiler

I will have a look, probably the API differs for different versions of bPermissions - what kind of problems are you encountering ?

@Flenix1

Yes, you can set up the filter-perm for a permdef - then only players that have the filter-perm will get the groups added or removed.

Similarly you can set the ignore-perm to ensure that players who have that will not be bothered by the effects of that permdef.

Here is an example for assigning a group TestFly to people that are inside of the maintown region (rsp.yml):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

permdefs:
    MainTownFly:
        ignore-perm: rsp.ignore
        filter-perm: rsp.custom.maintown.fly
        have-inside:
            groups:
            - TestFly
links:
    MainWorld:
        maintown:
        - MainTownFly

The permdef MainTownFly has both the ignore-perm and the filter-perm set.
So all people that have the permission rsp.custom.maintown.fly will have the permission group TestFly inside of the maintown area (that is done by linking the permdef under links).

I just chose "rsp.custom..." to indicate that the permission is for use with rsp, it is arbitrary of course.

I should probably add, that if you want high accuracy in terms of block distance to the region, you might have to set lazy-dist to 0, which will cause more region checks and thus cost a bit more of performance, but lead to exact region-linking. A lazy-dist of 0 still guarantees that afk people wont cost more performance.

I would appreciate any kind of feedback, especially if it does not work out !

@Sayshal

What do you refer to by permissions blocking ?

I really intend to use groups as addon-collections of permissions, and the server-admin defines the groups, so the admin has the control over prefixes.

Example would be to add flying, juts define to use group "RSPFly1" for players inside the region, in your permissions setup you define that group to just have the permissions necessary for the flying. If some players already have flying, you can then set an ignore-permission for those groups or players like "rsp.custom.rspfly1.ignore" or something simpler, so unnecessary adding of RSPFly1 will be prevented. To prevent complications the normal flying groups (not to be added by RSP) should have other names like "NormalFly" then these things won't interfere.

I could make it so it will remove or add single permissions, but the drawback is that checking if a player has or has not a permission usually does not reveal if the permission had been given to the player explicitely or just is there due to inheritance of groups.

I will rather not remove inherited permissions, and that is the reason why i am working with groups, because for those it can be checked if they're present on "top-level" for a player (not 100% sure about bPermissions at present).

For this approach i am not regarding groups as "clan definitions" or similar but as an abstract concept to group permission nodes.

Depending on the permissions plugin one might be able to add "negated permission nodes" to negate effects of inherited permissions, but i am not sure how different plugins handle the priority of negated nodes, concerning which is checked first (the given one or the negated one), so i will not focus on these aspects.

I hardly will be able to release this (in a configurable state) before next week, though.

@Sayshal

It just assigns an extra group and would only remove that one - if you choose those groups carefully (once it is configurable), then the prefixes should be determined by an already present group that has defined a prefix. This is valid if your permission plugin allows multiple groups per player.

I will provide examples for usage, and have a look into bPermissions as well.