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

    Features:
    • 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.

    Configuration:
    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:
    Code:
    users:
        ConspiracyWizard:
            permissions:
                permissions.example: true
            groups:
            - admin
    groups:
        default:
            permissions:
                permissions.build: false
        admin:
            permissions:
                permissions.*: true
            inheritance:
            - user
        user:
            permissions:
                permissions.build: true
            worlds:
                creative:
                    coolplugin.item: true
            inheritance:
            - default
    messages:
        build: '&cYou do not have permission to build here.'
    

    Permissions:
    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:
    Code:
    server.basics:
        children:
            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:
    Code:
    server.basics:
        description: Basic permissions for My Cool Server.
        default: true
        children:
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
    server.admin:
        description: Admin permissions for My Cool Server.
        default: op
        children:
            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:
    Code:
    da-name-format: '+prefix+name&e'
    date-format: HH:mm:ss
    message-format: '+prefix+name&f: +message'
    mchat:
        prefix:
            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.

    Downloads:
    Current Version:

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

    [​IMG]

    Changelog:

    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

    babystompa

    Yeah I realized that DefaultCommands wasn't listening to it and it made me sad :[ If I wait tell DC is 1000 compatible it should work right?
     
  3. If you're planning on implementing BukkitPerms and don't want to wait for the updates for the respective plugins for native support, you'll definitely need the SuperPermsBridge for most plugins.

    As for waiting for the plugins to update, assuming DefaultCommands implements permissions in their plugin properly, PermissionsBukkit will work with it with no additional configuration or hair-pulling.
     
  4. Offline

    babystompa

    Great to hear :]
    Guess i'll go back to using default plugins built in permissions tell it is compatible I really want to bump some people in my server up but I guess they will have to wait.
     
  5. Offline

    Drageer

    Can't say i'll be switching right now.
    I'm honestly pretty confused on how to make permissions 3.1.6/2.7.4 bridge over to this.
    Do I just install the bridge?
     
  6. Offline

    Kozzy68

    Hi, Im not sure if I understand new perms.
    I am setting up new server and I like to use some plugins that are 953 ver. This plugins are written to support old permissions 3.x.
    Does this means I have to install old permisions plugin and then use bridge to new permissions ? Or I dont need old permissions plugin at all now when setting up new server also with older 953 plugins ?
    For example I like to use towny[1000] plugin. what do I have to install ?
     
  7. I have the latest PermissionsBukkit and Bridge, its not working :(
     
  8. Offline

    fffizzz

    able to set build rights for specific worlds yet? for example, default group can build in start map, but no other maps?
     
  9. Offline

    mrgreaper

    the ability to build is a permission so simply remove if as a global and add it as a world rule true in the ones you want it in and false for the ones you dont want it in, fair bit of typing but only has to be done once :)
    /permissions group unsetperm default permissions.build
    /permissions group setperm default world:permissions.build true
    /permissions group setperm default world2:permissions.build false
    /permissions group setperm default world3:permissions.build false

    like that i think (untested as i havent had time to test per world permissions)
     
  10. Offline

    fffizzz

    ahh ok, so something like this..

    Code:
    groups:
        default:
            permissions:
                permissions.build: false
            worlds:
                ww:
                    modtrs.command.modlist: true
                    modtrs.command.modreq: true
                creative:
                    announcer.receiver: true
                    mcmmo.*: false
                start:
                    announcer.receiver: true
                    permissions.build: true
    one other quick question...

    can console use the permissions command? if so, this is going to make my life so much easier.. i have a bunch of php scripts that currently modify the text files from permissions 2.7.4 and then a mod has to do a /permissions -reload all manually.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 17, 2016
  11. Offline

    mrgreaper

    if im right then yes like your example

    the console does indeed allow permissions just omit the / its how i added all my players much easier to type oncce then tap up and edit name group for about 30 people then do it all in the yml file (plus my hatred for all yml files!, one wrong space and bam grrrr)
     
  12. Offline

    wraith1200

    I am working on setting up my own node groups to keep the config.yml for bukkit permissions clean as possible and when I am putting in the yaml I get the following error for this code. I am not very familiar with the yaml and can't figure out where i messed up. Thanks for any assistance you can provide.

    Code:
    server.basic
       description: Gives access to basic commands and abilities.
       children:
            permissions.build:true
    Code:
    [WARNING] Server permissions file permissions.yml is not valid YAML: mapping values are not allowed here
     in "<reader>", line 2, column 16:
            description: Gives access to basic commands ...
                       ^
    
     
  13. Offline

    Techykid3

    I use Permissions 3.1.6 and now I don't know what to do :(
     
  14. I believe as of right now he's working on a converter for Permissions 3.x (as well as 2.x). if you're already using Permissions 3.1.6 and it's working, you don't have to worry about switching right away.
     
  15. Offline

    Techykid3

    Am I able to update to #1000, while still using Permissions 3.1.6? Or do I need to start learning this version.
     
  16. I have it working on RB1000 myself, so you should be safe to update. it wouldn't hurt to start learning this just because though :)
     
  17. Offline

    Techykid3

    Alright, one thing that totally makes me go crazy is that everything is changing with permissions now. I got no clue on what to do with my 27 plugins.

    Also, do you know the difference between Superperms and PermissionsBukkit?

    I got no clue.
     
  18. Superperms is the name of the Bukkit internal mechanism and PermissionsBukkit is a way to access it.
     
  19. Offline

    Techykid3

    Okay, I'm starting to loose some confusion now :)

    But a whole load of questions :p Here you go:

    groups: default: permissions: permissions.build: false
    Okay, so if I had essentials.kick... Does this mean for EVERY NODE, that I don't want someone to use I have to list it to false for them?
     
  20. Offline

    pontuzz

    If i write the config.yml do i still need to write the permissions.yml doc aswell? if so can anyone show or tell me how to do that?
     
  21. Offline

    Svenboy222

    How do I make groups and add myself into it?
     
  22. Offline

    Exxidion

    I'm having problems doing many things on my server. For example, I cannot use any of the appleseed or herochat commands. I'm not sure what the problem is, but I think it has to do with the config file... any suggestions?
    Config file: http://pastie.org/2238304
     
  23. Offline

    ValBGaming

    Having a bit of a problem with configuration... I just spent about 4 hours setting up all the permissions with this plugin and how I did it was I made 6 ranks (Unregistered, Member, VIP, Moderator, Admin, and Operator) and then used the method of using the root permissions.yml and then used the permissions I made in the plugin config. So for example I made "essentials.member" with all the essentials commands I wanted members to have, and then used "essentials.member" in the plugin config.

    The server started up perfectly fine, all was well -- Until I logged in -- The server wasn't responding to any commands (Or chat for that matter) and by the time I decided to look at the console it had spammed about 127,000 lines of errors... In a matter of about 30 seconds... I'm not sure what I'm doing wrong, I'll post the beginning of the error -- Because after the beginning it's just the same line repeating over and over.
    Code:
    2011-07-19 13:20:31 [SEVERE] Could not pass event PLAYER_JOIN to mcMMO
    java.lang.StackOverflowError
        at java.lang.Character.toLowerCase(Unknown Source)
        at java.lang.String.toLowerCase(Unknown Source)
        at java.lang.String.toLowerCase(Unknown Source)
        at org.bukkit.plugin.SimplePluginManager.getPermission(SimplePluginManager.java:410)
        at org.bukkit.permissions.PermissibleBase.calculateChildPermissions(PermissibleBase.java:178)
        at org.bukkit.permissions.PermissibleBase.calculateChildPermissions(PermissibleBase.java:185)
    And then it just repeated "at org.bukkit.permissions.PermissibleBase.calculateChildPermissions(PermissibleBase.java:185)" for about 127,000 lines...

    Actually -- Scrolling through it I'm finding a couple spots where it stops and a new error begins -- However the error is the exact same thing, just with a different plugin...
    Code:
    2011-07-19 13:20:37 [SEVERE] Could not pass event PLAYER_MOVE to NoCheat
    java.lang.StackOverflowError
        at java.lang.Character.toLowerCase(Unknown Source)
        at java.lang.String.toLowerCase(Unknown Source)
        at java.lang.String.toLowerCase(Unknown Source)
        at org.bukkit.plugin.SimplePluginManager.getPermission(SimplePluginManager.java:410)
        at org.bukkit.permissions.PermissibleBase.calculateChildPermissions(PermissibleBase.java:178)
        at org.bukkit.permissions.PermissibleBase.calculateChildPermissions(PermissibleBase.java:185)
    Then that goes on for awhile... And that same error occurs about 3 times, then this one happend...
    Code:
    2011-07-19 13:20:56 [SEVERE] Could not pass event PLAYER_MOVE to AfkBooter
    java.lang.StackOverflowError
        at java.util.LinkedHashMap$LinkedHashIterator.<init>(Unknown Source)
        at java.util.LinkedHashMap$EntryIterator.<init>(Unknown Source)
        at java.util.LinkedHashMap$EntryIterator.<init>(Unknown Source)
        at java.util.LinkedHashMap.newEntryIterator(Unknown Source)
        at java.util.HashMap$EntrySet.iterator(Unknown Source)
        at java.util.HashMap.putAllForCreate(Unknown Source)
        at java.util.HashMap.<init>(Unknown Source)
        at java.util.LinkedHashMap.<init>(Unknown Source)
        at org.bukkit.permissions.Permission.getChildren(Permission.java:71)
        at org.bukkit.permissions.PermissibleBase.calculateChildPermissions(PermissibleBase.java:185)
    And then the one with NoCheat happened 2 more times, followed by another one with AfkBooter, then the NoCheat one a few more times... And then the AfkBooter one again... And so on...

    But I'm not sure what I did wrong... It only happens once I log in. The start up is working perfectly fine.

    EDIT: Here's a couple snippets of my code for reference.
    Code:
    essentials.unregistered:
        children:
            essentials.afk: true
            essentials.chat.question: true
            essentials.chat.shout: true
            essentials.ignore: true
            essentials.msg: true
            essentials.ping: true
            essentials.spawn: true
    That is in the "permissions.yml" in the root folder, and then this is from the PermissionsBukkit "config.yml"
    Code:
    groups:
        unregistered:
            permissions:
                permissions.build: false
                mchat.prefix.unregistered: true
                essentials.unregistered: true
                worldedit.unregistered: true
                mcdocs.unregistered: true
                iwarning.unregistered: true
                modtrs.unregistered: true
                lagmeter.unregistered: true
                chaircraft.unregistered: true
     
  24. Offline

    ToastedJelly

    Hi SpaceManiac,

    My Plugin gets the group of the user with code like this from permissions:

    Code:
    group = ((Permissions)getPlugin("Permissions")).getHandler()
            .getGroup(player.getWorld().getName(), player.getName());
    Now somebody that uses "Permissions - Compatibility layer between original Permissions and Bukkit Superperms" has problems. My Plugin detects it as Permissions, but I get an empty group back, although /permissions player groups NAME returns "admin".

    Are you aware of problems there?
    Here are the informations the user posted:
    http://forums.bukkit.org/threads/in...m-help-pages-935-953.18330/page-5#post-489201
    http://forums.bukkit.org/threads/in...m-help-pages-935-953.18330/page-5#post-489139
     
  25. Offline

    lukehib

    If I want to use permissions 3.1 for the time being, what do I put in bukkit.yml under permissions file?
     
  26. @lukehib nothing, atleast I didn't edit or add anything to mine
     
  27. Make sure you have a ':' after 'server.basic:'. I'll make sure the FAQ is not in error.

    If you're having trouble with the nodes for a plugin that depends on SuperpermsBridge (as in hasn't been updated for Superperms yet), try adding 'superpermbridge.' to the beginning of their nodes.

    I'll take a closer look at this shortly.

    Double-check to make sure you don't have any loops in your parent/child permissions (such as a parent permission having itself as a child).

    Right now the bridge doesn't do any special handling of groups. If this becomes a major issue, I will modify the bridge to optionally hook into PermissionsBukkit, but the "correct" way of handling this is to, instead of allowing your users defining a group name -> help set mapping, allow them to name each help set (so you have admin: thishelp, user: thathelp, guest: otherhelp, and so on) and then for each help set the user has defined, you check if they have the "helppages.set.[set]" permission, and if so display that help set. There's less reliance on users having defined groups in the first place, and it's more Superperm-ey in general.

    You should be fine leaving it alone.

    Also special thanks to mrgreaper and krinsdeath for providing support when I'm gone.
     
  28. Offline

    Giancarlo

    In the config file I put myself in the admin group but i still get the message, "You do not have permission to build here" when i try to do anything. what am i doing wrong?
     
  29. Make sure the admin group has 'permissions.build: true'.
     
  30. Offline

    Giancarlo

    well i have the 'permissions.*: true'. does this work?
     
  31. Offline

    Exxidion

    I tried what you said and added superpermbridge. to the beginning of all the nodes that were not made for superperms yet and now I cannot do anything on my server (less than I could do before)
     

Share This Page