[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

    SpaceManiac

    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

    Snowy007

    Just give the groups that should be able to build, the 'permissions.build: true' node.
     
  3. Offline

    tsr78

    i have a question i have tried to make a new group agian and agian but cant seem to do it. my console gets all screwy and the group won't register. what would a new group look like could you give an example?
     
  4. Offline

    saintcarlos

    Giving players OP rank is usually a really bad idea. Players who are OP have access to All commands. Yes, even the /stop command!
    Also, you really don't have to give players the permissions.build permission when the group you put them in already has the permission.
    The problem with your config is that you have 2 empty lines. PermissionsBukkit really hates empty lines and won't'work correctly if the config contains any. Here it is fixed:

    thanks, but the question still remains, how do i give simple Moderator commands, they still cant access the commands without OP?
    thanks, but the question still remains, how do i give simple Moderator commands, they still cant access the /kick, /ban etc commands without OP?
     
  5. Offline

    Snowy007

    There should already be some examples in the config that gets generated when you first install the plugin...
    Code:
        Examplegroup:
            permissions:
                example.permission: true
                other.example: true
            inheritance:
            - default

    Assuming that you are using the standard CraftBukkit ban and kick commands, then you can find all the permission nodes here: http://wiki.bukkit.org/CraftBukkit_commands
     
  6. Offline

    Mollgan

    Hi and thanks for a great plugin!

    I have a question regarding editing the config file. Can I color the text inside the document to make it easier for myself to read and find lines in it, without messing anything up?
     
  7. Offline

    Snowy007

    Most text editors don't support coloring the text, but if you have one that does... well... just try it out. If you get errors and things get messed up.. then it doesn't work. :p
    And make a backup before trying it. :p
     
  8. Offline

    Mollgan

    I'm using wordpad and it seemed to work, so far! :p
    Thank you
     
  9. Offline

    oisins

    how do i make a permission for the command /give someone and so on?
    permissions.give: true?
    give:true?
     
  10. Offline

    Snowy007

    I've mentioned this link 2 times already on this very page of comments....
    Some people just don't know how to read any more...
    http://wiki.bukkit.org/CraftBukkit_commands
     
  11. Offline

    naddx0

    Hi!

    I just set up Craftbukkit on my (local) Minecraft Server, plus Essentials and PermissionsBukkit. Unfortunately, the changes I applied in the config file do not seem to have any effect. :(

    Here is my config file:

    Code:
    users:
      ConspiracyWizard:
        permissions:
          permissions.example: true
        groups:
        - admin
    groups:
      default:
        permissions:
          permissions.build: false
          essentials.god: false
          essentials.heal: false
      admin:
        permissions:
          permissions.*: true
        inheritance:
        - user
      user:
        permissions:
          permissions.build: true
        inheritance:
        - default
    messages:
      build: '&cYou do not have permission to build here.'
    debug: false
    
    I paid attention and removed the empty lines, but I can still use the /god and /heal commands.

    I don't know what to do...

    Thanks in advance,

    Naddx0.
     
  12. Offline

    Snowy007

    What group should be able to use /god and /heal?
    You are using 'false' for the god and heal permissions in the default group. If you want the default group to have access to those commands, you should put them on 'true'.
    If you don't want the default group to use god and heal, but instead want to give it to the admin group, you should just remove the nodes from default and put the nodes in the admin group. (as 'true')

    All permissions are usually always 'false'. So if you don't give a group a node, it will automatically be false. There is no need to use ': false' unless you want to deny a higher group something you gave a lower group.
     
  13. Offline

    naddx0

    I don't want the default group to use /god and /heal. Actually, it seems that all permissions are 'true'.
    I didn't make any change in the config file of Essentials. :x
     
  14. Offline

    Snowy007

    If you are OP you automatically have all permissions. Just de-OP yourself to see how it is for normal players.
     
  15. Offline

    naddx0

    Alright, I get it. I was still in the ops.txt. :oops:

    I figured it out before seeing your reply, but thanks a lot! :)
     
  16. Offline

    oisins

    thanks :):):)
     
  17. Offline

    Hoffnung Stark

    Hello, I have some problems about my permissions. Here is the error messeage:

    Code:
    [SEVERE] Permission node 'groups' in permissions.yml is invalid
    java.lang.IllegalArgumentException: 'default' key contained unknown value
        at org.bukkit.permissions.Permission.loadPermission(Permission.java:269)
        at org.bukkit.permissions.Permission.loadPermissions(Permission.java:218)
        at org.bukkit.craftbukkit.CraftServer.loadCustomPermissions(CraftServer.java:591)
        at org.bukkit.craftbukkit.CraftServer.enablePlugins(CraftServer.java:244)
        at net.minecraft.server.MinecraftServer.t(MinecraftServer.java:381)
        at net.minecraft.server.MinecraftServer.a(MinecraftServer.java:368)
        at net.minecraft.server.MinecraftServer.init(MinecraftServer.java:197)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:432)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:492)
    Here's the "permissions.yml":

    Code:
    groups:
      default:
        default: true
        info:
          prefix: '&f[Oyuncu]'
          suffix: ''
        permissions:
          permissions.build: true
          admincmd.kit.*: true
          admincmd.item.id: true
          admincmd.player.list: true
          admincmd.player.msg: true
          admincmd.player.afk: true
          admincmd.player.played: true
          admincmd.server.uptime: true
          admincmd.spawn.tp: true
          admincmd.server.help: true
          admincmd.tp.home: true
          admincmd.warp.tp: true
          factions.autoclaim: true
          factions.chat: true
          factions.claim: true
          factions.create: true
          factions.deinvite: true
          factions.description: true
          factions.help: true
          factions.home: true
          factions.invite: true
          factions.join: true
          factions.kick: true
          factions.leave: true
          factions.list: true
          factions.map: true
          factions.money.balance: true
          factions.money.deposit: true
          factions.money.f2f: true
          factions.money.f2p: true
          factions.money.p2f: true
          factions.owner: true
          factions.ownerlist: true
          factions.power: true
          factions.relation: true
          factions.sethome: true
          factions.show: true
          factions.tag: true
          factions.title: true
          factions.unclaim: true
          factions.unclaimall: true
      ozel:
        default: false
        info:
          prefix: '&6[Ozel]'
          suffix: ''
        inheritance:
        - default
      mod:
        default: false
        info:
          prefix: '&2[Yetkili]'
          suffix: ''
        inheritance:
        - default
      admin:
        default: false
        info:
          prefix: '&4[Yonetici]'
          suffix: ''
        inheritance:
        - default
        permissions:
          permissions.*: true
    Someone can help me please?
     
  18. Offline

    Snowy007

    Ok, 2 things.
    1. This is NOT a PermissionsBukkit config file. You are probably using a different permissions plugin. I think it looks a bit like permissions 3 but i think that plugin was outdated.
    2. Don't use the permissions.yml file for your group structure. The permissions.yml is a bukkit file in which you can group multiple permission node into a single node. To create groups and assign permission nodes to groups, you need to edit the config of the plugin. Usually found in the 'plugins\pluginname' folder
     
  19. Offline

    Hoffnung Stark

    Sorry but I don't get it, I'm not using another permissions plugin. Just Bukkit's own permissions.yml in main folder. Maybe I'll use PermissionsEx.
     
  20. Offline

    Snowy007

    I don't think you understand how permissions work yet.
    You need a plugin to handle the permissions. The permissions.yml is useless without any.
    This forum is for the plugin called 'PermissionsBukkit' which you could kinda say is the official bukkit permissions plugin. Of course you first have to download it and put it in your plugins folder. Than you can configure the config.yml file of this plugin to create groups and assign permissions.
     
  21. Offline

    tsr78

    so i keep adding in a group my config look like this
    # PermissionsBukkit configuration file
    #
    # 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 all admin permissions. 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.
    users:
    ConspiracyWizard:
    permissions:
    permissions.example: true
    groups:
    - admin
    tsr78:
    worlds:
    bluebirds:
    goto: false
    foolio88:
    worlds:
    senctum:
    worldgen: false
    worldgen<normal.neather.end><worldname>: false
    puppyraiser:
    worlds:
    senctum:
    build: true
    skellytoon:
    worlds:
    bluebirds:
    give: true
    groups:
    default:
    permissions:
    permissions.build: true
    admin:
    permissions:
    permissions.*: true
    inheritance:
    - user
    user:
    permissions:
    permissions.build: true
    prisoner: permissions: permission.build: true permission.fly: falses worlds:
    creative:
    coolplugin.item: true
    inheritance:
    - default
    messages:
    build: '&cYou do not have permission to build here.'
    debug: true
    even though it look like that it gives me this error
    an international error has occured while attempting to perform this command.
    what am i doing wrong?
     
  22. Offline

    Snowy007

    Could you post that in code tags? I think i see some strange things that shouldn't be in the config, but its hard to read this way without indention and all.
    Also you probably mean 'internal error' instead of 'international error' xD
     
  23. Offline

    saintcarlos

    thanks dude lol:)
     
  24. Offline

    tsr78

    # PermissionsBukkit configuration file
    #

    # 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 all admin permissions. 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.
    users:
    ConspiracyWizard:
    permissions:
    permissions.example: true
    groups:
    - admin

    tsr78:
    worlds:
    bluebirds:
    goto: false

    foolio88:
    worlds:
    senctum:
    worldgen: false
    worldgen<normal.neather.end><worldname>: false

    puppyraiser:
    worlds:
    senctum:
    build: true

    skellytoon:
    worlds:
    seanalpha:
    goto_<world>
    : true
    groups:
    default:
    permissions:
    permissions.build: false

    admin:
    permissions:
    permissions.*: true
    inheritance:
    - user

    user:
    permissions:
    permissions.build: true
    prisoner: permissions: permission.build:true

    worlds:
    creative:
    coolplugin.item: true
    inheritance:
    - default

    messages:
    build: '&cYou do not have permission to build here.'
    debug:
    false
    here i spaced it out more
    i was not quite sure where you would like me to put code tags so i did not put em on however i devided it into sections
    thx
     
  25. Offline

    Snowy007

    Just click the {}# button above the textbox, and then paste your config in the popup screen.
     
  26. Offline

    tsr78

    i know
    i was not sure exactley where you wanted k

    my config is already up there just need to know why

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jul 14, 2016
  27. Offline

    Snowy007

    You really don't understand how important it is to put configs in code tags do you... Not only does it improve visibility, but it also allows me to find any indention mistakes, empty lines, etc...

    When i look at your config like this, i just simply can't fix it for you, i can however tell you that i see some weird things, but its too time consuming to thoroughly search and fix mistakes.

    so, i'll just tell you the things that got my attention at first look.

    "goto: false"
    What the hell... this definitely doesn't look like a permission node.

    "worldgen: false
    worldgen<normal.neather.end><worldname>: false"
    Again, WTF is this.... permission nodes are usually 'pluginname.node: true' I've never seen them like this. Also why are there parameters in a permission node? What the hell??

    "build: true"
    Again... really strange use of permissions. This one looks familiar though and i guess you probably mean 'permissions.build: true'
     
  28. Offline

    tsr78

    kk sry i will do it in code tags
    or at least try
    Code:
    # PermissionsBukkit configuration file
    #
     
     
    # 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 all admin permissions. 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.
    users:
      ConspiracyWizard:
        permissions:
          permissions.example: true
        groups:
        - admin
     
     
      tsr78:
        worlds:
          bluebirds:
            goto: false
     
     
      foolio88:
        worlds:
          senctum:
            worldgen: false
            worldgen<normal.neather.end><worldname>: false
     
     
      puppyraiser:
        worlds:
          senctum:
            build: true
     
     
      skellytoon:
        worlds:
          seanalpha:
            goto_<world>
     
    : true
    groups:
      default:
        permissions:
          permissions.build: false
     
     
      admin:
        permissions:
          permissions.*: true
        inheritance:
        - user
     
     
    user:
        permissions:
          permissions.build: true 
     
    prisoner:    permissions:  permission.build:true
       
     
    worlds:
          creative:
            coolplugin.item: true
        inheritance:
        - default
     
     
    messages:
      build: '&cYou do not have permission to build here.'
    debug:
     
    false
    
    sry i never learned java so i can not actualy write the code this is all i could do i hope it will be acceptable
    plz do not get mad for it cause this is simpley the best i can do
     
  29. Offline

    Samithon

    How come when I join it just says <"Build-A-Craft!" Samithon> when I talk?
     
  30. Offline

    Snowy007

    You don't actually have to write any java code.....
    Its just copy and paste everything from your PermissionsBukkit config into that code box popup.
    And if your config does actually looks like that with all the empty lines, incorrect indention, incorrect permissions, uncommented lines that should be commented, and other just plain weird things... i myself would probably just delete the config and start over.

    This can not be caused by this plugin. You probably have another chat plugin or something that does this.
     
  31. Offline

    Deleted user

    wow can't even get the bukkit permissions to work.

    good lord I miss the original permissions.
    can't even launch this crap with the default settings without getting errors.
     

Share This Page