RSP 1.9.2
Details
-
Filenamersp.jar
-
Uploaded by
-
UploadedAug 16, 2015
-
Size147.22 KB
-
Downloads1,167
-
MD507c67975bd9b4bdd213b6ccc43ee9b5e
Supported Bukkit Versions
- 1.8
Changelog
1.9.2
- Update to 1.8.8, update dependencies to "now".
- Supposedly minor internal changes for consistency.
For offline mode, static config permissions for individual players are a danger, because the UUID will be the same for anyone who'd join with the same name. If you use another permission plugin for filter permissions, danger depends on the other plugin.
Compatbile region plugins:
- WorldGuard
- (no plugin: you can only assign static permissions to individual players via configuration.)
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, or statically based on configuration.)
- 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.