Bukkit

1.9.0

This release is breaking some internal API (!), for the case you have a custom plugin hooking into RSP.

• HOT
  • Add (global) per-player group setup, allowing to give certain players transient groups by default, including priority. This is to be seen as "experimental", no commands to manipulate those yet, no extras, uuid-safe storage (see docs on players.yml) .
    Bug: Names have to be lower-case in the players.yml file, initially. RSP will switch to the UUID for data storage, on the next time the player joins the server, the name will be referenced from within the data section then.
• New
  • Reduce dependency on WorldGuard (might run without it, but doesn't support anything else yet).
• Internals
  • "UUID-safety" built in (uuids are stored with names, remove conflicting entries, thus not strictly fully transparent uuid-support yet).
  • As a consequence of default per-player groups, groups are cleared on checkout now.
  • Minor internal changes (consistency, refactor, project folder structure).
  • Compiled with 1.7.10.

Not sure this works with earlier Bukkit versions, no big changes, but never know...

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.)

• Names used instead of UUIDs in the players.yml file must be lower-case, otherwise RSP won't recognize the player. Once recognized, the data will be stored by UUID instead of the name, and the (correct-case) name will be stored under the extra key "name" within the data section.
• 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.