Which permissions plugin do I use?

Hello, I've been developing for a while now. However, many permissions plugins have died. What is the most common permissions system being used that I can use in my plugin? Thanks.

 

Umm, just use:
if (player.hasPermission("")){}

thats universally used..

 

Bukkit has an official permissions plugin. I'd guess it's not as fully featured as some of the other permissions-implementing plugins though.

http://dev.bukkit.org/server-mods/permbukkit/

 

If you mean what permission plugin you want to use choose PermissionsEX. It has the * node.
Don't ever use PermissionsBukkit! It is barely updated, the creator doesnt do any c*** about help tickets! So in conclusion; it sucks my duck...
If you mean the universal permissions system just use

PHP:

if (player.hasPermission("")){}

 

Try not to suggest PermissionsEx as it doesn't always work how you think it will.

 

PEX is probably the worst perms plugin out there. mbaxter wrote an entire page on how it fights bukkit, and at one time it broke op permissions, and it has broken player permissions several times, making players blame bukkit because they didn't know about it.

 

Or making players blame your plugin for permissions problems when in fact it was PEX's broken behaviour causing all the problems. PEX is... not high... on my list of favourite plugins PermissionsBukkit on the other hand is rock solid, and bPermissions is also very well-written.

But to just check if a player has a particular permission node, use the built-in player.hasPermission(). There is absolutely no need for anything else.

If you want to check or manage permission groups or give/take permissions to/from players, use Vault - don't tie yourself into a particular permission plugin's API.

 

Group Manager seems to be doing good for me, but ya avoid PEX...

 

Okay so the default built in system as well as SuperPerms. Thanks for all the responses.

 

Huh? BuildIn == SuperPerms... http://wiki.bukkit.org/SuperPerms
And the page that Jnorr44 was talking about is: http://goo.gl/MHhbl

 

That page has been deleted so it has no additional information. So SuperPerms is the built in permissions system? Does it have groups like others or straight up you have the permission or you don't?

 

You can use this:

Code:

if(player.hasPermission("permission.node"){
 
// Insert here code...
 
}

 

kmccmk9 You don't understand the system, I think.
SuperPerms == bukkits permissions API. Now all modern permissions (non-modern doesn't even compile with the current CB builds) plugins use bukkits API. But bukkits API is limited: It provides simple permission checks, but no things like groups. Also you need a plugin that populates bukkits API, which is was all the (modern) permission plugins do.
So for simple permissions just use (what Nuko32 told) player.hasPermission - It will be compatible with all and every permissions plugin out there. If you need more stuff, like creating groups, adding/removing players from groups, ... you need another way. Like desht told Vault is the way to go then - but still just for the extended things, normal perms checks are slower through Vault than calling player.hasPermission cause Vault calls exactly the same internal: https://github.com/MilkBowl/Vault/blob/master/src/net/milkbowl/vault/permission/Permission.java#L98 so you just add in a useless layer.

The only exception here is PermissionsEX, which tells to be SuperPerms compatible but in fact overrides Bukkit methods instead of using them. IIRC you can't use getServer().broadcastMessage("Test"); with PEX, cause the broadcastMessage call uses SuperPerms, too (yes, you can decide who can see the broadcasted messages with a permission node) but PEX creep overweiting-reflecting-whatever codes fail here.

 

Could you show me the WHOLE page stating PEX sucks... (by: mbaxter) PermissionsEx hasn't caused me any problem to be honest. I don't give the * node for any group. I only gave the * node to me (Owner) and my Co Owner.
And you could do this in PEX - -bukkit.commands.give.op etc).

Jnorr44 All those bugs mentioned were fixed in the latest version. Again for restricting permissions just use
- -bukkit.commands.give.op etc).


EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Odie680

 

Really? Since only changes in the last two months according to the github commit log are one NPE fix and a database timeout fix. Where did you get the information that all of the discussed problems are fixed now?

(And it really doesn't help that the dev.bukkit.org page lists 1.19.1 as the latest, the forums.bukkit.org post lists 1.19.3, and the github commit log makes mention of a 1.19.4 release. It's impossible to have any confidence in the development cycle of this plugin).

 

Odie680 Unless they re-wrote the entire plugin, they were not fixed. You cannot override bukkit methods and expect them not to break stuff.

PEX is actually a disgrace to developers to be honest

 

Oh okay I understand now. Thank you. I was confused and remembering the old days when you had to use the api for the permissions plugin itself.

 

perm bukkit is exceptionally perfect for our setup at DwD, reason for no updates is because it is not needed! If you know how to setup complex permission nodes then it is perfect you, not to mention permbukkit os nearly top on mcstats.org. In my opinion, which is ONLY my opinion, PEX sucks. Has to many features that is unnecessary that other plugins should be doing. Permission plugins are meant to give your users or that group a specific permission node. Not a bunch of other bullshit. So let the heat come because I know for a fact that this will cause users in the minecraft community to rage and argue against something that is only my opinion. Like I said though, it has work since day one for DwD and our permission.yml in root folder is way over 2000 lines.

 

No, many server owners will argue, but the developers won't because they know whats going on.

 

won't or will?

 

The server owners will argue that PEX is good,
but the developers won't, because they know its junk.

 

touché