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


    that would mess us up rather royaly, we reley on seperate groups for everything from giving those that take the time to register extra commands and functions to enabling players to see in chat who is admin staff etc and on pvp not to mention most of our sensors detect groups lol (in pvp world it keeps the 2 sides from entering each others bases)
    for now i will let players know pvp world is disabled untill a fix is available, no biggie to me (i hate pvp, come on minecraft was not designed for it lol) vut my players may revolt lol

    im still sorting out upgrading plugins before i start tapping in the commands for permissions but i will set myself as a vip player and test this out and post the result before i give myself the admin * permission lol (might be an hour or so mind) for the good of all minecraft kind :)

    what command is it to add a group? thats missing from the command list (as is the set prefix and surfix commands) do these have to be done in the yml for now?
  3. Offline


    I have one problem about this plugin. I don't know how to edit the prefixes ad the name colors because I can't find the config file
  4. Offline


    so i should replace the old permissions with this?
  5. Offline


    I am not entirely sure but you change replace it if you want. For me I switched because I was using the new Permissions (3.1.6) and many plugins were not compatible with it and also SpaceManiacs has provided superperms which make the plugins believe that the PermissionsBukkit is version 2.6.x -3.x. Correct me if I am wrong.
  6. Offline


    Do groups have multiple inheritance?


    There are three groups, Default, Member, VIP

    Default has no inheritance
    Member inherits Default
    VIP inherits Member

    Would VIP then inherit Member's permissions and ALSO Default's permissions?
  7. I'll look into world-groups when I get the chance. At the moment, there's no commands to add or remove groups or change group inheritance as an intentional design decision to make it harder to accidentally mess up your whole config in-game; these are rare actions anyways. For more info on prefixes and suffixes read below.

    Because of the structure of Superperms, PermissionsBukkit doesn't have prefix and suffix configuration; if you're not too attached to the chat plugin you are currently using, I recommend trying out mChat, which supports Superperms for prefixes and suffixes using what will eventually be the same method iChat and HeroChat will have to use (I've talked to the HeroChat devs and will be contacting the iChat devs too).

    If you're not completely sure, you can feel free to hold off for a while. If a lot of your plugins currently depend on Permissions, use both PermissionsBukkit and SuperpermsBridge. Some chat plugins (like iChat and HeroChat) will not be able to fetch prefix and suffix information (see above for more information).


    Correct. Groups can also directly inherit from multiple groups, but this is generally unneeded and should be avoided if possible.
  8. Offline


    I don't want to be annoying but I don't know how to set it up with mChat thats what I said in my previous post I think....
    Im confused :D
  9. 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+group+suffix+name&e'
    date-format: HH:mm:ss
    message-format: '+prefix+group+suffix+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.
  10. Offline


    Is it possible to have different permissions set for different worlds?
  11. Yes; take a look at the configuration example in the first post for an example of how to do this.
  12. Offline


    I will check it out in a sec and see if I understand :p

    I have no clue what to do..I am stupid with these kind of things.....

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 17, 2016
  13. Basically, put mChat's jar in your plugins folder, and put a configuration like the one I posted in plugins/mChat/config.yml, then use a command like /perm group Member setperm mchat.prefix.member to set the prefix of all players in the Member group to have the prefix under "member" in mChat's config (in the example, that's "&cDtK [M] &7 ").

    In other news, I finished up a converter from PermissionsEx's YAML format to PermissionsBukkit's configuration format. It can be found here and I will be adding a link to the first post shortly. Permissions 2.7, 3.1, and GroupManager converters are on their way.
  14. Offline


    Wow I am stupid I had the wrong link to the mChat download! Instead it gave me PrefMess.jar and I was like wtf mate?
    But now I can do it so its ok now! Thanks anyways :D
  15. Offline


    I'm attempting to run this on my server because I was having trouble with Permissions as well as Essentials GroupManager. But when I added it to my server and tried to run /help, I got an Error: Null message. Several commands that would normally come up with a confirmation message, like /time day or /time night work, but without the confirmation. It appears that notifiers for several of my plugins have been disabled.
    I would also like help with the config file as the format is different from GroupManager and I'm not sure on how to transfer the settings in their entirety, such as my admin privilege which was previously defined by the line '*' under permissions no longer seems to work.

    I guess just overall more explanation of how to update fully without losing functionality would be appreciated over anything else.
  16. Offline


    well as promised i tested it and i had permission to use mc0232 even though set to false so that answers that ...time to add all ics one by one ..arghhhhhhhhhh lol
  17. Offline


    After all I can't get it to work..In game I typed /perm group Member setperm mchat.prefix.member and then I before i did that I made the configuration file and then I reloaded config file (I saved it obviously) Then I tried to type something and then no color, group, prefix, nothing..and now I don't know whats the problem
  18. Offline


    Well, I just got done testing some basics of it.

    /perm reload doesn't seem to reload correctly. I had to manually restart my test to get it recognized.

    .* does not work on several plugins, you'd have to manually add all the nodes.
    Universal '*' for all access for admins does not work unless I have the wrong format.

    Is there a some example for Permissions.yml in the root directory?

    When using stop to stop server.

    McDocs stop working as soon as I installed the two files attached. Could not pass player join event.
    Without it, it works fine.
  19. If plugins check for lets say coupon.add, and the user has coupon.*, will it return true? Or will we have to check for both?
  20. I can't help you with the missing confirmation messages, as that sounds like an issue with another plugin, but I'm working on setting up a GroupManager converter right now. However, some things like the '*' node will not work - try and find my post earlier in the thread. This is a technical limitation of Superperms and is by design. I'll add an FAQ when I get the chance.

    Heh, this is probably a side effect of Superperms being a young system. Kinks like this will be ironed out over time.

    Not completely sure. Try asking in the mChat thread if you still can't figure it out.

    I'll look into figuring out what the issue with /perm reload might be. The .* will probably not work on some plugins, but I will update SuperpermBridge shortly with a temporary fix for this. The universal '*' permission does not yet work either, but I can add it to SuperpermBridge as well. This means that plugins designed to work with Superperms that specify their own 'plugin.*' nodes will function as normal, but plugins going through the bridge will have all permissions assumed to be true if their .* node is specified (Note: this may cause some issues with WorldGuard's auto-god permission, among other things).

    I will add an example of using root directory permissions.yml to an FAQ in the first post when I get a chance.

    If you are running BukkitContrib, there is a known incompatibility - make sure you have the latest. If that doesn't solve it, please give me a full list of plugins you're using. I'll look into the issue with McDocs as soon as I get a chance.

    If you are writing a plugin for the Superperms API, use plugin.yml to define 'coupon.*' as a parent permission for 'coupon.add' (refer to this post in the FAQ for an example) and check for the 'coupon.add' permission. If a plugin by you or another author is using Permissions 2.7/3.1 via SuperpermsBridge, then I will be updating the bridge shortly to fix 'plugin.*' node checking.

    In other news, I have contacted Drakia of iChat (by request of Shaun Bennet) and Flabaliki of Simple Prefix (by request of @Realtek1) about supporting Superperms.
    LaLa likes this.
  21. Offline


    ah crud major error at mo

    011-07-18 04:41:14 [SEVERE] Could not load 'plugins/bukkit-permissions-0.1.0-SNAPSHOT.jar' in folder 'plugins':
    while scanning an alias
     in "<reader>", line 50, column 13:
                    *: true
    expected alphabetic or numeric character, but found but found :
     in "<reader>", line 50, column 14:
                    *: true
        at org.yaml.snakeyaml.scanner.ScannerImpl.scanAnchor(ScannerImpl.java:1156)
        at org.yaml.snakeyaml.scanner.ScannerImpl.fetchAlias(ScannerImpl.java:782)
        at org.yaml.snakeyaml.scanner.ScannerImpl.fetchMoreTokens(ScannerImpl.java:313)
        at org.yaml.snakeyaml.scanner.ScannerImpl.checkToken(ScannerImpl.java:183)
        at org.yaml.snakeyaml.parser.ParserImpl$ParseBlockMappingKey.produce(ParserImpl.java:564)
        at org.yaml.snakeyaml.parser.ParserImpl.peekEvent(ParserImpl.java:163)
        at org.yaml.snakeyaml.parser.ParserImpl.checkEvent(ParserImpl.java:148)
        at org.yaml.snakeyaml.composer.Composer.composeMappingNode(Composer.java:228)
        at org.yaml.snakeyaml.composer.Composer.composeNode(Composer.java:160)
        at org.yaml.snakeyaml.composer.Composer.composeMappingNode(Composer.java:230)
        at org.yaml.snakeyaml.composer.Composer.composeNode(Composer.java:160)
        at org.yaml.snakeyaml.composer.Composer.composeMappingNode(Composer.java:230)
        at org.yaml.snakeyaml.composer.Composer.composeNode(Composer.java:160)
        at org.yaml.snakeyaml.composer.Composer.composeMappingNode(Composer.java:230)
        at org.yaml.snakeyaml.composer.Composer.composeNode(Composer.java:160)
        at org.yaml.snakeyaml.composer.Composer.composeDocument(Composer.java:122)
        at org.yaml.snakeyaml.composer.Composer.getSingleNode(Composer.java:105)
        at org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseConstructor.java:124)
        at org.yaml.snakeyaml.Yaml.load(Yaml.java:264)
        at org.bukkit.util.config.Configuration.load(Configuration.java:82)
        at org.bukkit.plugin.java.JavaPlugin.initialize(JavaPlugin.java:157)
        at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:175)
        at org.bukkit.plugin.SimplePluginManager.loadPlugin(SimplePluginManager.java:207)
        at org.bukkit.plugin.SimplePluginManager.loadPlugins(SimplePluginManager.java:130)
        at org.bukkit.craftbukkit.CraftServer.loadPlugins(CraftServer.java:128)
        at org.bukkit.craftbukkit.CraftServer.<init>(CraftServer.java:97)
        at net.minecraft.server.ServerConfigurationManager.<init>(ServerConfigurationManager.java:51)
        at net.minecraft.server.MinecraftServer.init(MinecraftServer.java:132)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:335)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:422)
    not sure why its erroring, im well versed in yml by now!

    all i have in my file is

                permissions.example: true
            - admins
                permissions.build: true
                permissions.build: true
                falsebook.ic.selftriggered: true
                falsebook.ic.mc0232: false
            - user
                permissions.*: true
                *: true
            - user
                permissions.build: true
                    coolplugin.item: true
            - default
        build: '&cYou do not have permission to build here.'
    i removed the *: true and the error went away but i dont have permission to do anything!!!!
    i did a permissons dump mrgreaper and this is the result;
    >permissions dump mrgreaper
    04:59:13 [INFO] [==== Page 1 of 3 ====]
    04:59:13 [INFO] Node permissions.*=true (PermissionsBukkit)
    04:59:13 [INFO] Node permissions.build=true (PermissionsBukkit)
    04:59:13 [INFO] Node permissions.check=true (PermissionsBukkit)
    04:59:13 [INFO] Node permissions.dump=true (PermissionsBukkit)
    04:59:13 [INFO] Node permissions.example=true (PermissionsBukkit)
    04:59:13 [INFO] Node permissions.group.*=true (PermissionsBukkit)
    04:59:13 [INFO] Node permissions.group.help=true (PermissionsBukkit)
    04:59:13 [INFO] Node permissions.group.list=true (PermissionsBukkit)
    as you can see the permissions.* is there but that doesnt apear to be functioning the same as the * from the old permissions arghhhhhhhhhhhhhh BLEEP

    its 0506 here and i need sleep. Hopefully the *: true bug will be fixed when i get up, my server is now on the longest downtime since hmod died :( not good so not good but unavoidable
  22. This'll be fixed once I update SuperpermBridge. Sorry about the downtime!
  23. Offline


    not your fault chap, new plugin = new elephants (too big to be called bugs)
    i do however love the new commands, very easy to use and the ability to look up permissions a player has is very good

    side note : i changed my group to trusted and did the dump again, the mc0232 false was above the falsebook.ic.selftrigered :true
    perhaps if you set it to look for true rules first then false rules, that may fix the issue of it letting me use mc0232 even though its false ? (though i know nothing of programming beyond BASIC lol)

    right must sleep (reckon im gonna have nightmeres about yml files lol)
  24. Offline


    Quick question, to maybe save me some time, do you have to put false for every command you don't wan't a user to use? If so wouldn't that mess up inheritance?
    permissions.build: true
    essentials.item: false (I don't want this user to have this command)
  25. In general, commands will be disabled by default.

    Still working on the GM converter, the SuperpermsBridge update, and writing up an FAQ.
  26. Offline


    Sorry, I'm really confused, but if I put a permission node down and not mark it as true or false, will it default to false?
  27. Offline


    I really hate these plugins, I want to use them but I have no idea how to set them up, even after watching the tutorials.
  28. In the configuration, just make sure you always mark it 'node: true' or 'node: false'. If you want it to default to false you can just leave it out.

    Heh. I've designed PermissionsBukkit to be as simple to use as possible, and a lot more help and information is coming your way in the form of a detailed FAQ.
  29. @SpaceManiac
    Thanks for the help and this plugin, permissions system is so much better now both for devs and server admins
  30. Offline

    Brandon Egnell

    ok i look at this and im just wondering in the examples
    permissions.build: true <== Can i put any other plugin in here?
    coolplugin.item: true <== or is this for any other plugins
    inheritance: - default

    I am just trying to understand this. I use essentials group manager and its never failed me but it seems if this is being put into it. Then i guess i should learn how to use it and use this. No point in having 2 of the same thing in one place.
  31. SuperPerms gooo!

Share This Page