[Split] PermissionsEx discussion

Discussion in 'Bukkit Discussion' started by Alexander852, Dec 22, 2012.

Thread Status:
Not open for further replies.
  1. Offline


    approved plugin =/= well coded plugins.
    approving - no stolen code, not malicious
    PEX is currently answering both, thus its approved, since not approving it because its bad coded goes a bit too far.
    also, thinking outside the box =/= breaking everything.
    also, the only plugin that staff recommends not using is PEX, thats FAR from forcing a permission plugin, considering 8 other exist.

    the error is when PEX crashes due to invalid permissions.yml, essentials is unable to check superperms.

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



    THANKS! a Essentials/PEX User! Exactly make sure your up to date and inform the Developer of a Bug and they will fix it.
  3. Offline


    Ah. That makes more sense now. Yeah I've had that happen before, but its usually fixed within 5 minutes and only happens when whoever edited the file forgot something silly, so its not a huge deal for me personally in that sense. It is a pain whenever an error happens and you get X amount of people screaming at you to fix it, however...The joy of the complaint department...
  4. Offline


    what you say that is that they have to be well coded... well that would be that the code would have to... not cause deadlock or crashes. if ANOTHER plugin not Bukkit causes PEX to crash is it PEX's fault that it did? not really it happened, so lets fix it so they work better that's what we've been aiming for this whole time a group of plugins that work perfect together.. that do what WE want not what Bukkit wants plugins to do. since it's up to us to decide what we want for ourselves and by no means should be locked down to one persons view of whats better for the "community" I do know exactly what I am talking about, Thinking outside the box breaks everything... I'm sorry that you live and think with a one track mind and it's this way or no way. but there are a lot of free thinkers out there that "think out side the box" and they didn't "break everything" things break because of mistakes in code not because of thinking outside the box, all that leads to is wonderful creations.

    They are Forcing there hand and saying the only one that has true database support is bad and advising all potential new users away from PEX even though they probably will not have an issue migrating to PEX and if they use a SQL database they will have protection of there data. The main point that you all miss and never disagree with is PEX IS SUPERIOR due to the fact that it protects your permissions (with the use of SQL) from being reset to blank and all of a sudden a riot breaks out because there are no more permissions! oh and what about that PEX everything has to be allowed not denied. you automatically are not allowed to do that well that's much better then anyone joins my server while I'm tinkering with permissions and breaks everything.
  5. Offline


    if another plugin caused the crash, it would be that plugin fault. PEX causes the crash, PEX's fault.
    and yes, WE want a plugin that uses the standard API instead of causing a major amount of grief to developers and admins. this isnt one person's view, this is a view of many people. and no, that doesnt mean everyone should stick to the same way, see Bpermissions, also has things out of the box, but unlike PEX, it does it WELL
    also, if the only reason you use SQL is because of permissions file breaking due to crash, that also applys to SQL, and the best solution is to simply backup. (GroupManager does it, for example)
    also i dont understand your last 2 sentences, you dont know how to make a server whitelisted?
  6. Offline


    I did update it as I always do but th reload issue was still there ... Lets just call it preference then I prefer Group manager over PEX as I seemed to have less issues
  7. Offline


    no that's not the only reason I use MySQL and if something let say causes my pex config.yml to be reset my database gets untouched because it's not the default .yml that would also get reset it's securely locked away on a remote location that can only be accessed if the config.yml was not reset there for being 100% fail safe from itself and every other plugin and bukkit I use only plugins that have MySQL support unless I really cannot find one. making a back up of just my config files it's alot easier then making a back up of everything and then when I need to backup MySQL i just execute a Dump and I take a load off. and dump well over 8m entries all backed up in to a single .sql file instead of multiple files and folders like the config's.

    also why do I want to whitelist? PEX denies the right to do anything by default.

    if your trying to type /reload ( that's a bukkit server command not PEX and has always been bugged) try doing /pexreload when you want to reload your pex files. I've never once had an issue I reload while people are breaking and building no problems not chat issues nothing because its all stored data that's pulled when it's needed and stored in ram.

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


    i still dont see how what you do is any different than an automatic config backup.
    also, EVERY permission plugin gives nothing but the basic permissions, if anything, to default. even then, you should always setup your permissions BEFORE you launch server
  9. Offline


    Well obviously you need it set up before the launch but with out testers who says it works? you need to be online to get testers and, screw whitelisting I can just do live edits of PEX perms in Navicat and then type /pex reload in game chat and boom new commands across the boards. I can design a website to edit add remove permissions that can be accessed anywhere and with it It could also do grief management and inventory management anything that can be stored or held can be managed by MySQL and accessed VIA and Smexy looking GUI on a website with user/pass req, but since Bukkit doesn't care about making things EASIER just take longer that's why they choose the NO TABS PROPERLY SPACED .yml flatfile instead. I mean it's brilliant no way to truly edit it with out opening up a text editor... where if they chose the EASY TO SET UP MySQL they could have developed a whole web interface around bukkit to control/configure every aspect all data/config stored in MySQL but then again they must be getting paid by Mojang because that would make Bukkit 100% superior to mc server
  10. Offline


    nobody forced PEX to use .yml. PEX chose YML. people might aswell used .properties or .json, but they didnt. see YAPP permission plugin. also everything you mentioned can be done with any permission plugin, without needing SQL.
    slipcor likes this.
  11. Offline


    I didn't say anyone forced pex to use .yml they offer that because it's standard to bukkit.

    YAPP looks nice but it is a lot messier then just having 3 MySQL tables handling all your permissions.
    the in-game GUI for editing is a nice bonus as well but still PEX is superior with WEB access not in-game access I can edit permissions and (other plugins settings that are hooked in to MySQL) while not even being in a location to play the game... IE from my tablet or Smartphone while in the boonies on EDGE network not 3G or anything.

    YAPP was only updated to 1.4.6 1 day ago yet PEX updated on the 24th I know your not complaining but that proves that the Devs for PEX are fixing it.
  12. Offline


    I'd just like to point out that YAPP did not break with 1.4.6, so it did not need an immediate update. The update added new features and fixed a couple pre-existing bugs, it did not repair any breakages caused by the 1.4.6 update.

    From what I've seen, many server admins are happy with PEX, because it seems to work great for them all the time. However, you'll find that many plugin devs do not like PEX as much. This is because PEX has tended to break Bukkit functionality in the past, and when it has done so, it makes it look like other plugins have broken. So, then the server admin assumes that plugin is broken, and goes to the dev for that plugin to complain. Then the dev spends forever trying to figure out what is wrong with their plugin, only to discover that it was PEX all along, and not their plugin at all. I speak from experience here.
    desht and slipcor like this.
  13. Why would you want to look up permissions concurrently? The Bukkit API is not thread safe on that account anyway, and i personally distrust any attempts to make permissions thread safe by the nature of the whole thing, because with reasonably simple implementations that just slows down all the frequent lookups done in the main thread (and makes deadlocks possible if they don't have them in mind enough :p ).

    If that was an official feature you might blame PEX for it not working, but most servers are not in need of such for sure, in fact relying on such would show the devs to be unexperienced and/or pretty desperate and/or lazy/savage. As far as i know PEX had not officially been allowing concurrent lookups (at least until that commit "concurrency for superperms", which i would not blindly trust without further inspection), though i might well be mistaken on that. At present the main page of PermissionsEx does not show anything about concurrent lookups.
    s32ialx likes this.
  14. Offline


    Something cool about the author of bPermissions (and the author of PermissionsBukkit on occasions) are that they are on the bukkit forums to help people out with their plugin. I haven't seen the creator of PEX doing that.
  15. Offline


    I realize that and type /pex reload to reload pex but it was causing issues either way I am much happier with Group manager
  16. Offline


    Would PEX benefit from a complete re-write ? I think that's the plan by the devs
    s32ialx likes this.
  17. Offline


    Personally IMO All project eventually benefit from complete re-writes it's very genius and logical as down the line you implement code much cleaner and simpler kinda like what bukkit and mojang are doing with the class renames etc which is why the "safeguard" was brought in to fruition transitioning easier in the end.


    I hope everything with GroupManager goes as smoothly as things have with PEX and I, must have been a plugin that does not get along with PEX either on PEX's end or the plugins maybe you'll try PEX again later but who knows. glad your enjoying your server that's the main point to this.
  18. Offline


    Bukkit doesn't stamp plugins with a seal of approval, we only try our best to make sure malicious plugins don't get uploaded. That's all we can do and it is already a lot of work.

    All we're doing is trying to give server admins peace of mind that if they're running a plugin from BukkitDev, chances are it doesn't let the author do anything malicious (to the best of our ability). That is all. We do not verify if the plugin is properly coded, properly designed, efficient or anything else whatsoever - doing so would delay the already busy approval queue significantly and hinder plugin developers more than it would benefit the community.

    You are severely misinformed. There are absolutely no problems with /reload itself. Any problems you have with /reload are due to plugins you are using not properly handling /reload (not having proper plugin enable and disable handling).

    All I've learnt from this thread is that you are blindly defending a plugin you have no experience with. We have a ridiculous amount of experience with PEX as we provide support to people that use it every day and it is one of the most common causes of issues across our support load. Not only is it volatile, but it goes out of its way to break the Bukkit API many plugins and developers depend on. I don't see how you can sit there and tell people with a straight face that "every other plugin is broken, PEX is fine" when it is PEX that is breaking all the other plugins, not Bukkit and not any other plugin.

    If you're going to defend a plugin and try and put yourself out there as an expert of that plugin, you should probably be more familiar with the plugin and how it works internally and externally. Same applies if you're going to flat out misinform people about what BukkitDev's purpose is.
  19. Offline


    evilseph sure. I never claimed to be any sort of expert ( although I have been a certified technician in computers/networking since 2005) I'm just defending from my own personal experience and others chip in with there own even ones with "claimed" plugins that cause errors saying no error there after it was correctly set up.

    I never said "every other plugin is broken" but I do say that a "user" can cause plugin conflicts if they don't know what they are doing as for conflicts with PEX I avoid most plugins that don't say PEX compatible as I'm sure most PEX users that have any CLUE of what they are doing also do. I know you speak ALOT of about issues across our support load being mostly PEX related but I'm also certain that most of the issues across your support load are incompetent users that shouldn't even be attempting to run any kind of server. (again MOST not all because even the most experienced users sometimes still need support)

    I get that you need a ton of people to test and submit bugs, but just because you have a lot of people using Bukkit does not mean they can. and I respect that you guys do your best to support every issue that arises but again why would you let your staff bash good plugins I don't see any proof if this "volatile code" still and just because they go outside the box does not mean they are bad you talk as if you expect every plugin to work flawlessly together but you know that's never going to happen unless you enforce strict coding standards and your not willing to do that or maybe you are we'll see but the point of "open source" and freedom is for us to have a Choice of which plugin and which data storage type we use. Why is PEX the only Perm plugin with MySQL support? which is the most superior database around SQLite is just as robust but not as editable
  20. Offline


    It isn't.
    What the actual fuck does "not as editable" mean? MySQL and SQLite aren't comparable, they both have their uses, and one is not better than the other.
  21. Offline


    Thanks I'm going to do alot of looking in to that plugin not that I have issues with PEX but reducing to less plugins instead of PEX,Modifyworld,Chatmanager, plus WG and HC adds bloat

    all I was trying to get across there was the SQLite flatfile from my understanding is not alterable like MySQL via website scripts hooking in to it as maybe I'm wrong but from my experience that's what I gather.
  22. Offline


    There are website scripts that allow you to alter SQLite files.
  23. Okay, I'm trying to end this debate once and for all by creating a plugin that will break with PEX.

    I've got this, so far, based on what some of the people posting here have said will break PEX. What else should I add to the plugin to make it break with PEX?
  24. Offline


    I'll second that. I've learned to hate PEX through all the problem reports I've had on ScrollingMenuSign which turned out to be with PEX. Stupid things like the daft '*' node which basically breaks any negated permissions, and PEX's inability to correctly handle parent/child permission relationships (these problems may well be fixed by now, but the PEX author was not interested in any reports I sent).

    PEX Is liked by server admins, I guess because the config syntax is like the old P2 syntax, but plugin devs rightly despise it.
  25. On many aspects PEX has upsides as well. I can't tell about the support-skills of PEX dev(s), but i have had some reference of those of the Bukkit team also concerning communicative skills. So i think you should not continue blaming the PEX devs, if it has been fixed, though i understand frustration in general. Also use of the '*' node is not that complex a thing, it is a useful feature and is up to the admin to use it or not.

    In my opinion it is a flaw that Bukkit does not have a concept for a '*' node, OP is a classical vanilla concept.

    How do negated nodes work anyway with several plugins adding permisisons? They simply don't make much sense, as far as i know, a concept for that is missing in Bukkit, feature requests about priorities (overriding principles are mostly missing in Bukkit) got getting rejected by default in the past with Bukkit, leading to the question how they had plugin compatibility in mind with designing superperms.

    Certainly superperms was an improvement to before, and it is not bad, but it is also not that great after all.

    I can't remember having many substantial issues with PEX with any of my plugins, amongst which one does dynamic permission adding/removing. More problems i would have with superperms itself :) (that's somewhat polemic though).

    Add brains please, concurrent permission lookups are stupid by default so are most Bukkit-API calls (no offense, but such things are plain bashing attempts, this does not help).

    Actually reload is not that clean, because a concept for "a permissions plugin" is missing in Bukkit, so one can not (soft-) depend on all "the permission plugins". If you reload you can have players online, but the permission plugin
    has not yet been loaded and you can't possibly know all permission plugins names. So what is the solution? Saying "reload is perfect with (Craft-) Bukkit" does not seem to be the full truth about plugin compatibility.
    s32ialx likes this.
  26. Offline


    Bukkit should just make a powerful permissions plugin with features similar to PEX or integrate one like bPerms or whatever they like and have it distributed with each latest build don't you guys think?
    s32ialx likes this.
  27. Offline



    Wicked return! ;P I don't know all the technical aspects of it all so me trying to defend this alone gets hard against coders, thanks for the great input and I agree hmmmquestionmark is not helping either side.

    tanveergt5 your 100% right I don't think bukkit should have left something as important as USER RIGHTS to freelance developers I personally think they should have took on the roll of permissions/rights themselves but they have the BEST EXCUSE it's already cumbersome enough pushing out the builds why would we want to add more work to our load... well that's easy to answer bukkit staff stop doing bukkit or do it properly and not half assed permissions are suppose to be HARD CODED not a soft plugin. whether or not they "WORK fine as is" is moot the fact of the matter is you need to have that kinda thing as part of the whole package not an addon.
  28. I know that using Bukkit-API calls in an async repeating task is not smart, but that's what I heard people say was causing the issue, so I was trying to replicate it.

    I might have misunderstood what mbaxter said, but I read his comment earlier in the topic saying to do just that:

    I personally use PEX on my server and have had no noticeable problems with it. I'm simply trying end the debate once and for all in the only way we actually can: with experimental proof. I'm not trying to help either side, I'm trying to find the truth.
    falkensmaze and s32ialx like this.
  29. Offline


    maybe because its not permissions* its permissions.*
    and op does the same exact thing unless you disabled full op perms -_-
    tanveergt5 and s32ialx like this.
  30. Offline


    anyone imo that doesn't disable full op perms is asking for trouble.

    Thanks for clearing that up with me I understand what your trying to do.
Thread Status:
Not open for further replies.

Share This Page