example...

user "bill" is assigned to group "donor"
"donor.yml" permissions includes "- group.donor_global"

group.donor_global.yml contains something like...

• essentials.back
• essentials.back.ondeath
• essentials.workbench

User bill can /workbench (/craft) but cannot (/back), there seems to be no reason for this. This happens sporadically, I've had a few other random items be ignored from time to time, then they come back working again as if nothing was ever wrong. I can't see what the problem is. If I set the permission directly to the user, that works, but if that's the only way to get things to work... groups are unreliable and virtually worthless under those conditions. Any ideas?

Set group weights.

Without them, inheritance order is random. (well, it's nondeterministic)

https://github.com/lucko/LuckPerms/wiki/Command-Usage#lp-group-group-setweight

Well i wish it was providing an error. Also, I can't verify that weights actually work.

User is assigned to primary group 'builder'... has griefprevention.trapped: value false ... weight: 10
Added parent builder_test to user with griefprevention.trapped: value true both at weight: 1 and at weight: 11. Result is still false. I've seen weights actually have the appearance of working previously, but am no longer convinced it is taking the order properly. My thought was that higher value... higher weight... is the same as higher PRIORITY. Since neither appears true, however... let me know if I have that backwards. It won't help in this particular case since... for all I know "weight" is just a line being randomly ignored. Rules later in the file are being followed, I smell a pretty major bug here.

Groups with higher weights are inherited from first, however inheritance is still done in stages.

Effectively:

1. Take all of a the subjects permissions, and accumulate them if not already present.
2. Take the groups the subject inherits from directly, sort them into priority using weight, then for each group, run steps 1+2

I find it really hard to believe this is an LP issue. (will be gladly proven wrong though)
If such a crucial issue was occurring, I'd be getting similar reports from all users.

I urge you to take a look over your current setup with the permission info and parent info commands, and double check everything is exactly how you intend it to be. :)

I did set group weights... I'm saying the rules are being randomly ignored. I do not have any group where the mentioned permission is set to false and the inheritance is happening in the wrong order... there is no permission for the nodes until this group is applied, several nodes are just being ignored.

There's no technical explanation for that.

There's no middle ground where "some" of the data is loaded.

It either explicitly fails to load the data (in which case you'd get an error message) or it all gets loaded.

yeah things are correct when checking permission info and parent info, that's the worst part. I'm seeing the permissions I set exactly how I set them, but the result is not carried to users of that group? Also, why is it that the user permission check seems to be completely limited to checking for permissions set directly to users? This doesn't seem to reveal any information about nodes granted by groups.

I am running your latest build, but I've had perms disappear here and there for the last few. I can't come up with any reasonable explanation as to why some lines seem to be completely ignored. I am using .yml for storage so far... I haven't been willing to trust set up without some ability to line edit... but all I'm seeing now is that certain lines are just not even being considered.

Ok retrying this experiment, I still don't know what priority the weights are handled in. It would make sense to me that a higher weight takes priority, and that was the approach I took, but neither setup appears to work.

user_one -- primary group: builder
-- add parent builder_test

permissions:
builder:

• griefprevention.trapped:
  value: false
• weight: 1

builder_test:

• griefprevention.trapped:
  value: false
• weight: 10

/lp user user_one permission checkinherits griefprevention.trapped

result is:
false in context global (inherited from builder). This is true even if I swap weights? Making Builder weight 10 and builder_test weigh 1? At the very least,, these two should reverse. One necessarily needs to outweigh the other. It's like once it's false, it's always false, no matter what. Nothing can ever make it true again... regardless of what level/weight of group the user is put into above where they started? Is that... basically the problem here? I was having issue with at least one I'm sure was never set to false but that one magically started working again since we began discussing it, so who knows... I won't be able to test it again until it starts failing again.

I did resolve one of my permission issues... had to do with libsdisguises... an update on THEIR end was needed before the permission node they had documented was operational, this at least explains to me why this permission wasn't having the desired effect even though it had never been set to false. I came across a variation of the issue with something else, but don't really have much I can compare it to... in docs they or luckperms is calling it "regex" but I don't consider it that if *'s and .'s are used in this way... their documentation suggests using this:

• libsdisguises.disguise.*.setbaby
  In order to allow the user to use the "setbaby" function on every disguise they have access to, this does not work. The only way to get it to work is to verbosely place each disguise verbosely with that .setbaby node. I'm not sure if that's a LuckPerms issue or something else with their documented perms not quite working as advertised... but I did run into something similar before where I had to put the rule straight out instead of using wildcards.

I can't quite get the "once false always false" issue resolved entirely. In some cases I can just remove the rule that set it to false? But not if it's something enabled by default which I want disabled for lower groups.

Also I didn't notice until today the 'checkinherits' function which is crazy useful for tracking down the issue with stuff like this, this has helped somewhat in making some of these items seem a bit less random, so well done and thank you.

Ah yeah - that may explain some of the issues.

The checkinherits and check commands are uhh, "weak". Meaning, their behaviour may be a little strange. They're of course meant to be accurate, but they don't function in the same way as real permission checks.

If you want to run real permission checks, use /lp check <user> <permission>.
I imagine this command will return the intended result.

The verbose system may also prove useful for debugging exactly what checks are being made by plugins. :)

https://github.com/lucko/LuckPerms/wiki/Verbose

It will also tell you the result of each checks, and where they originated from.

It would make sense to me that a higher weight takes priority,

Yes, that is correct.

As for the LibsDisguises regex stuff, it sounds like that documentation has been written specifically for the v1 versions of PermissionsEx. To my knowledge, no other permissions plugin implements that same behaviour. (even PEX itself doesn't in the newer v2 versions)

The LuckPerms regex system is defined here, but it's slightly different to the PEX v1 system.
https://github.com/lucko/LuckPerms/wiki/Advanced-Setup#regex

Ok that's interesting, i I didn't notice that one, all i saw was the permission check one which... seems to ignore anything not actually set directly to the user. Down side I noticed right away from this one tho... it doesn't work unless the user is actually online? Not sure why that would be necessary.

Any information on how to set something to 'false' initially and 'true' on a higher level group? I thought I could do that by setting value: false on the lower level group (with a lower weight) then value: true on a higher level group (with a higher weight), but that doesn't seem to be doing the trick.

Yeah I was afraid of something like that with the regex... i reread your section on it and... even if that works i'd have done it wrong, so I may try a few things just to see. I think the documentation needs to have escaped both dots in that example too (luckperms.create.*)? Anyway it might work if I use the R= as I'm supposed to in that situation but I haven't tried... but by now I've already put all the individual lines in so... time no longer saved.

Appreciate you taking the time.