[REQ] Take Over Permission 3.1.6 ?

Discussion in 'Archived: Plugin Requests' started by paunk, Oct 19, 2011.

  1. Offline


    Permission 3.1.6 is inactive now, but i still use that plugin until this time.

    The reason is that plugin is simple and really easy to use. The in-game commands are structured really well. I think its the best permission plugin. Its just "work" if you know what i mean.

    Lots of server owners i know still use that permission too.

    It will be really great if someone take over that plugin and update it to make it compatible with the next craftbukkit builds.

    If its updated, plugin developers will also make their plugins compatible with 3.1.6. Lots of new plugins didnt support 3.1.6 anymore. And also, some of existing plugins dropped their 3.1.6 support.

    If someone willing to take over permission 3.1.6, i will 100% suuport and maybe i will donate some money too.
  2. Offline


    No. There are good alternatives, time to move on.
  3. Offline


    uhmm ok lol.

    which is the best ? PermissionEx or bPermissions ?

    I tried both but cant make them working :/. Maybe ill try it out again tonight.

    and BTW, a lil off topic

    i used your banana protect and still works great in 1185 :D
  4. Offline


    Someone has a specific plugin and wants to advocate it :p?
    if Permissions 3.1.6 still does the job well enough, why move? "bPerms support" is a joke.
    It only takes about 2 minutes to implement that in Permissions as well.
  5. Offline


    yea 3.1.6 still works great in my server (1185). Its really simple, easy to use and just "work". I hope it still works for the upcoming bukkit build for 1.9

    The problem staying at 3.1.6 is new plugins that dropped their support for 3.1.6 because its being inactive.

    and by the way what do u mean by "bperms support is a joke" ? :rolleyes:
  6. Offline


    Permissions 3.x is unsupported and obsolete. It requires plugin devs to add and maintain specific support for it, instead of just using player.hasPermission() and not worrying about which (superperms-compatible) plugin provides the implementation. It needs to be laid to rest; even the original author (Niji) has said so.

    I'm dropping Permissions 3 support in my plugins, not just because it's inactive, but because it's the Wrong Way To Do It. Even if someone was to try and revive it, the chances of me continuing to support it are zero, and I suspect I'm not the only plugin developer to feel that way.

    It worked OK at the time because there was no better alternative, but it's no longer needed. Please, just move on. PermissionsEx, PermissionsBukkit, bPermissions, zPermissions... they all work fine, and are superperms-compatible.
  7. Offline


    I could easily make permissions 4 - but it'd just be permissions 2 with superperms, what'd be the point?
  8. Offline


    What i meant was that implementing BukkitPerms support into Permissions is easy. It took me less than 5 minutes.
    I could "release" it, but i'm not sure if TheYeti/rcjrrjcr would be happy if I did.

    Also, please do elaborate. "The Wrong Way To Do It". Not supporting Permissions, but willing to support PermissionsEx is wrong in my view. Most of the plugins just use the "hasPermission()" aspect of it.
  9. Offline


    There are lots of good permissions managers out there, the "permissions" series of plugins is dead. Time to move on.
  10. Offline


    I don't see any elaboration part. "just move on" isn't a good answer.
  11. Offline



    im starting to get it now. So, if a plugin dev want to make it compatible with permission 3.1.6, they must add something specific in the code to do that.

    And, if they want to make it compatible, they can just use the player.haspermission() and it will automatically compatible with all permission plugins that support superperms.

    well, if this can be done, and you can get the permission from rcjrrjcr and the yeti, im sure lots of people will love it.
  12. Offline


    That's missing the point of superperms: I, as a plugin writer, don't need to write any explicit support for PermissionsEx, because it's a superperms-compatible plugin. I use player.hasPermission() - any superperms plugin Just Works.

    The "The Wrong Way To Do It" was to require plugin writers to write explicit support for every permissions plugin that their users wanted. That led to a lot of ugly code and well-intentioned but failed attempts to create a proper bridge (who remembers APIHandler?).
  13. Offline


    Your first argument invalidates itself by the entire purpose of this post, namely updating Permissions. If Permissions were to implement player.hasPermission(), but keeping the "easiness" of Permissions (i.e. a rewrite of the current system), it would be a better option than switch out Permissions for some other plugin.

    About your second argument, the apparent "Wrong Way" isn't so wrong as you make it sound. Not only should you implement multiple ways of permissions in your plugin, even if there is no uniform system, but it's easy as hell too. It's about 10 seconds work, and 10 lines of code, plus, if you've done it before, it's almost copy+paste work.

    Even though I don't have the time to pick such a project up, I do support it.

    BTW, Permissions does more than just player.hasPermission...
  14. Offline

    Don Redhorse

    well Permission 3.x was broken... internally... you are lucky you didn't see the problems.

    using pex is easy... it even converts iirc... similar to the other superperms managers..

    info, prefix and suffix doesn't have anything to do with permissions... it has to do with identiy... problem is though that Permissions did implement it and a lot of plugins did use it and there is no alternative... unfortunatly this means that either plugin writers who need those features need to write their own implementation or that superperms managers are implementing that feature which brings us back to square one for those plugins...

    but at least most plugins don't need those features and for them life has become easier.
  15. Offline


    I choose GroupManger. ;p
  16. Offline


    No no no no and no just leave permissions alone theYeti has left it and so should we with the new superPerms system its far easier to code and better for you just get a superPerms plugin and be happy :)
  17. Offline


    I'd suggest you switch to PEX.
  18. Offline


    If someone wants to add superperms functionality to Permissions 3, that's fine. It'll be automatically supported by any plugin which uses superperms. And anyhow, PermissionsEx already pretty much does that: it has a config file style pretty much like Permissions 3, and it's superperms-compatible already. I'd argue that any Permissions 3 rewrite is a bit unnecessary at this point..

    It's not hard to hook into a plugin-specific API, but that doesn't make it the right way to do it. Because then someone else comes out with a new permissions plugin with its own API, and then someone else does... you end up with a mess of unnecessary code as you try to support multiple incompatible permissions plugins that each do it their own way. That's how it used to be, and is indeed the Wrong Way.

    Trust me, I know that. Having worked with various permissions plugins to allow commands to be run with permission elevation/bypass, extracting nodes for users, checking groups, I'm pretty familiar now with the various API's, and for that reason even more convinced that a common API is really the only way forward.
  19. Offline


    Its dead, Jim. SuperPerms is alot more efficient and has official bukkit support.
  20. Offline


    SuperPerms a lot more efficient, right.
    The inability to put people into groups is a major pain in the butt. (the non-world aware permissions are as well)

    Also, PermsEx indeed does import from perms 2.x, but it only does that for the yml files. Not from the MySQL DB.
    Ugh, i think i'll just write a Perms SQL -> PermsEx SQL myself then :p.
  21. Offline


    Any bother sending me perms 3 with superperms support? :3
  22. Offline


    Superperms isn't groups, the permissions plugin you use is groups :confused:
  23. Offline


    And now in English? :p
    I am aware of those issues codename_b, that's why you have to reapply every permission every time a player moves from a world to another. Even though it does it in a jiffy doesn't mean it's the right way.
  24. Offline


    It's up to a permissions plugin to be world aware, (and with the newly added API it's easier than before.) since it depends on the server if they want different permissions based on worlds.
  25. Offline


    being world-aware always has been easy, if you wanted to check which world a player is in you just use player.getWorld(). It's been that easy ever since multi-worlds were added :p.
    what do you mean "with the newly added API it's easier than before", no, you have to reapply the permissions whenever the player switches worlds, how is that "easy".

    But this is going way offtopic. I could go on for months why Permissions 3.X isn't "as bad" as you make it out to be.
    Yeah the SQL DB is quite iffy, rcjrrjcr did over analyse it quite a bit :p. But in the end it's the API that counts. Permissions isn't bad at all on that part. Neither is PermissionsEx.

    You could argue on the commands though. If you're not 100% sure of what you're doing it could go haywire like that. (I'm talking about the new "old" permissions command)

    To be honest, the ONLY issue i have with permissions at the moment, is the inability to hand out permissions to a player that'll only count on that world, but without having to add him to a world specifically made for that world.
    If you add it like "/prold player w : otherworld perms add" it'll add it to the original world in stead of the inherited world.
    that's the only issue I personally have with it :p.
  26. Offline


    Other issue is the lack of offline permissions.
  27. Offline


    Don't know what you're talking about there, i can manage permissions for players that aren't connected just fine.
  28. Offline

    Daniel Heppner

    Why would anyone want to store permissions in a MySQL database? That's practically the worst use of a database I've heard so far. Totally pointless, a flatfile is much more fitting in this case.

    BTW: Permissions is dead, use PEX. 1000x better.
    thehutch likes this.
  29. Offline


    I've heard worse, people want configuration in MySQL.
    thehutch likes this.
  30. Offline


    Permissions is dead. Last time someone tried to resurrect Permissions this happened:

    Link to said thread
    Nijikokun's official statement on Permissions and how to switch to PEX

    Can this thread be locked for the sake of every developer in this community?

Share This Page