[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

    Flatliner

    Just out of interest, I tried build 43 myself (I think I was using a slightly newer build) and that still produces the same problem. Are you on craftbukkit rb 1000? I'm on 1025 atm as I needed to be on 1024 or newer for multiverse 2.
     
  3. Offline

    Luke.Handle

    Yes!
    PermissionsBukkit manages the permissions each user has and the inheritance from groups etc.
    SuperpermsBridge is 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. And for plugins that do not use Superperms directly you can 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 and not to plugins using Superperms directly.

    Taken from FAQ above.
     
  4. Offline

    br0ad456

    i
    im so confused, so i use both of them but them what one do i put my groups and users in. the permissions.yml or the superperms config?
     
  5. Offline

    krinsdeath

    @Flatliner - I am indeed doing this testing on CB1000. I'll run some tests on 1025 to try and reproduce the problem, but since it's not a recommended build I didn't even think about it. Also, I am again unable to replicate any problems with Spout (build 65-69), or PermissionsBukkit, using CB1000. So yeah, I'll get back to you after I try some of the newer CB builds.
     
  6. Offline

    br0ad456

    @krinsdeath
    Code:
    users:
        Cas_Br0ad:
            permissions:
                permissions.build: 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.'
    this is my permissions.yml
     
  7. Offline

    Master_Rudik


    Rename that to config.yml and move it to /plugins/PermissionsBukkit/
     
  8. Offline

    br0ad456

    ok ill give it a go cheers
     
  9. Offline

    krinsdeath

    @Flatliner - Latest builds of MV2.0 and MVportals 2.0 require craftbukkit 1042+. Upgrading should fix the problems you're having. Furthermore, the latest builds of Spout and PermissionsBukkit should work fine (without the SuperpermsBridge, even!), so you should be good.

    If you have any more issues, let me know.
     
  10. Offline

    Jaxkr

    Not to be rude, but, this sucks. This will never catch on for quite a few reasons. The first reason being that it doesn't support Prefixes and Suffixes. Also, no Multiworld support. This will die out unless the Bukkit crew REALLY puts up a fight.
     
  11. Offline

    Master_Rudik

    Actually, this does have multiworld support, and it is actually MUCH easier to use than Permissions. In the beta, it works perfectly. The lack of prefixes and suffixes is not hard to get past, and it turns out mChat actually also makes it much easier to configure users than iChat.

    Plus, having all the permissions in one file along with the users is a feature I missed so much. With so many new worldgens coming out, I have 7 worlds running right now. Instead of changing seven different group/user files, I only have to change one.

    My only complaint is the lack of the all permissions wildcard '*', but that's also easy to get around, it only means one extra command whenever I add a plugin to reload the permissions along with it.

    But, I see your standpoint. To each his own, but I think that PermissionsBukkit is going to catch on fast.
     
    Luke.Handle likes this.
  12. Offline

    Jaxkr

    I see your point. But, it is impossible to set different users and groups for different worlds. That is what I meant by multiwotld support.
     
  13. Offline

    Master_Rudik

    Still possible, if you create a group and don't give them any permissions EXCEPT for in the world that you want that group to exist in, that will thus become a group in that world only. Then, if you put people into both groups, they will be part of the single-world group in one world, and the other group in your default world.

    It takes a bit of configuring and a bit of imagination to work out, but it would work.
     
    Luke.Handle likes this.
  14. Offline

    Singapore123

    Erm, I am using BOTH Superperms and PermissionsBukkit, and what ever group I am in, I can use ALL permissions! Like default, I can break blocks! Here is my CONFIG:

    Code:
    groups:
      default:
        permissions:
          permissions.build: false
      Moderator:
        permissions:
          'worldedit.*': true
          'commandbook.*': true
          'godPowers.*': true
          'godPowers.vulcan': false
          'permissions.*': true
          'freeze.*': true
          mchat.prefix.Moderator-ce: true
          permissions.build: false
        inheritance:
      Admin:
        permissions:
          mchat.prefix.Admin: true
          permissions.*: false
    users:
         Singapore123:
            groups:
            - default
         Andrechan:
            groups:
            - Moderator
         Player:
            groups:
            - Morderator
    
    I put myself in the DEFAULT Group, and I still have world edit permissions. But the mChat works.
     
  15. Offline

    krinsdeath

    This supports multi-world permissions much more fluidly than any other permissions plugin (aside from bPermissions). Simply define the permissions you want in the subnode:

    Code:
    groups:
      users:
        permissions:
          # this is a global flag, and will apply to all "users"
          permissions.build: true
        worlds:
          world:
            some.node: true
            that.node: true
            another.node: false
          world_nether:
            some.node: false
            that.node: true
            another.node: true
    
    With no additional configuration, users are effectively "two different groups" on the worlds you specify. If you want certain users to have access to whichever group on whichever world, simply set groups for the worlds you specify!

    Code:
    users:
      some_guy:
        groups:
        - builder
        - vip
      some_other_guy:
        groups:
        - builder
    groups:
      builder:
        permissions:
        worlds:
          world:
            permissions.build: true
          world_nether:
            permissions.build: false
      vip:
        permissions:
        worlds:
          world_nether:
            permissions.build: true
          world_skylands:
            permissions.build: true
    
    @Singapore123 - Are you designated as an op in ops.txt? WorldEdit will default certain permissions to op if they're not explicitly defined as false permissions, meaning your powers won't be influenced by your group.
     
  16. Offline

    Singapore123

    Oh! I must try to make my friends more VIP. Oh well. Thanks!

    EDIT: Will it be the same with "Essentials"?
     
  17. Offline

    sirmyllox

    Question on the world level permissions .. could i skip an existing world in the world level configuration of permissions and retain the group permissions for that "skipped" world .. ie group level permissions are global? in my code box i deny worldedit on a global level and allow in world "heaven" .. would that be correct?
    Code:
    groups:
        default:
            permissions:
                superpermbridge.worldedit.*: false
                superpermbridge.worldguard.*: false
                dc.*: false
            worlds:
                heaven:
                    superpermbridge.worldedit.*: true
    
     
  18. Offline

    krinsdeath

    @sirmyllox - As of the latest WorldEdit build, I don't think you need to specify the superpermbridge prefix. However, I do believe your suggestion will work.
     
  19. Offline

    Zenithas

    *Reads through first page*

    These is a very, very limited selection of permissions explanations here. The questions below are very urgently needing to be addressed on my server, as I won't be comfortable with running this plugin/remake until after they're addressed.

    I'm not reading through 24 pages of notes to find information that according to basic common sense, should be covered in the first page. This makes my brain hurt.

    1) How do I manually convert entries from the old Permissions 3.x to this? Just add :true or :false?
    2) How do I set a default group?
    3) How does one set up multiple worlds?
    4) Failing this, can one still simply use regular Permissions?
     
  20. Offline

    Flatliner

    Just tried with the latest builds you mentioned and it's still the same. I should add that during my testing (just in case you've been doing it differently) I've only had 3 plugins installed. PermissionsBukkit, the superperms bridge and Spout. I've removed myself from the op file so that I don't have access to the permissions commands from that (I have them only from being in the admin group). When I join the server I have access to the permissions commands via the admin group. After a reload (issued through the console since I'm not op) I can't access the commands anymore until I reconnect.

    The op part is important as when I first started testing this I thought I had fixed it because the permissions nodes were showing up in a perms dump but they were only showing because I was op.

    1) For the most part yes. If you have any wildcard nodes (like somepermission.*), then you'll need to use the superpermbridge (this is explained in the first post).
    2) The group named default (which is added automatically) is the the default group, as far as I know it can't be changed.
    3) You would do it like this:

    Code:
    groups:
        default:
            permissions:
                permissions.build: true
                worlds:
                    world:
                        world.only.permission:true
                    world_nether:
                        nether.only.permission: true
    
    4) Yeah you can absolutely stay with Permissions, you're under no pressure to switch to this unless your plugins start phasing out support for the Permissions plugin.

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

    Luke.Handle

    In the example config it does show MultiWorld support.
    Also in the FAQ in does answer many of the questions and IMO is an excellent place to start. It gives a link to a tool that c an assist with the converting of the files. Personally, I just took it as an opportunity to re-build my permissions and that was it.
     
  22. Offline

    krinsdeath

    @Flatliner - Out of curiosity, are you using permissions.yml to create node templates for your groups? As far as I can tell, this is the only thing that may differ between our setups. I was unable to replicate any of your problems with CB b1000-1046, Spout b43-69, PermissionsBukkit b18 and MV b186-210. I've tried using permissions.yml to construct a template for my nodes, as well as a multitude of other things. I simply cannot replicate this problem. :(

    @Zenithas - The default group is provided (by default). It's called "default." Multiple worlds are explained (by me) in this post. Regarding questions 1 and 2, the most simplistic answer is "yes." As this system becomes more widely adapted by plugin developers (and it will, since it requires absolutely no effort to maintain and will never break as a result of an update), Permissions 2.x/3.x support will be largely phased out.
     
  23. Offline

    Flatliner

    @krinsdeath So strange :( In the interest of thoroughness I've just thrown up my entire minecraft folder (it's small as I've been doing my tests on my local machine with a fresh world, no plugins except those mentioned etc). Can grab it here, its only 10mb.

    If you change my name to yours in the permissions config, launch the server, type /perms (it should work), then type reload into the console (not in the ingame chat as you won't be op), then try doing /perms in the game, it'll say you don't have permission.

    edit
    Actually just noticed something in the logs. If I join the server and then leave (with permissions still working) I typically get this in the logs:

    Code:
    14:16:57 [INFO] Flatliner_ lost connection: disconnect.quitting
    14:16:57 [INFO] [PermissionsBukkit] [Debug] Player Flatliner_ quit, unregistering.
    But after I do a reload, if I leave I get this in the logs:

    Code:
    14:17:25 [INFO] [PermissionsBukkit] [Debug] Player Flatliner_ quit, unregistering...
    14:17:25 [INFO] [PermissionsBukkit] [Debug] Unregistering Flatliner_: player did not have attachment
    It could be an irrelevant difference but I thought I'd mention it.
     
  24. Offline

    vildaberper

    This is impossible to work with as a developer, please add this to all of your listener's methods:
    Code:
    if(event.isCancelled()){
        return;
    }
    Would be great, thanks! :)
     
  25. Offline

    krinsdeath

    @Flatliner - Weird. With your minecraft installation, I was able to replicate your problem. The solution? I moved my PermissionsBukkit.jar into your minecraft's plugins dir, and it works as intended. I tried it with the last successful build (here), and that works as well. You just had a wonky jar, I think.

    What an odd problem.

    edit: replacing the permissions bukkit jar is literally the only thing I changed, and it fixed the issue

    @vildaberper - This plugin only modifies three events; block place, block break, and player interact. Each of these directly correlates with one of its primary features, which is "build: true/false"

    The point of that feature is that it modifies these events according to the user's permissions. I do not understand what is causing you so much grief.

    I (as a developer) have never run into issues with any of this.
     
  26. Offline

    Flatliner

    @krinsdeath Well I just threw in the permissionsbukkit jar you linked to, still doesn't work for me. I've managed to reproduce this in the same way on 3 different machines now with clean installs and freshly downloaded copies of all plugins and craftbukkit and fresh config files.

    This is easily one of the most annoying things I've ever tried to pin down.
     
  27. Offline

    krinsdeath

    @Flatliner - I see in the zip that you sent there's some MacOS stuff. Are you running this on a mac? I've done the same thing on my server (Debian Linux), my local test (Slackware 13.37), my local server (FreeBSD 8.2) and my windows PC (windows 7 professional ultimate 32bit), and cannot replicate this problem EXCEPT with your zip'd minecraft server. Maybe try upgrading to CraftBukkit #1046, PermissionsBukkit #19, and no other plugins (not even SuperpermsBridge).

    Only other things I can suggest are to try upgrading Java (JDK1.6.0_26 if possible, or JDK1.7), or trying to run it in 32bit mode rather than 64bit.

    I'm at a loss. It really makes no sense to me that it would work for me and not for you, using identical settings.
     
  28. Offline

    vildaberper

    That would be great, but I saw in your source that you do not check if the event is canceled in any of your methods in your PlayerListener.
    Therefore, its impossible to cancel an event (ex. kick), without making your plugin throw errors:
    Code:
    2011-08-10 16:10:22 [WARNING] vildaberper was kicked for floating too long!
    2011-08-10 16:10:22 [SEVERE] Could not pass event PLAYER_KICK 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.onPlayerKick(PlayerListener.java:29)
        at org.bukkit.plugin.java.JavaPluginLoader$4.execute(JavaPluginLoader.java:265)
        at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:58)
        at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:332)
        at net.minecraft.server.NetServerHandler.disconnect(NetServerHandler.java:96)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:354)
        at net.minecraft.server.Packet10Flying.a(SourceFile:126)
        at net.minecraft.server.NetworkManager.b(NetworkManager.java:226)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:85)
        at net.minecraft.server.NetworkListenThread.a(SourceFile:105)
        at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:451)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:361)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:422)
    2011-08-10 16:10:22 [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:332)
        at net.minecraft.server.ServerConfigurationManager.disconnect(ServerConfigurationManager.java:146)
        at net.minecraft.server.NetServerHandler.disconnect(NetServerHandler.java:117)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:354)
        at net.minecraft.server.Packet10Flying.a(SourceFile:126)
        at net.minecraft.server.NetworkManager.b(NetworkManager.java:226)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:85)
        at net.minecraft.server.NetworkListenThread.a(SourceFile:105)
        at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:451)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:361)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:422)
    That is what happens when I cancel a PlayerKickEvent.
     
  29. Offline

    dunst0

    even if it is not likely that you would run into issues,
    its always better to write your code as bulletproof as possible

    hope you get what i'm trying to say, ... i'm not a nativ english speaker,
    so its sometimes not easy to express my thoughts.
     
  30. Offline

    Switch0r

    Does worldedit and worldguard run on permissionsbukkit 1.1?
    I have the latest dev build bukkitpermissions running.
     
  31. Offline

    Flatliner

    The main server where I first had this problem was a linux machine (ubuntu 10.04 running java 7), as you rightly said, the zip file I put up was from a server running on my mac. I've also reproduced this on my windows 7 64-bit machine running the latest java 6 update and a virtual machine running ubuntu 11.04.

    In each case I downloaded the files from scratch and used no copies of files from any of the other installations. Latest builds of craftbukkit, permissionsbukkit and spout were used in each case.

    Don't suppose anyone else tracking this thread has ran into this problem?
     

Share This Page