RSP 1.7.2

Details

  • Filename
    rsp.jar
  • Uploaded by
  • Uploaded
    Sep 4, 2013
  • Size
    130.37 KB
  • Downloads
    1,469
  • MD5
    64dfc65aeb016234ac7f9429d6a8e1de

Supported Bukkit Versions

  • 1.6.2

Changelog

1.7.2

  • Add per-permdef lazy-dist. Can be used to increase accuracy within a container region, to get enter/leave exactly for a sub-region, or to get more precision on exiting.
  • Add tab-completion to commands (and permissions to plugin.yml).
  • Add player-infos to the info command: "rsp info [player1 player2 ...], showing lazy-dist, links and transient-groups for players.
  • Add a command to re-check a player "rsp recheck". Likely this is not needed anymore, but together with "rsp info PLAYER" it might help tracking bugs / problems better. Ensures checking a player.
  • Fixes and alterations for consistency (e.g. delayed re-checking after teleports and respawn, full re-checking of active groups on changes or cache expiration).
  • Handle with care: option for heavy re-check for the delayed checking.
  • Compiled with 1.6.2

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


REQUIRES:

  • WorldGuard

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.