Bukkit

Running the plugin for the first time will generate the default configuration file rsp.yml .

• heuristic.lazy-dist: 5
  Block-distance which a player must take before getting rechecked for changing regions. Setting this to 0 will still be effective, but a value like 5 will lead to better performance, while too big values make it too inaccurate, probably. A value of zero means exact border detection (but also often adding and removing groups if people keep croosing that border, say for fun).
• player-cache.lifetime: 12345
  Lifetime in milliseconds of permission and region cache, which gets renewed after this time. A value around 12 seconds seems ok, if you are ok with changes to permissions getting delayed for a longer time to RSP, then set it to a higher value.
• stats.use: true
  Collect statistical data about events processing, print to console fairly often - [periods to be configurable]
• stats.log: false
  Since 0.11.7 release: Control if stats are logged to the console.
• stats.show.rnage: false
  Since 0.11.7 release: Control if stats show minimum and maximum values.
• permissions.save-at-all: false
  Since 0.12.0-DEV-6 this can be set to prevent any saving. Saving extra is unnecessary currently, it should be set to not save.
• permissions.saving-period: 0
  Period in seconds at which changed permissions get saved for players/worlds. Since 0.12.0-DEV-6 set to 0. Saving is not necessary.
• permissions.save.on-check: false
  Save permissions on having checked a players location, if groups have been added or removed. Not necessary to set.
• permissions.save.on-checkout: false
  Save permissions on checkout of a player, i.e. when all RSP-related permission groups get removed, for instance when the player leaves. Not necessary to set.
• permisisons.use-worlds: true
  This is used by Vault integration: You must set this to false for permission plugins like PermissionsBukkit, because Vault would not allow to manipulate groups for specific worlds for some plugins, or the plugins would not support it.
• permissions.lower-case.worlds (false) and permissions.lower-case.players (true)
  For some permissions plugins this might matter, RSP will perform permission checks and/or group manipulations with the player name in lower case letters, if the players flag is set to true, similar with worlds.
• errors.log.min-delay: 10000
  This is a period in milliseconds that will be waited from one log mesage to the next of the same kind, for certain kind of potentially very frequent errors (if permissions fail all the time it might be many, for instance).
• no-parking: false
  You can force RSP to always checkout immediately when a player leaves, for instance. Thus data would not get parked to wait for a possible quick relog, which might spare few checks. Usually the cache expiration happens anyway, in the current implementation this does not make too much of a difference, except that permission groups might get removed immediately if set.

More info and hints coming!

For world specific and confinement settings (since 0.9.2) see: Configuration/Worlds

Example configuration (RSP 0.12.0-DEV-4 / rsp.yml):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

# DEFAULT SETTINGS:
create-portals: false
errors:
    log:
        min-delay: 10000
stats:
    use: true
    show:
        range: false
    log: false
load-plugins: []
permissions:
    saving-period: 0
    save:
        on-check: false
        on-checkout: false
    lower-case:
        players: true
        worlds: false
    use-worlds: true
    save-at-all: false
player-cache:
    lifetime: 12345
no-parking: false
generic-links:
    ownership: []
    online: []
heuristic:
    lazy-dist: 5
confine:
    enabled: false

# EXAMPLE:
permdefs:
    test:
        ignore-perm: test.ignore
        filter-perm: test.filter
        have-inside: 
            groups:
            - RSP_TestFly
links:
    MainWorld:
        test_rsp:
        - test

The configuration is split into two basic steps:

• Define a permission manipulation (permdef), stating who can be affected by this permdef, and what shall be done with permission groups on entering / leaving a region.
• Link one or several permdefs to WorldGuard regions (links), to tell RSP for which regions which permdefs should apply.

With permdefs you define for a unique name a pemdef, with a filter-permission (only players that have this get groups assigned and removed), and an ignore permission (players with this permisssion get ignored, overrides the filter permission) and a definition of which groups to have when inside a linked region. Leave the permissions out if you want all players to be able to use that pemdef.

To tell the plugin on which regions to use which permdefs you can link regions to pemdefs with links, cascading world -> region-id -> List of permdef names. This way you can add several pemdefs to a single region, and you also only need to define a permdef once for a certain purpose, like having Flying permissions inside of the region.

Still be aware that different permission plugins (currently PermissionsEx, bPermissions) handle groups and worlds slightly differently. PermissionsEx can have a group that has different effects in different worlds, while bPermissions seems to assign groups on a per world basis (with a default world though). To be sure not to have different groups interfere too much dont have them have the same names, if in doubt.

All names of worlds, region-ids and pemdefs are CASE-SENSITIVE.
If you are using bPermissions, check if you have the lower-case all checked, because this means that you might have to use lower-case group names in the RSP configuration too.

EXAMPLE:

The example configuration above contains a permdef named 'test', defining that players with the permission test.ignore will not get affected, while those with the permission test.filter will get affected such as to have a permission group RSP_TestFly inside of regions this permdef is linked to (linking is done under links).

The section 'links' defines then that for the World MainWorld on the region test_rsp the permdef with the name test should be applied.

So players that have permission test.filter but don't have test.ignore will have the permission group RSP_TestFly inside the region test_rsp of the world MainWorld. Those players can not have the group outside of that region then (on top level, if it is part of an inheritance chain of groups, it might still be there, but that i would avoid.).

The permission group RSP_TestFly can then contain the permsisions for flying like nocheat bypasses and your flyplugin.use-flying-node. It is not recommendable to add permissions like there are for switching gamemode, for the permisison would be gone after leaving the region, but the effect might stay, like with changing to creative mode, while inside. (To do that you could hover hook your own plugin into RSP via the API and make sure people have set gamemode to SURVIVAL on leaving.)

Be sure to use special Group names to avoid unpleasant effects on crashes or bugs or similar, so that these groups are pretty safe to remove and easy to find (for instance like in the example with an RSP_ prefix).

There can occur conflicts with removeing and adding permissions - be sure that on multiple pemdefsthat apply for a spot, that they have different groups to add and remove.