Region specific permissions
Region Specific Permissions (RSP) allows to add and remove permissions dynamically, using WorldGuard regions as reference. Also useful to limit your worlds to a rectangular or circular zone around an arbitrary center! Currently you need WorldGuard for regions.
Maintenance Phase
Due to timing constraints i might not add much to this plugin, but can keep it updated.
I might implement some features of pex to make this a fully featured permissions plugin, t would be somewhat optional and RSP still would be able to use hooking into other plugins. However that is quite a task and i am not sure if i will do it, or if i want to rely on another permissions plugin, since pex might time out.
Quick links: Installation | Configuration | Commands | Troubleshooting | Examples
Internals: Performance | Progress | Changelog | Source Code on GitHub
REQUIREMENTS:
- WorldGuard
Since version 1.1.0 you don't need a permissions plugin anymore to operate RSP.
Compatible permissions plugins:
- PermissionsEx or
- bPermissions or
- Since 0.12.0:
Vault, linking to another permissions plugin - however it is not guaranteed, that your permission plugin supports adding or removing groups during runtime. Furthermore you might have to alter the RSP settings to achieve compatibility via Vault.
Should work without adaption (or despite): PermissionsBukkit (RSP 0.12.0)
This plugin actually adds and removes permission groups, either those defined by the permissions plugin or those given in the RSP configuration in the transient-groups section.
Actually RSP has more to it than "just" permission adaption for regions, it also allows to confine your worlds to circular or rectangular areas with arbitrary center, to limit your maps.
See the Configuration link for more specific information and the Troubleshooting link for examples and hints. Both sections are under review and will be updated more or less soon.
IT FREAKING WORKS!!!! (bPermissions 2.7.3). I <3 this so much!
@MiachBiatch
WorldGuard 5.4 should work but i wil lcheck what with 5.2.2...
I am running the latest dev build of CraftBukkit, the WorldGuard is 5.2.2. Could you plese make a config for me, just the setup, based on the info I gave you? Also, can you add me on skype to write there instead? My skype account is "jonas.fjellhaug"
Thanks! :)
@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).
Also I get these errors when I log in when I have installed your plugin:
Hi mate! I really need this plugin, and I have no idea how to configurate it, because Ive never seen a configuration tutorial messed up like that, haha sorry but true!
Could you please set up the config-file for me based on this info?
INFO:
THIS IS HOW I TRIED TO DO IT:
Can you please set it up for me? Thanks in advance! :)
@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.
@asofold EDITED. Never mind, I hadn't checked the OP recently :) Although I would like a copy of that dev build which all "PASS" on :)
@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:
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 ?
Well I took a crack at it and since PermissionsEx and bPerms work so vastly different (like bPerms barely even added meta which kinda resembles the ability to have things like ignore-perm: rsp.ignore, but we sure don't have any way to "make our own perm" like permissionsex does. The best way for you to understand well is to try bPermissions out yourself. I suggest testing on 2.1.4b rather than the newer ones just cause most people use that one and the newest has still thing to work out. If you can find a way to get this to work with bPermissions I would die happy. I am more than glad to test anything out on a scale of about 10-20 ppl online at a time. I really need this kind of plugin so I wish you the best of luck.
Thank you
@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):
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.
Would it be possible to only give the permissions node, if they already have another one?
permisception :)
I want to make people have to go to a certain area to craft SpoutMat runes - easy enough to do with this plugin. However, I then only want certain people to be able to do that. I think I can block other people going in at all, but thats no fun... I want others to be able to explore these aincent structures just not craft in them
I would appreciate any kind of feedback, especially if it does not work out !
I would LOVE to test for bPermissions. I really need this for my server so bad and I hate PermissionsEX
-edit- I am testing it right now as is, will get back to you on it asap
@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.
Will test when this supports: a) bPermissions b) Permissions blocking, not just changing group. (Messes up prefixes)