I am new to LP, but been running a server (bukkit, then spigot) for quite a while.

I have been using essentialsX antibuild to prevent people from using certain items (ender chests and shulker chests) and it worked fine till I switched to LP this week.

I am having trouble negating permissions that should override wildcards
Example:

- essentials.build.*:
    value:  true
- essentials.build.place.130:
    value: false

I believe this should give players the ability to use all blocks except 130 (ender chests) Unless I am misunderstanding how LP works. The actual result is that players are still able to use ender chests. i.e. only the wildcard is working

If I do the opposite:

- essentials.build.*:
    value: false
- essentials.build.place.130:
    value: true

the wildcard works correctly and players are not able to build anything ... but the place exception does not work and players are not able to place ender chests. i.e. only the wildcard is working

If there are NO wildcards and I just add the antibuild perms individually:

- essentials.build.place.130
- essentials.build.break.130

That works fine, players are able to break and place ender chests and noother blocks, which is correct. I don't really have a way to test the opposite of this example, since antibuild sets everything to false, by default.

In any case, I don't know if this is an issue with antibuild or LP or an interaction between them. The issue seems to be wildcards, but I am not a coder and can't explain it. I am just reporting what I see.

Versions:
4:14:33 PM LP: Running LuckPerms v3.2.44 by Luck.
4:15:56 PM CONSOLE: [INFO] This server is running CraftBukkit version git-Spigot-7228328-11323bf (MC: 1.12) (Implementing API version 1.12-R0.1-SNAPSHOT)
4:16:25 PM CONSOLE: [INFO] Essentials reloaded 2.0.1-b496.

Antibuild is still on the old system
How does it still function? Why has the dev not updated to match the rest of the community?

EssentialsXAntibuild is almost identical to Essentials Antibuild (as are almost all of the EssentialsX modules), and hasn't been updated for a long time because it still works (or at least worked).

Definitely sounds like an LP issue.

Can you check using "/lp verbose" and take a look at the check results.

https://gist.github.com/anonymous/3d5c87d0fa03e6ca7487261f1f785e00

Wasnt really sure how to use this ... I turned it on and used ender chests in member group.

There's a lot of

BigPoppaCronie - essentials.build.interact.130:0 - TRUE
BigPoppaCronie - essentials.build.interact.130:5 - TRUE
BigPoppaCronie - essentials.build.break.130:5 - TRUE
BigPoppaCronie - essentials.build.place.130:5 - TRUE

spread throughout that.
Change them all to false to stop the ability to place/break/open the ender chest

Not sure which block 130:5 is, though

Try essentials.build.place.ender_chest
or .minecraft:ender_chest
Block and item ID numbers haven't been used since 1.8 or so...

Sorry, that doesn't work. Antibuild is still on the old system. Also, please note that the antibuild perms do work, just not when combined with wildcards.

OK, I did a bit of testing and made some progress. It looks like ender chests are 130:0 before they are placed by a player. After they are placed, they become 130:5 and they take on an NBT tag, presumably regarding the inventory items it contains. Shulker boxes similarly go from 219-234:0 to 219-234:1 after being placed.

The problem, I think, was that I didn't know these items needed a :0 :1 as identifiers. I was just using 130 and apparently that was not enough to trigger the permission. As far as I can tell at this point (i.e. tired and ready for bed) this is not a permission issue .... the main issue is that now there are 160 perms at least in order to add/remove the use of ender/shulker chests.

I am still new to LP, I am used to using group manager and with that I would use a sub-group to deal with adding that many perms. Does LP have a similar system?

In my opinion, the major issue is Essentials. GriefPrevention - in my experience - is far easier to deal with. Ender chests (and shulker boxes) are just an interact-secondary flag.

But I'm entitled to my opinion, and what you use is up to you. 😛

Oh, it is not about grief prevention.

I clear out old player inventories (player.dat files) if players are inactive for over 4 months. Many players don't know that they can also lose the items in ender and shulker chests in this process. So I require players to affirm that they understand this is going to happen before I give them permissions ... it just saves me a lot of pain and explanations later on.

For grief prevention I have other plugins.

LP does have sub groups, although they're just referred to as "groups". There's no separation.

You can make a group inherit a group in the same way you would for a user. The commands are the same.

yeah, found out by talking in discord, thanks for the help guys :)

Sorry for digging up (again) a 2 months old thread but the topic is relevant to the similar issue i'm coping with (Running LuckPerms v3.3.19).

Consider a simple group with the following permissions:

[18:16:23 INFO]: > essentials.build.* (true)
[18:16:23 INFO]: > essentials.build.place.* (false)
[18:16:23 INFO]: > essentials.build.place.2 (true)

First we grant all build permissions to group members. ~ OK
Then we prevent them from placing blocks but still being able to break ~ OK
Finally we allow them to place block ID 2 (grass) ~ KO

Is this related to the double restriction or deep restriction or something? I'm currently having a headache trying to understand this. 😋

I thought it would be usefull to provide a verbose gist (filtered out to only track essentials.build)

Note: i'm only trying to place a grass block with the specified permisions.

Thanks for your time, and keep up the good work 😉

(If you want me to open up an issue for this tell me I'll do so)

You need to set essentials.build.place.2:0 to true as well. (the verbose log shows you this)

(and yes, in future, please don't comment on old/closed tickets, even if you think your issue is related)

My bad indeed, thanks for the quick troubleshooting.