LuckPerms | An advanced permissions plugin

Yea… I completely understand about each plugin requiring their own set of permissions…
It’s always been like that. It’s when folks start mentioning that a plugin like yours for example… whether it’s a “defaults” issue… Wel… to me that means before any plugins get introduced… the baseline… What should that be? This to me is what I would need in order to troubleshoot if a new plugin has introduced a glitch in my permissions setup that doesn’t allow my kids to shovel some sand lol :wink:
Is there a reference anywhere of what the “defaults” (if any)… should be? When I query what nodes the group defaults for example… what should I see?

As far as I know there is none.

LuckPerms does not limit any vanilla behaviour, or anything at all, in fact. There’s nothing like ModifyWorld included within it. If you have a blank server with just LuckPerms installed, regular Vanilla / default Sponge behaviour will be maintained.

THANK YOU!!!
I don’t think I’ve ever read ANYWHERE that when you refer to “defaults” for just basic play… especially when you read that “defaults” were not generated properly… You presume there’s at least a basic node that can be used… At least in my head. A few of those plug ins in the past expressed how folks without the default perms wouldn’t be able to interact with anything… it would alleviate the issue with trolls getting into your server; trying to screw up you map.
It’s nice to confirm. thank you for your valuable time luck :wink:

1 Like

Hey, on the latest builds this still doesn’t seem to be handling the default permissions for Grief Prevention correctly? While testing as the default rank I cannot break blocks in the wilderness, which is a default permission added in GP. I’m using a MySQL backend for LuckPerms, which I know caused issues with defaults for PEX, is it causing the same issues here?

I have the same issue but also know a work around that’s a major pain. To me it seems that GP is unable to automatically load the perms as PEX does into the default group. So none of the claimflag settings you change seems to affect them at all, overrides including. I’ve had to manually enter this permission into the default group with the proper claim uuid. Either wilderness, or one of my admin claims. for each and every flag, per claim.

“(gp_claim=46b92993-2080-420d-914f-4db5dd148563)griefprevention.claim.flag.interact-block-secondary”: true,

Thanks, that seems to have worked for the wilderness issues. Even if it is a pain to do I’d rather get it done while we wait for the issue to be fixed :stuck_out_tongue:

I’ll look into it now… @Darktilldawn you should’ve mentioned it to me! I wasn’t aware that there were any issues with it. :slight_smile:

I swear I did mention it xD 8 days ago scroll up lol
On that other issue, about the groups sticking to a player after removing said group, that is fixed

1 Like

Ok, I’ve had a quick look.

GP is registering its default permissions with LuckPerms. Here’s the list I got:

However, GP is assuming that wildcard permissions will be resolved by the implementation.
http://hastebin.com/sekosezina.css

So yeah, not really my fault. It’s not made clear anywhere whose responsibility it is to do that processing. In fact, for Defaults, LuckPerms just uses the default Sponge implementation.
https://github.com/lucko/LuckPerms/blob/master/sponge/src/main/java/me/lucko/luckperms/api/sponge/simple/SimpleSubject.java#L51

So my guess is that PEX added the feature, and blood just assumed that other providers would do the same thing, even though it’s not documented anywhere. Not the first time I’ve had issues with vague documentation in the Sponge API. :cry:

Anyway, it’s no big deal. I’ll try to clarify what should be happening there and if need be make modifications to allow for wildcards.

Ok, I’ve made those changes. @Darktilldawn @Proxying please try with this build:
https://ci.lucko.me/job/LuckPerms/213/ :slight_smile:

I see a default.conf file there on your paste. Where is that supposed to be at? I’ve had to create a default group under .json and use inherit laws to make it happen for all groups and players? I’ve updated and testing now

default.conf was just the name I gave the file when I gist’d it. You don’t have to save it anywhere, and it doesn’t get saved anywhere. :stuck_out_tongue:

Alright xD was like wait a sec… is there an easier way to do this xD maybe that should be a thing…? An automatic default.conf that you can set up with perms and it automatically is set to all players, and that’s where the GP flags and permissions could be controlled within?

Yeah, that file exists, it’s the “default.json” file within the groups directory, or the default group record in MySQL, or whatever. Anything you define in the default group will override default permissions set by plugins internally, and players are a member of this group by default.

There’s no need for default permissions set by other plugins to be persisted. :slight_smile:

Oh I didn’t remember if that was automatically made or not lol. First thing I did was create all the groups and then hit the permissions.
Well the flags seem to be changing in game but I’m not seeing the default.json generating anything for it permission wise. Although I will say that it is working

The default group is completely different from Sponge default permissions.

The default group is configured by you, and the Sponge default permissions are configured internally by other plugins. (and never get saved to a file)

So the only way for me to see what’s going on flag wise per claim is in game? Not against this just wondering

I’m not sure what you mean by that. I linked you the set of default permissions, I’d assume that they will always remain the same.

Edit: Yeah, they’re just constants.
https://github.com/MinecraftPortCentral/GriefPrevention/blob/master/src/me/ryanhamshire/griefprevention/GPFlags.java

Alright, I’ll switch up to this build. I’m using a SQL backend, instead of flatfile. Will it require a regeneration of the whole database? Or will it apply to a premade one?

It won’t change the database at all. Defaults are not persisted.