Bukkit

1.9.1

Since the RSP 1.9.0 release, some internal API has been changed (!), for the case you have a custom plugin hooking into RSP.

• Fixes
  • Fix letter-case issue with players.yml - now should be case-insensitive.

Conflicts with earlier version of Bukkit and offline-mode servers could be the use of UUIDs internally, amongst general API incompatibility, so it's a matter of testing it, or using an earlier version of RSP.

REQUIRES:

• WorldGuard (this version might run without it, though).

Compatible permissions plugins:

• PermissionsEx
• bPermissions
• Vault - 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-DEV-4)
• (no plugin: No data is saved, but you can dynamically assign permissions based on regions, worlds, ownership of regions etc.)

• Teleporting and respawning: At the time of the event-processing, the player is still at the old position. RSP does check the changes/permissions for the target location, however some filter permissions might not be 100% under control if other plugin alter those too. Thus RSP performs a delayed re-check now, though still a minimal uncertainty might remain with commands being executed after the server-side teleport but before the delayed re-check. For most cases this has no relevance, also the player has to "spam" the command beforehand to hit the gap (< 50 milliseconds usually). If critical command-related permissions are handled within RSP, this should not be an issue.
• Vault+PermissionsBukkit might lead to a lot of log messages, this will be fixed lateron, by hooking into PermissionsBukkit directly, or by Vault.
• transient-groups and parent-nodes of permissions: Currently negations of permissions will not override the already present permission for the case of same priority. This might be changed in future, for the case that a permission node contains a permission as child, and another node is added with the same priority to un-negate it. Here the order of appearance might be a useful concept, because these appear in the same transient-group, thus priorities have no effect.