[ADMN/DEV] PermissionsBukkit v2.0 - Official Default Groups Plugin [1.5.2-R1.0]

Discussion in 'Archived: Plugin Releases' started by SpaceManiac, Jul 17, 2011.

  1. Offline


    PermissionsBukkit - the Official Default Groups Plugin
    Current Version: v2.0
    Find PermissionsBukkit on BukkitDev!

    If you are getting a specific error or cannot determine what is wrong with your permissions file, filing a ticket on BukkitDev will make me much more likely to respond to you; general questions are best to ask in this thread or on the forums on BukkitDev.

    It's been a long time coming, but with the accomplishment of build 1000 Bukkit has finally accomplished a built-in Permissions system (codenamed Superperms). For more info on how they work, and how to integrate them with your plugin, see the official Permissions FAQ. Keep in mind that you should rarely, if ever, have to hook this plugin directly; instead keep things in the realm of checking player.hasPermission("yourplugin.node"). The FAQ thread has more info on how to use Superperms with things like chat prefixes/suffixes.

    • Storage of users and groups in plugins/PermissionsBukkit/config.yml.
    • Both users and groups can be assigned individual permissions and parent groups to inherit permissions from.
    • Support for global and per-world permissions.
    • Reload configuration from file with out reloading the plugin.
    • Ability to check if a player has a specific permission node.
    • Ability to dump all permissions a player has and the plugins that set them.
    • Ability to print plugin, description, and default for a given permission node.
    • Ability to modify the permissions of groups and users and the groups of a user in-game.
    • Built-in antibuild via the "permissions.build" node (defaults to allowing anyone to build).
    • A minimalistic bridge from Permissions 3.0 to Superperms is available as a separate plugin, which does not depend on PermissionsBukkit.
    Command Usage:

    Show Spoiler
    PermissionsBukkit uses the command /permissions, with aliases /perms and /perm.

    /permissions reload - reload the configuration from disk.
    /permissions check <node> [player] - check if a player or the sender has a permission (any plugin).
    /permissions info <node> - prints information on a specific permission.
    /permissions dump [player] [page] - prints info about a player's (or the sender's) permissions.
    /permissions setrank <player> <group> - set a player to be in a group with per-group permissions.
    /permissions group - list group-related commands.
    /permissions group list - list all groups.
    /permissions group players <group> - list players in a group.
    /permissions group setperm <group> <[world:]node> [true|false] - set a permission on a group.
    /permissions group unsetperm <group> <[world:]node> - unset a permission on a group.
    /permissions player - list player-related commands.
    /permissions player groups <player> - list groups a player is in.
    /permissions player setgroup <player> <group,...> - set a player to be in only the given groups.
    /permissions player addgroup <player> <group> - add a player to a group.
    /permissions player removegroup <player> <group> - remove a player from a group.
    /permissions player setperm <player> <[world:]node> [true|false] - set a permission on a player.
    /permissions player unsetperm <player> <[world:]node> - unset a permission on a player.

    All commands have in-game help and are usable from the server console.

    Show Spoiler
    A permission node is a string like 'permissions.build', usually starting with the name of the plugin. Refer to a plugin's documentation for what permissions it cares about. Each node should be followed by true to grant that permission or false to revoke it, as in 'permissions.build: true'. Some plugins provide permission nodes that map to a group of permissions - for example, PermissionsBukkit has 'permissions.*', which automatically grants permissions for all PermissionsBukkit commands. You can also specify false for permissions of this type.

    Users inherit permissions from the groups they are a part of. If a user is not specified here, or does not have a 'groups' node, they will be in the group 'default'. Permissions for individual users may also be specified by using a 'permissions' node with a list of permission nodes, which will override their group permissions. World permissions may be assigned to users with a 'worlds:' entry.

    Groups can be assigned to players and all their permissions will also be assigned to those players. Groups can also inherit permissions from other groups. Like user permissions, groups may override the permissions of their parent group(s). Unlike users, groups do NOT automatically inherit from default. World permissions may be assigned to groups with a 'worlds:' entry.

    The cannot-build message is configurable. If it is left blank, no message will be displayed to the player if PermissionsBukkit prevents them from building, digging, or interacting with a block. Use '&' characters to signify color codes.

    An example configuration file might look like this:
                permissions.example: true
            - admin
                permissions.build: false
                permissions.*: true
            - user
                permissions.build: true
                    coolplugin.item: true
            - default
        build: '&cYou do not have permission to build here.'

    Show Spoiler
    PermissionsBukkit checks for the following permission nodes:
    • permissions.build - Allows a player to build. Defaults to true.
    • permissions.help - Allows viewing of usage for /permissions.
    • permissions.reload - Allows use of /permissions reload.
    • permissions.check - Allows use of /permissions reload.
    • permissions.info - Allows use of /permissions reload.
    • permissions.dump - Allows use of /permissions reload.
    • permissions.group.help - Allows viewing of usage for /permissions group.
    • permissions.group.list - Allows use of /permissions group list.
    • permissions.group.players - Allows use of /permissions group players.
    • permissions.group.setperm - Allows use of /permissions group setperm.
    • permissions.group.unsetperm - Allows use of /permissions group unsetperm.
    • permissions.player.help - Allows viewing of usage for /permissions player
    • permissions.player.groups - Allows use of /permissions player groups.
    • permissions.player.setgroup - Allows use of /permissions player setgroup.
    • permissions.player.addgroup - Allows use of /permissions player addgroup.
    • permissions.player.removegroup - Allows use of /permissions player removegroup.
    • permissions.player.setperm - Allows use of /permissions player addgroup.
    • permissions.player.unsetperm - Allows use of /permissions player removegroup.
    Also, the following parent nodes are provided for convenience:

    • permissions.* - Maps to permissions.help, .reload, .check, .info, .dump, and to permissions.group.* and permissions.player.*. Defaults to op.
    • permissions.group.* - Maps to permissions.group.help, .list, .players, .setperm, and .unsetperm.
    • permissions.player.* - Maps to permissions.player.help, .groups, .setgroup, .addgroup, .removegroup, .setperm, and .unsetperm.

    Frequently Asked Questions:
    1. Where are my * nodes? (open)
    Bukkit's Superperms has no built-in concept of a global '*' node that automatically gives all permissions, which is intentional - a player can instead be given all permissions by being given 'op' status (that is, listed in ops.txt). Additionally, individual plugins define a parent node (which could be 'pluginname.*' or 'pluginname.all' or anything else) which maps to whatever subpermissions in that plugin the author desires.

    An example is PermissionsBukkit, which provides three such permissions: 'permissions.group.*' for all /permissions group commands, 'permissions.player.*' for all /permissions player commands, and'permissions.*' for all /permissions commands (including permissions.group.* and permissions.player.*).

    If you are using SuperpermsBridge, you can do something similar to '*' nodes for plugins which use Permissions 2.7/3.1 - see the next FAQ for more information.
    2. How do I use SuperpermsBridge? (open)
    SuperpermsBridge is kind of like FakePermissions for GroupManager or PermissionsBridge for PermissionsEx. Once it's installed, it pretends to be the Permissions plugin and converts any plugins that use Permissions 2.7 or Permissions 3.1 to use Superperms instead.

    You can have PermissionsBukkit without SuperpermsBridge or SuperpermsBridge without PermissionsBukkit if you like, but both of these are limited in functionality. If you install SuperpermsBridge without PermissionsBukkit you will not be able to make use of PermissionsBukkit's groups feature or admin commands, and if you install PermissionsBukkit without SuperpermsBridge, plugins that have not updated to use Superperms directly will not function.

    For plugins that use Permissions 2.7/3.1, you can use the special node 'superpermbridge.*' to give the equivalent of what used to be the '*' node for plugins that do not use Superperms directly. If you don't want to give the * node, you can also use the node 'superpermbridge.pluginname' to do the equivalent of what used to be the 'pluginname.*' node. Once again, these only apply to plugins that SuperpermsBridge handles and not to plugins using Superperms directly.
    3. How do I use the root permissions.yml? (open)
    The file 'permissions.yml' in the root of your server can be used to set up custom parent permissions. Parent permissions are a single node that, when given to a player or group, automatically give all their children node. Here's a simple example:
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
    Now, if you give a player the node 'server.basics', they automatically get all the nodes listed here. Children may also say 'false' instead of 'true', in which case giving the parent will remove the child instead of giving it.

    You can also specify a description if you like, which can be used by plugins to provide information on your node (such as PermissionsBukkit's /perm info command). If you want, you can also provide a default, which can be one of "true", "false", "op", or "notop". CraftBukkit will automatically assign everyone, no one (default), ops, or non-ops the children permissions based on the specified default. Without any plugin like PermissionsBukkit, you can use this defaults system as a limited way to assign people permissions. Here's a more complex example:
        description: Basic permissions for My Cool Server.
        default: true
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
        description: Admin permissions for My Cool Server.
        default: op
            commandbook.broadcast: true
            commandbook.teleport: true
            commandbook.kick: true
            commandbook.ban: true
    You can also define permissions without children, but this is of limited usefulness in permissions.yml (though is important in plugin.yml; see question #6)
    4. How do I switch from (other Permissions plugin)? (open)
    Depends on the Permissions plugin! If you were using PEX's YAML backend, I have a converter done and available on the PermissionsBukkit Tools page. Also available on the tools page is an automatic converter for Essentials GroupManager users.yml and groups.yml files. Automatic converters for Permissions 2.7 and 3.x are on their way, but in the meantime you can still convert your configurations manually.
    5. Where are prefixes and suffixes (or option nodes)? (open)
    Bukkit Superperms has no built-in prefix/suffix settings or non-boolean permission nodes, so individual chat plugins will have to start supporting Superperms in order to make use of non-Permissions-plugin based prefixes and suffixes. Herochat, iChat, and Simple Suffix are all aware of the Superperms update, but in the meantime you can use mChat, which already supports Superperms.

    Once you install mChat and configure the mchat.prefix, mchat.suffix, and mchat.group names in its configuration file (see the example), use PermissionsBukkit to give players or groups the permissions "mchat.prefix.admin", replacing "admin" with whatever node you configured. For example, with an mchat configuration that looks similar to this:
    da-name-format: '+prefix+name&e'
    date-format: HH:mm:ss
    message-format: '+prefix+name&f: +message'
            admin: '&4DtK [SO] &7 '
            sadmin: '&9DtK [SA] &7 '
            jadmin: '&aDtK [JA] &7  '
            member: '&cDtK [M] &7 '
    You can assign players or groups the mchat.prefix.admin node to get the "SO" prefix, mchat.prefix.sadmin to get the "SA" prefix, and so on.
    6. (Coders) How do I set up my plugin.yml? (open)
    Take a look at this post in Dinnerbone's FAQ for an example. This is a lot like the setup of permissions.yml (see above), but you can also define non-parent permissions (just include description and default and leave out children).
    7. Is PermissionsBukkit outdated? (open)
    No! PermissionsBukkit 2.0 was last updated for 1.3.1-R2.0, is verified to work on 1.4.7-R1.0, and is unlikely to break on future releases.

    Current Version:

    PermissionsBukkit v2.0 (jar) (details)
    Old Versions:
    PermissionsBukkit v1.6 (jar) (details)



    Friday 7 September 2012 (2.0)
    • Fixed a case-sensitivity issue with setting per-world permissions that could cause some permissions to fail to apply.
    • Added /perm setrank <player> <group> subcommand (alias rank) with per-group permissions (permissions.setrank and permissions.setrank.<group>)
    • Added plugin metrics via http://mcstats.org/plugin/PermissionsBukkitMCStats (disableable in plugins/PluginMetrics/config.yml)
    Wednesday 29 February 2012 (1.6)
    • Fixed some massive issues that were caused due to having uploaded a buggy, in-development version instead of 1.5.
    • Note: If your configuration was messed up as a result of this issue, the new build should gradually correct it as needed.
    Saturday 25 February 2012 (1.5b)
    • Revamped to be compatible with R5.
    • Fixed issues with permissions not carrying properly on world change.
    • Many internal improvements for performance and stability.
    • SuperpermsBridge: in honor of R5 removing deprecated code, SuperpermsBridge is officially gone!
    Monday 18 July 2011 (1.1/1.2)
    • Fix BukkitContrib incompatibility issues.
    • Improved the output of the /perm check command.
    • Fixed issues when 'users:' is not specified in the config file.
    • Fixed the /permissions reload command.
    • SuperpermsBridge: improve wildcard handling; in addition to 'superpermbridge.*' and 'superpermbridge.pluginname', now supported are 'superpermbridge.plugin.*', 'superpermbridge.plugin.subnode.*', and so on.
    Monday 18 July 2011 (1.0/1.1)
    • SuperpermsBridge: adding the special 'superpermbridge.*' and 'superpermbridge.pluginname' nodes (see #2 in the FAQ for details).
    Sunday 17 July 2011 (1.0/1.0)

    • Initial release of PermissionsBukkit v1.0 and SuperpermsBridge v1.0.
    madmac, Gesundheit, tripleX and 23 others like this.
  2. Offline


    yep 100% blank, 0 byte in size and i even tried deleting to make sure

    i deleted the permissionsBukkit folder and restarted
    still had no permissions to use permissions perm perms from the console :(
    its clear there is some sort of configuration problem but no idea why
  3. Offline


    Hey Guys,
    So I have been getting chat spam that seems to be related to PermissionsBukkit, but caused by AdminsCanFly. The error doesn't appear when using permissions 3. I have talked to the dev of AdminsCanFly and he seems to think that the problem is caused by PermissionsBukkit. So, can I get some help?

    Here is the error code.
  4. There is a link to the development build in the first post. But yeah this should be updated to 1.2 to avoid people downloading the old version.
  5. Offline


    Great plugin, love the in-game commands, easy to use.

    The only complaint I have is that the permissions.build flag stops doors, chests, pressure pads, levers, etc.

    So I had to install some other plugin for anti build

    I would suggest adding more flexibility to that permissions.build flag, maybe a separate one like permissions.interact?

  6. Offline


    Can you please give me a sample of how i should configure this:
    -A group called "Owner" that has all permissions of all plugins, with only 1 member.
    -A group called "Admins" with 2 members and only a few permissions.(Use member1 and member2 as sample idk)

    And as i understood, the group called "default" has as members all players that aren't in a group. So:

    -The group "default" with basic permissions.

    I'm not asking to write much, but a least 2 samples of permissions in each group please. I downloaded the PermissionsBukkit v1.1, and i am having difficulty in setting it.
  7. Offline


    Is it possible to add prefixes to groups/players to use in for example mcdocs, ichat..?

    *facepalm* it helps to read sometimes... nm.
  8. Offline


    From the console, no permissions commands work at all. I just get errors telling me I don't have permission.
    In game, I can run any of the aliases and the will return the help list but if I try to use any sub commands like "/perms dump" I get no permission error.

    On the plugin conflict note, I removed SuperPermBridge and the problem went away. Obviously this isn't a viable solution as I then lose the bridge.
    mrgreaper likes this.
  9. Offline


    i was planing to close my server to the players tonight and go through it removing plugin at a time till i found the problem one, you have just saved me many hours of work thankyou!!

    @SpaceManiac and co creators, now we know what plugin is to blame can you fix it ?
  10. Offline


    I need a '*' supernode... just writing down the permission pluginname.* for the admin is really crappy imho. And i still get a
    SEVERE] Could not pass event PLAYER_QUIT to PermissionsBukkit
    error when a player quits
  11. Offline


    Is there somewhere I can read up on the design reasons for not having a '*' permission and making us add a line per plugin? It seems extremely inconvenient to add in a permission node per plugin (I've got over 50 plugins, as I'm sure a lot of others do), but I'm sure there's a good reason.
  12. Offline


    Hello! I have a question. In classic plugin called Permissions was function called "default group", like in this code:
            default: false
                prefix: ''
                suffix: ''
                build: false
            default: true
                prefix: ''
                suffix: ''
                build: true
                - Default
                - 'PhysicalShop.use'
                - 'stargate.use'
                - 'lwc.protect'
                - 'wolfpound.use'
                - 'heroicdeath.messages'
                - 'fight.user'
                - 'PhysicalShop.build'
                - 'bcvote.time'
    So, here the group called Members is default group, how can i make group be default in PermissionsBukkit? Sorry for bad english...
  13. Offline


    Noone anywhere seems to mention this at all:

    What if I want to keep the old Permissions plugin, and just use the Bukkit system for plugins which need it? Can I just use both together like that or will they have some sort of cyber dual to the death and destroy our server?

    I really dont want to/see the point in spending hours and hours moving my permissions system when the Permissions plugin does work fine...
  14. Offline

    Celtic Minstrel

    The default group is the one called "default".
  15. Offline


    @Keri - Use the SuperpermBridge and give your admins the "superpermbridge.*: true" node. This will simulate the permissions "*" node.

    @Flenix - You can use both permissions systems, but if you use Permissions 2.x/3.x, do not use the Superpermsbridge.

    @Amsek - Just give your "default" group all of the nodes you set for your member group. The name of the group is never needed, and so it is only a formality in this case. Just let it be default.

    @mrgreaper / @Jinux - I'm still unable to replicate this problem, with SuperpermsBridge, CB1060 and my release of PermissionsBukkit, except by setting "permissions.*: false"

    I've done a rather extensive amount of searching through the code to determine any possible conflicts, and I can't. Superpermsbridge doesn't register any commands, nor does it register permissions nodes equivalent to "permissions.*" or any of those registered by PermissionsBukkit.

    The only way I'm able to replicate this problem is by setting permissions.*: false in my permissions.yml, and this problem persists regardless of whether I have SuperpermsBridge or not.
  16. Offline


    @SpaceManiac and co. I'm curious about group assignments, it appears they work differently to the other permission plugins and two of my plugins don't read the groups. What I mean by this is with LWC and Lockette, you can lock chests/doors etc to a person and or a group, if I lock things to the 'trusted' group, with permissions 2.x and 3.x everybody listed in 'trusted' can access these locked items, but not with permissionsbukkit.

    There is also a problem with the node superpermbridge.*: true overwriding any other node you use to remove permissions. In 2.x and 3.x you could use '*' to grant all permissions, then list maybe two to three you didn't want to use with the - '-take.this.away', but if I do superpermbridge.*: true then take.this.away: false, it ignores the nodes listed as false and grants them anyway.
  17. Offline


    Would anyone be willing to help me out with this, I loaded the plugin and copied and pasted the information given for groups and players then reloaded the server but it says that people I have set as admins don't have permission to use plugins. I have skype or could talk over a pm on here I would really appreciate it.
  18. Offline


    @khamseen_air - Superpermbridge was meant as a temporary stopgap while plugins converted to Superperms; it was never intended to be a permanent tool. The idea was to provide compatibility while plugins were updating.

    Too many plugins are relying on the old (unsupported and inactive) permissions plugins, and it's making it really hard to switch over. Plugin devs need to stop being so obtuse.

    That's right. Obtuse.
    mrgreaper and Ninja Grinch like this.
  19. Offline


    @krinsdeath @SpaceManiac

    Inheritance doesn't work at all. Everyone's prefixes are wrong, for example ops have the donor tag.

    Also Ops can't teleport in the world creativethree, even though they are supposed to inherit it from the VIPs


    any help? thanks
  20. Offline


    @Pand3micc - Without a peek at your config.yml for PermissionsBukkit (and which chat plugin you're using), I can only venture a guess as to what your problem actually is. In this case, I believe the most likely scenario is that you have misconfigured mChat.

    mChat's nodes require you to set the inheriting group's nodes (mchat.prefix.group2) for the inherited group's nodes (mchat.prefix.group1) to false. As a result, the config grows in size (and perhaps complexity). This isn't a glitch in inheritance, but an unfortunate consequence of using permissions as configuration options.

          mchat.prefix.group1: true
          mchat.prefix.group1: false
          mchat.prefix.group2: true
          mchat.prefix.group2: false
          mchat.prefix.group3: true
  21. Offline


    @krinsdeath Well that fixes the prefix issue, but what can I do about my ops not being able to use teleport commands in the world creativethree
  22. Offline


    Well yes I agree that they need to update their plugins to use it. But since it's not a required thing for them to do, no one can really say they are in the wrong. The PermissionsBukkit handles permissions differently to all the other permissions plugins that have been readily available for a very long time now, it shouldn't be expected for people to go "yes well we've been doing it this way for this long, but since this one new permissions plugin does it that way, let's all convert". In the interim, (it's still not a long time since PermissionsBukkit became available in the grand scheme of thigs) superpermbridge could at least be edited to function as intended.

    To not fix it so that it works correctly, is no better than the plugin devs not updating their plugins to support PermissionsBukkit in my opinion.

    You've also over looked my other (and primary) question completely. :)
  23. Offline


    did i set this up right? it isnt working on the server, whenever i type /perm or any alias of that command it says Unknown console command. Type "help" for help.
    Here is a list of the plugins I have installed:
    CraftBook Circuits
    CraftBook Common
    CraftBook Mechanisms

    thank you so much for taking the time to read this and help out :) this is the last thing i need to do for my server. I've gone from essentials group manager to permissions 3.x to permissionsEx and now to this one. I couldent get any of them to work properly with other mods that I wanted. My config is at the bottom and in a .txt thanks again

    I also noticed this in the terminal. idk why it isn't loading.

    Attached Files:

  24. Offline



    Gave up on the other one then eh? :p

    On lines 165, 168, 171 and 181 you are missing a space between the : and true so you have :true instead of : true.

    And for reference, the commands are listed in the OP of this thread. :)
  25. Offline


    @khamseen_air - The answer to your first question is that LWC and Lockette likely do not hook PermissionsBukkit to determine which group the player is in, and as such have no way of referencing whether or not the player has access to a particular chest. The way around this is that they've probably provided a node for that particular chest that you can apply to any given group, to enable access for that chest to that group. I don't know how LWC and Lockette work, however, and say this with a large degree of uncertainty. This is certainly not PermissionsBukkit's problem, though.

    To answer your second query, it's likely that you need to apply your "negative" permission in the form of "superpermbridge.take.this.away: false" in order for Superpermbridge to handle it. Superpermbridge is, as I said, a stopgap. It's not intended to take the reigns from Permissions, but to provide a handler while the trainer is switched, and as such performs its tasks fairly well. Improving on it kind of a moot point, because it's not intended to exist for longer than it takes to update a plugin to use superperms, which for my plugins took all of an hour.

    PermissionsBukkit provides a frontend for server owners; it is not an API. Bukkit itself provides a permissions API now, and plugin devs do not have to hook it or even provide support for it; it just works. Permissions 2.x, 3.x, GroupManager and the plethora of other permissions plugins have the largest amount of "help me it doesn't work" posts relative to any other plugin because they're confusing, backward, and poorly designed. Many of the original authors of those plugins have even urged users to stop using their plugins because of how poorly designed and difficult to maintain those plugins are.

    All ranting aside, it's perfectly acceptable to use both Permissions 2.x/3.x/GroupManager and PermissionsBukkit at the same time, to provide a permissions interface for plugins that (for whatever reason) refuse to update, and plugins that have already updated. They should not conflict in any way, so long as you're running the latest versions of CraftBukkit (at the time of this post, build 1060).

    @Pand3micc - Do teleport commands work for every world (and group) except ops in "creativethree"? I see nothing immediately wrong with the config, and can only surmise that some other plugin is attempting to override the ability to teleport inside of that world.
  26. Offline


    @krinsdeath They can't teleport or spawn items in creative or survival, as well as some other stuff
  27. Offline


    I shall try to get a response from the dev of LWC then (Lockette has gone inactive), since he does claim to have already updated it to support PermissionsBukkit.

    I shall test that theory of applying the negative permissions using the superpermbridge and get back to you. To be honest, it's not a huge deal for me any more as I've now gone through every plugin we use and written the config from the ground up so that it lists all required nodes, not as nice and easy as a '*' but it works. As I say though, since there is no end date or required point in time for plugin devs to support PermissionsBukkit, we can't really say it wont still be required for some time yet.

    I can understand that, though to be completely fair (and rather blunt), a lot of the problems people encounter is their own inability to understand YAML. Though I do understand that the intention is one system that is supported constantly over five to ten that are supported half of the time and can see the logic behind that.

    I had actually considered doing that, but to be completely honest, I can't justify having three plugins to do the work of one. I already require two to do the work of one to cover the plugins that don't yet support PermissionsBukkit haha.

    Thank you for the response. :)
  28. Offline


    Actually, you should only need PermissionsBukkit and Permissions if you were to do this. SuperpermsBridge would conflict with Permissions 2.x or 3.x, and make the entire system explode. You'd be back to using 2 plugins (albeit with perhaps more success, since permissions would provide its own configuration files). The downside is more the fact that you'd then have even more segmented configuration files, and you'd have to keep track of which plugins are updated to Superperms and which aren't (or have no intention of doing so).

    I appreciate your candidness, and patience.

    @Pand3micc - Which versions of CraftBukkit and CommandBook are you running? This could be a problem with outdated plugins, because I do not have this problem (world inheritance and node overriding works fine for me). I can only suggest trying to give the nodes to players in the global scope (permissions node rather than worlds node) and seeing if the problem persists. If it does, you need to update CommandBook (latest versions of it, WorldGuard and WorldEdit all support Superperms natively and do not require the use of the SuperpermsBridge).
  29. Offline


    What about just using PermissionsEX for the time being? It covers both Superperms and the old way. From what I can see its actually the perfect way to go at the moment because of stubborn and lazy devs.
  30. Offline


    Ah well yes, I wouldn't really want it to explode haha. I guess that is a possibility then, though I shall pester the LWC dev a little more first. I've looked at his source on github though and it does seem to be set to check what group people are in with PermissionsBukkit. Though my JAVA skills are a little out of date. It'd be much nicer to have that sorted than have to keep track of two sets of configuration files.

    I had actually tried that as a stop gap measure before, can't recall exactly why I didn't use it, but I'm pretty sure one of the plugins I use had stopped support for all permissions bar this one. That may not be the reason though. My desktop currently looks like a file monster has been on the run with stuff dotted around everywhere haha.
  31. Offline



    I have the most recent commandbook, and I can't use those permissions in the global scope because I don't want normal members to be able to spawn items in survival. I'll just try avoiding inheritance altogether and doing it the long way, at least until this plugin has most of the kinks and bugs worked out.

    EDIT: This is what it has come down to, lol: http://pastebin.com/p54gcWX7

    (only included the group section)

Share This Page