@Mon3y13ankeR

If it does not work with PEX groups then it must either be a configuration issue (on whatever side) or Essentials is doing something strange.

It could be that the back permission or another sub-permission is necessary to have the back position set at all ?

Some plugins checlk the permission at players death or whatever and if the permission is not present then later /back would not work, even if the permission is present then. But that is a wild guess , idon'T know hwat Essentials is doing on that account.

@Mon3y13ankeR

If Essentials uses the PEX interface for permission testing instead of the superperms interface then transient gorups won't work.

You could try to use PEX groups instead of transient groups. This makes it heavier but is as well possible. Only disadvantage is that using permission plugins groups might stay with the playerys after crashes or other problems, so be sure to use anextra group that is only used with RSP.

So you essentially would delete or comment out the transient-groups section and create a group in PES with the same name and permsisions.

That might work then. But i am not sure if that is really the reason ...

@Mon3y13ankeR

If essentials overrides the time command then it will be that...

@Mon3y13ankeR

CB/1.3.2/beta should be ok.

Does it work with time adding ?

@Mon3y13ankeR

The config gives players the permisison bukkit.command.time.add inside of the region test_rsp in the world named world.

Change the permission in the transient groups section to essentials.back instead.

Then you need to use the correct world and region name in the links section.

If the world is named PvPWorld then you have to write exactly that instead of world, if the region is named placeForBack then you need to use that instead of test_rsp.

@Mon3y13ankeR

What do you want to reach with RSP ? Maybe just describe what tasks there are and probably past/link your RSP config here...

@Dell341

Thx :)

@wiloh95

If you just want to let some users have permission to use shops inside of a certain region, while they don't have them everywhere else, you can also simply add the permissions with RSP during runtime, without need for negating permissions.

Example: Transient permissions with RSP

You create a group entry in transient-groups section containing the shop permissions, then you create a "permdef" that sets up the permission manipulation to have the group inside of somewhere in the permdefs section, then you link the permdef to a region in the links section. (See example.)

@asofold

Faster than i thought, but i freaked out and thought i had found a bug, but it was just malconfigured (might remove that groups: ... extra bit of typing), but anyway for now should do: RSP 1.1.0

Now you might use priorities with permdefs. And i might have to add examples without permissions plugins and for priorities.

I am not sure if the transient-groups are really 100% superperms compatible - the permission checks work for exact matching permissions, but they might not work for parent nodes yet.

Example for negating permissions: Negating permissions...
(Might still need review.)

@Remi_Scarlet

It is pretty difficult to have negated permissions work dynamically - with luck one could find a way to manipulate the order of groups to be set/added/remove such that the specific permissions plugin will value the negated permission higher than a given permission from another group the player is in anyway.

Negating a permission given by a permission plugin using RSP transient permissions does not seem to work, because of the design of Bukkit / CraftBukkit. (They did recently deny a feature request to add priorities to permissions adding with words like "it is not needed", but obvioulsy negating/conflicting permissions in the context of multiple permisison manipulating plugins poses problems by design.)

Anyway, i was thinking about this and i see two thinkable ways:

• Attempt to set the group order on changes such that the permission plugin values the groups added / removed by RSP always higher than all other groups the player was in anyway, potentially allowing top respect priorities assigned to permdefs.
• Add more permissions management to RSP, allowing for 100% reliable overriding (whichever way) of permissions, possibly also including priorities for permdefs or groups.
  This would/will make RSP half a permissions plugin, because you might have to define the groups in RSP, but assigning the groups will check prermissions the players must have been given before. For more convenience i might add a feature to add groups defined in your permissions plugin in a transient way (only during runtime), but such also demands a lot of internal changes.

Obviously the second way would demand a lot of changes to be done, and i would likely have/want to redesign the whole internals for that.

The first way might be somewhat easier to add, because it almost only involves the sorting of the groups to assign to the player and it can be made configurable if to add them first and in descending order etc.

Priorites of permdefs is will in some form be added.

Concerning the overlapping question, i probably wold not want to handle that by priorities only because they might be needed for the overriding question with negation etc., but i could imagine adding something like a list of permdefs to override for each permdef, such that if both are added the overriding entries allow to not have the other when in an overlapping region.
Update: Actually priorities could handle this using the remove-enter option, then remove-enter would really remove the group if it is added by a permdef with lower priority at the same time. As of now it would not get removed if another permdef is adding it.

Difficult to judge what i can add fast, probably the group ordering is the easiest - all other things might call for an internal redesign, after all this plugin had been made pretty quickly, after i saw that EvenPrime "took too long" for his PermissionZones, so the code is in parts very old and needs a design update for more flexibility, i tried to refactor parts but the success was not great up to now :)

So, err, good suggestions !