[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. That is correct.
    The op commands go through bukkit and not the plugin so there's no permissions for them. The build permission is
    permissions.build: true
     
  3. Offline

    xKYLERxx

    Alright, two things that you seriously need to add. There needs to be a global node i.e "*". I don't want to have to look up the permission nodes for every plugin. Also Prefix and Suffix support.
    Thank you!
     
  4. Offline

    KrimsonEagl

    Right, so what should the onCommand method return if the user doesn't have permission to perform the command? Should it return false, which would show the command usage, or should it return true and manually print out a message saying that the user doesn't have permission. What approach do other plugins take?
     
  5. Offline

    Jackzilla88

    I'm not sure whats going wrong, but once I figure it out I shouldn't need help (I got stuck with old permissions too) Can somebody fix this config where it's needed? I'm very lost.
    http://pastebin.com/DN1v6R9J

    For me, Styx Space, Administrate, and Multiverse plugins won't respond to permissions, but every plugin that defaults to OP does. I think it is my config that's messed up.

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

    Soulsinner

    Hello, is there a way I can make my players(all ops) remain ops, with the ability to teleport, change time but not spawn items? Is there a specific permission node for this? Or is there another pluggin which can do this job?
    And secondly, I tried to NOT have an op have permissions to everything, but somehow this does not work. Any help would be appreciated, maybe you can post an example of a config file showing how to not let the ops have all the permissions?
     
  7. Offline

    Human_v2

    I click on the server, to run it, and it says error, you don't have the right java. I went and installed the right java, but it still isn't working. Any ideas as to why this is happening?
     
  8. Offline

    IncendiaDrakon

    Can anyone confirm an issue with inheritance? I have three groups set up that borrow permissions from each other and it decides when it does and does not want to work. In theory, shouldn't this work out: default > vip > moderator
    As in, vip inherits from default and moderator inherits from vip. This results in moderator having all the permissions of default and vip. Well, players in my vip group keep losing access to commands, I don't understand why.
     
  9. Offline

    dunst0


    do you have something like this?

    Code:
    groups:
        default:
            permissions:
                server.guest: true
            inheritance:
    
        member:
            permissions:
                server.member: true
            inheritance:
            - default
    
        mod:
            permissions:
                server.mod: true
            inheritance:
            - member
    
        admin:
            permissions:
                server.admin: true
            inheritance:
            - mod
    
        owner:
            permissions:
                server.owner: true
            inheritance:
            - admin
    I did it that way, cause i had assumed that owner would have all rights because of inheritance.
    But it looks like owner just inherit the right of the admin group.

    So i change my config for owner like this:
    Code:
        owner:
            permissions:
                server.owner: true
            inheritance:
            - default
            - member
            - mod
            - admin
    It's not the right way to do but for now it works for me.

    By-the-way: don't look at the grammar, of my writings cause English is not my first language
     
  10. Offline

    skyranger

  11. Offline

    IncendiaDrakon

    Yes, I have it like that, but it doesn't really matter at the moment. The problem I'm having is inheritance working occasionally. I just want my vip group to inherit from my default group. It doesn't always work, which is weird. I'm only using PermissionsBukkit and SuperPermsBridge. I define my permissions in the PermissionsBukkit config, not my permissions.yml.
     
  12. Offline

    RustyDagger

    @SpaceManiac I had some issues with the dev build you posted default commands had alot of issues getting the info from the bridge with it and often lost all knolage of if it was allowed to let me do the command. mchat and minfo had some issues as well getting my chat formatting to work was a real pain.

    the weird bit is that every thing worked fine on my local test server but it really had a fit on my live server. I downgraded to the stable and every thing just worked (bar a few typo's in the file)
     
  13. Offline

    Jinux

    Apologies if this has already been answered but when I try the permissions command from console, it tells me I don't have permission. I thought console access was built in? :S
     
  14. Offline

    dunst0

    Console support is build in,
    but i had once an permission in the root permission.yml,
    which was default rule and setting permission.*: false
    after that permission commands where denied in console
     
  15. Offline

    RustyDagger

    I have an issue im trying to add a handful of permissions only to my creative map but it seems im having an issue where none of it is working :( good news is theres no yml errors but yet still not working. here is part of my file.

    Code:
        vip:
            permissions:
                minfo.group.player: false
                minfo.prefix.player: false
                minfo.suffix.player: false
                minfo.group.vip: true
                minfo.prefix.vip: true
                minfo.suffix.vip: true
                dc.do.Creative: true
                dc.do.Noob: true
                nocheat.speedhack: true
                nocheat.moving: true
                logblock.me: true
                dc.join.self.Noob: true
                dc.join.self.Player: true
                dc.join.self.Nether: true
                dc.join.self.Creative: true
                dc.fly.self: true
                dc.warps: true
                superpermbridge.dc.time.*: true
                dc.repeat: true
                superpermbridge.dc.weather.*: true
                dc.nopickup.self: true
                dc.hide.self: true
                superpermbridge.dc.mount.animal.*: true
                dc.give.self: false
                worldedit.superpickaxe: false
                dc.clearinventory.self: false
                dc.stack: false
            worlds:
                creative:
                    dc.give.self: true
                    worldedit.superpickaxe: true
                    dc.clearinventory.self: true
                    dc.stack: true
    
    found part of my problem i had a typo creative not Creative like it should of been :( but now users have /i in all my worlds EEEEEKKK
     
  16. Offline

    dunst0

  17. Offline

    Jinux

    checked that, not the issue. Here's my config.yml:

    Code:
    groups:
        default:
            permissions:
                permissions.build: false
                lwc.blockinventory: true
                superpermbridge.mcdocs./rules: true
                superpermbridge.mcdocs./commands: true
        user:
            permissions:
                permissions.build: true
                permissions.help: true
                lwc.protect: true
                superpermbridge.mcdocs./commands: true
                superpermbridge.myhome.home.basic.*: true
                superpermbridge.commandbook.who: true
                superpermbridge.commandbook.motd: true
                superpermbridge.commandbook.rules: true
                superpermbridge.commandbook.teleport.*: false
                superpermbridge.commandbook.locations.coords: false
                superpermbridge.commandbook.time.check: true
                superpermbridge.bc.status: true
                superpermbridge.stargate.use: true
            inheritance:
            - basicIC
        vip:
            permissions:
                superpermbridge.falsebook.ic.restricted: true
            inheritance:
            - user
        mod:
            permissions:
                permissions.*: true
                bb.admin.*: true
                lwc.mod: true
                superpermbridge.stargate.*: true
                superpermbridge.worldedit.*: true
                superpermbridge.myhome.*: true
                superpermbridge.commandbook.*: true
                superpermbridge.worldedit.*: true
                superpermbridge.worldguard.*: true
                superpermbridge.bc.*: true
            inheritance:
            - anyIC
            - vip
    
        boss:
            permissions:
                lwc.admin: true
                permissions.*: true
            inheritance:
            - mod
        basicIC:
            permissions:
                superpermbridge.falsebook.blocks.lift: true
                superpermbridge.falsebook.blocks.bridge: true
                superpermbridge.falsebook.blocks.cauldron.use: true
                superpermbridge.falsebook.blocks.door: true
                superpermbridge.falsebook.blocks.gate: true
                superpermbridge.falsebook.blocks.hiddenswitch: true
                superpermbridge.falsebook.blocks.hiddenswitch.create: true
                superpermbridge.falsebook.blocks.lightswitch.create: true
                superpermbridge.falsebook.blocks.lightswitch.use: true
                superpermbridge.falsebook.blocks.readbooks: true
                superpermbridge.falsebook.destroy.blocks: true
                superpermbridge.falsebook.blocks.area: false
                superpermbridge.falsebook.cart.*: true
                superpermbridge.falsebook.ic.standard: true
                superpermbridge.falsebook.ic.detection: true
            inheritance:
        anyIC:
            permissions:
                superpermbridge.falsebook.anyic: true
                superpermbridge.falsebook.blocks.area: true
                superpermbridge.falsebook.blocks.*: true
                superpermbridge.falsebook.destroy.blocks: true
            inheritance:
    messages:
        build: '&cYou do not have permission to build here.'
     
  18. Offline

    Jacek

    Hey

    I have been developing a whitelist plugin and when I kick a player with player.kickPlayer() I get errors spammed to the console relating to permissionsBukkit, the same error happens when I use the /kick command.

    Code:
    15:04:29 [SEVERE] Could not pass event PLAYER_QUIT to PermissionsBukkit
    java.lang.IllegalArgumentException: Attachment cannot be null
        at org.bukkit.permissions.PermissibleBase.removeAttachment(PermissibleBase.java:134)
        at org.bukkit.craftbukkit.entity.CraftHumanEntity.removeAttachment(CraftHumanEntity.java:104)
        at com.platymuus.bukkit.permissions.PermissionsPlugin.unregisterPlayer(PermissionsPlugin.java:137)
        at com.platymuus.bukkit.permissions.PlayerListener.onPlayerQuit(PlayerListener.java:24)
        at org.bukkit.plugin.java.JavaPluginLoader$2.execute(JavaPluginLoader.java:251)
        at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:58)
        at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:338)
        at net.minecraft.server.ServerConfigurationManager.disconnect(ServerConfigurationManager.java:146)
        at net.minecraft.server.NetServerHandler.disconnect(NetServerHandler.java:118)
        at org.bukkit.craftbukkit.entity.CraftPlayer.kickPlayer(CraftPlayer.java:135)
        at com.sk89q.commandbook.commands.ModerationCommands.kick(ModerationCommands.java:140)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sk89q.minecraft.util.commands.CommandsManager.executeMethod(CommandsManager.java:343)
        at com.sk89q.minecraft.util.commands.CommandsManager.execute(CommandsManager.java:256)
        at com.sk89q.commandbook.CommandBookPlugin.onCommand(CommandBookPlugin.java:245)
        at org.bukkit.command.PluginCommand.execute(PluginCommand.java:35)
        at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:129)
        at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:322)
        at net.minecraft.server.NetServerHandler.handleCommand(NetServerHandler.java:718)
        at net.minecraft.server.NetServerHandler.chat(NetServerHandler.java:682)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:675)
        at net.minecraft.server.Packet3Chat.a(Packet3Chat.java:33)
        at net.minecraft.server.NetworkManager.b(NetworkManager.java:226)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:86)
        at net.minecraft.server.NetworkListenThread.a(SourceFile:105)
        at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:453)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:363)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:422)
    15:04:29 [INFO] KICKED: wide_load (127.0.0.1) kicked player 'wide_load': Kicked!
    
    Just letting you know :) I guess you need to add a if (thing != null) or something.
     
  19. Offline

    sheepyowl

    i dont know if this was asked already, but if it was you might want to put it on a FAQ or something, because many people(me included) dont really want to read 21 pages to find one answer...

    why was the '*' node removed? now im going to have to go through every single plugin, to check if its using bukkitpermissions or the old permissions, and then if it uses bukkit's im going to need to set a permission for it not only for the users, but also for admins. the '*' node saved me a lot of work, as i have around 40 plugins.
    is it possible to have the '*' node as a feature again? imo it wasnt just to bypass a bug with whatever.* nodes not going through the entire plugin's node, it was also a pretty lazy solution for admin permissions. i like things that allow me to be lazy.

    sorry if i sounded rude.
     
  20. Offline

    zenyl

    Mind make this alot more like Permissions, cuz its allmost impossible to use together with plugins, older than this, and it messes up the whole chat system, when using iChat :(
     
  21. Offline

    RustyDagger

    @zenyl use mchat and minfo not that hard to set up really.
     
  22. http://forums.bukkit.org/threads/ad...mands-compatible-with-permissions-1000.11238/
     
  23. Offline

    zenyl

    "minfo" doesn't exist, lol
    But thx about the MChat tip :p
     
  24. Offline

    dunst0

  25. Offline

    zenyl

  26. Offline

    dunst0

    is your permission.yml, which is located in the root folder of cb, emty?

    btw:
    if you use the group basicIC to group some permissions​
    you could easily put the following in the permission.yml​

    Code:
        basicIC:
            children:
                superpermbridge.falsebook.blocks.lift: true
                superpermbridge.falsebook.blocks.bridge: true
                superpermbridge.falsebook.blocks.cauldron.use: true
                superpermbridge.falsebook.blocks.door: true
                superpermbridge.falsebook.blocks.gate: true
                superpermbridge.falsebook.blocks.hiddenswitch: true
                superpermbridge.falsebook.blocks.hiddenswitch.create: true
                superpermbridge.falsebook.blocks.lightswitch.create: true
                superpermbridge.falsebook.blocks.lightswitch.use: true
                superpermbridge.falsebook.blocks.readbooks: true
                superpermbridge.falsebook.destroy.blocks: true
                superpermbridge.falsebook.blocks.area: false
                superpermbridge.falsebook.cart.*: true
                superpermbridge.falsebook.ic.standard: true
                superpermbridge.falsebook.ic.detection: true

    then you just need to give the group or the user the permission node basicIC an the got the funktionality​
     
  27. Offline

    midget_3111

    Any news on a fix for when players join with no permissions with the dev build?
     
  28. Offline

    SpaceManiac

    Please try the development build with debugging enabled and let me know what it prints when you kick a player.

    Yes, I'm pretty sure I know the problem and will get something up shortly.
     
  29. Offline

    midget_3111

    Looks like Krinsdeath has added a commit which seems to have fixed the problem!. works brilliantly now for me :)
     
  30. Offline

    bugeye999

    Is it possible to change a player's group based on what world they are in? In my case, it is impractical for players to be in a single group with per-world permissions.
     
  31. Offline

    zenyl

    Can someone please make a tutorial on how to make this work together with MChat and MInfo? (I know there allready are such tutorials, but it would be neat with tutorials on English, and not on German)
     

Share This Page