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.
Also, quick question:
Is there a way so a region could permananlty give a permission when entering? or maybe you know another way to do this:
I want people to be able to find a zone, and once found they can teleport there from another location - the location (a guild) can teleport you to any of these locations (shrines), but only the ones you've found. Any ideas?
@Flenix1
Ok it might be fixed now use:
RSP 0.10. - beta/dev
@Flenix1 Thank you for reporting, i found a bug, which might be related, and it is a surprise to me that a) it has not been reported before, because it was introduced in a "compatibility hot fix", which due to this bug was not fixing anything, if i am not mixing thinks up right now. b) you have this problem with one of the latest WorldGuard versions (and it did not happen on my tests/server(s), while i have/had the same version on, presumably).
I dare not try to derive from 0.9.2 and fix it there, so i will release 0.10.0 which does the same with the same configuration, but also allows for some other uses.
Expect it today or tomorrow...
@asofold
0.9.2 beta/dev of RSP,
Craftbukkit + +, version 169 (It's on 1.2.3 - not sure what the relevant CB version is)
WorldGuard: 5.5.2-SNAPSHOT
@Flenix1
That looks like RSP is not finding WorldGuard - currently it does depend on WorldGuard, do you have that installed?
If not ... "solved" :) - if installed, then i would like to know the versions of CraftBukkit (or whatever you are using) RSP and WorldGuard , and Per,mission plugin!
Seems to spam the server with:
"rsp - Checkout on WorldGuard missing [Name]"
Any ideas? Literally does 10 of that message a second... per player.
@muhgatus
Hi,
that looks like a good way to show an example for RSP,
i have made a thread in the forum for the time being (examples might get their own pages later on).
I like the presentation of the Sandbox definition, though one probably could make it even more simple, see forum: Discussion of "Building a Sandbox"
Building a Sandbox
Versions
PermissionEx
The group should have no right to build, but also shouln'd have the "negative right" to build. Simply keep it out, so they cannot build because the permission is not found. You should handle the right to build via permissions. In this case it is called *modifyworld*.
The Sandbox is placed in a world called MyGreatWorld.
Worldguard settings
This is our sandbox in top-view
1 and 2 are the build areas. 3 is the outerarea which stops the players from modifiing the outside world. because the actions of the player must not be within the 1 and 2 region.
Region definition.
RSP settings
That's all. This is a working sandbox!
@ASWeiler
Thank you, i appreciate testing and feedback !
I am going to test this with bPermissions 2.9.0 (R6) and World Guard 5.5. I will get back to you as soon as the test is done.
@asofold
I Still don't know what exactly you were asking :) ...
If you want to have a random choice ... that is another thing (not yet possible, but thinkable).
I could add an option like add-randomly: true, or add-randomly: 3 (3 out of ... will be added randomly).
Then one could make a region that removes all jobs on entering, and assigns one or more on exiting.
I like that, but iwill probably not add it in the version i am working on right now.
@morizuki
It depends on what you want.
Do you want the players to keep the job outside of the region ?
It is not yet possible to have groups just removed or just added without caring for what to happpen if players leave the region. The main reason for not having added that to the configuration is, that it could potentially lead to inconsistent permission states , also in case of bugs.
But the base for that is already built in, i might update soon.
If you just want them to be archer or swordsman while they are inside of the region, depending on what they were before, then that would be possible.
just a question
-Let say, A novice goes into a particular region called Jobs_Change and I want him to become a Swordsman and another novice goes into Jobs_Change and I want him to become a Archer.. is that possible?
@asofold
Thank you very much for looking into it. I figured out what was wrong thanks to your test case. I noticed that everything in the test case was in lower case, so I tried making my "RSP_Test" group lower case as well in both my groups.yml and my rsp.yml file, and that solved the issue. It might have something to do with the lower-case all option in bPermissions. (Which I have turned on.) Thanks again, this is a fantastic plugin.
@Regal0wl
I did a quick test with CB 1847 and bPermissions 2.7.8 and WorldGuard 5.4, and it worked without problems on lazydist 1.
Maybe check again if you did not test as op or admin, if the group contains the ignore-permission, and if all world, region, group names in the rsp.yml are matching exactly the definitions in WorldGuard / bPermissions, the resp-configuration is case-sensitive.
(If the permission gets added and not removed, though, it looks like a bug, some side-effect.)
Here rsp.yml and groups.yml with which i tested:
@Regal0wl
Your understanding seems accurate.
the saving settings are for saving changed permissions, i have to update the documentation.
saving-period is a general period in seconds at which all changed permissions will be saved to disk. save.on-check is for saving directly when the player gets groups added or removed, save.on-checkout will save when a player leaves or the plugin gets disabled and maybe on cache-lifetime expiration - those settings may well be set to false / 0, the worst that can happen is, that due to another plugin or a command issuing a bPermissions save could lead to a player having an RSP-related group on disk, while they should probably not have it. If that group is still part of the RSP configuration then it will be removed when the player joins again, if not then you have an inconsistent state (that is one of the reasons, why i recommend to use permission group names that are related to RSP and can easily be distinguished from normal groups, if necessary).
Question is if you had special op-permissions or not, and if the permission group itself contains the ignore-permission for instance...
I have heard about changed permission behaviour in some bukkit builds, i will have a look ...
I'm having trouble getting this to work with bPermissions 2.7.9 and WorldGuard 5.4. I'm not sure if I'm doing something wrong or if it is a bug. Here is my rsp.yml file:
Here is my understanding of how this works: I give a user that I want to be affected by the permdef the rsp.test.filter permission and I give a user that I don't want to be affected the rsp.test.ignore permission. I create a region with Worldguard defined as "spawn". At that point, any user that enters the spawn region should have the "RSP_Test" group assigned to them. (The "RSP_Test" group is a group defined in my bPermissions groups.yml file.) And then the "RSP_Test" group should be removed when they exit the spawn region. Is my understanding accurate?
What actually happens when I use this setup is that the "RSP_Test" group is successfully applied when entering the "test" WorldGuard region. However, upon leaving the "test" region the permission group is never removed no matter how long I wait. So after I go into the "test" region, all the permissions of the "RSP_Test" group are permanently assigned to me. I have tried changing the player cache lifetime, the lazy-dist, and the on-check and on-checkout save, all with no effect on this issue. I'm uncertain what the "on-check" and "on-checkout" options do, as I couldn't find them anywhere in the configuration information. I get no console errors. I'm running Craftbukkit build 1846. However, this problem also occurred on 1.1 R1 and 1.1 R2.
Am I doing something wrong, or is this a bug? Thanks in advance.
@Wardool
As it seems PermissionsBukkit does not provide an API for manipulating permission groups or users permissions - from the Plugin side it is read-only.
So i can not support PErmissionsBukkit directly.
If i should add general SuperPerms support then it might work for you.
Maybe you want to contact Evenprime85 who wrote a plugin that might work for you, check the Ticket Nocheat regions of the plugin NoCheat for that:
http://dev.bukkit.org/server-mods/nocheat/tickets/23-nocheat-regions/
@Wardool
If you refer to the Plugin PermissionBukkit, i might quickly adapt, but general superperms support i will probably not provide, because i focus on permissions plugins group API, to reduce developement time.
I will have a look...
Hi,
Your plugin will be compatible with PermissionsBukkit in future update?
Sorry for the bad english I'm french :D (And google traduction ...)