LuckPerms

LuckPerms

41.4k Downloads

Do not apply in "world"

k0nker opened this issue ยท 10 comments

commented

I'm having a hard time figuring out how to do something and I am not sure it's entirely possible without a ton of context usage which negates the promote option which would make tracks useless for me. I operate a server with 15 worlds, so adding world=world1, world=world2, etc is extremely taxing when I want to exclude just one set of worlds from the rank a player gets.

I want to put a user in a group when they're in a certain world and have it revoke their perms from the other group entirely.

Essentially I have two tracks that players follow: rank and skyrank. When a player is in ANY world other than skyworld, I want the normal group that's in the rank track to apply to them. This rank group often has MANY perms that the groups in the skyrank track do not have. I have the skytier1 set with context world=skyworld, and ranktier1 as a global parent.

Example of what I have tried regarding perms:

group.ranktier1
name: ranktier1
permissions:
- group.ranktier1perms
group.skytier1
name: skytier1
permissions:
- group.ranktier1perms:
    value: false

However when the context is met (the player is in world=skyworld) it does not remove the group.ranktier1perms from the player. From what I read of the advanced config file the world perm should override general/global perms. If I specifically add something like essentials.fly and put it to false that removes it, though it doesn't seem to treat groups of perms the same.

Am I missing something or is this intended not to work?

If this is not how it works, could there be a setting in the config.yml that we can set to true so world context perms override global parents entirely? Or maybe groups set to false actually recursively go through and mark all those perms as false that are inherited by that group? Like if I have group.essentials.level1 listed in group.tier1rankperms that would then go in an mark all of the group.essentials.level1 perms false, and go through any groups that lists and so on.

And perhaps another suggestion on top of the recursive group disabling. Add a setting to a group that makes that group only active in a certain world, that way promote and demote still work for world specific perms. Using the context "world=" removes the ability to use promote and demote along tracks.

Something like

/lp group skyranktier1 meta world skyworld

would make it so that even if you have that group it would only apply while in skyworld. Using contexts removes the ability to use promotion tracks.

commented

With 15 worlds that is 14 extra tags for each permission that is active on all worlds except for skyworld. And if at any time a world is added, removed, or renamed, all perms would then have to be updated accordingly.

While that would allow for promote/demote to work, it doesn't address the issue where group.nameofgroup set to false on a world perm is not working as other perms listed to false in that context are. If that worked the same, then it would only need to be the skyranktier# that are changed if ranktier names changed.

It may be a much easier solution to add a new context.

world!=skyworld
or
world=!skyworld

which would mean as long as the world is not skyworld or whatever world you've chosen.
Pic for clarity.

2018-05-10 16_41_14-luckperms - web editor

That would mean you get that group in every world except for skyworld. That could work and be a cleaner solution.

commented

Why not assign both groups to the players, then have the permissions themselves be world-specific?

permissions:
 - group.ranktier1perms:
     value: true
     world: [your world]

If you set the world context to the permissions instead of the groups, then you could set global permissions with deny on certain worlds... That way the groups themselves are global and you can use promote/demote.

commented

I managed to accomplish the exclusion of a world by changing the config file aliases. I set all worlds to have the alias "normalranks" except for skyworld. Accomplishes what I've set out to do, though I still believe adding a !worldname option would be a cleaner and more dynamic solution, in that the config wouldn't have to be updated for new worlds added that follow the track.

I did find a bug. Prefix does not work for world aliases. It works if the actual world name is used as a context but not if the alias is used. Same bug for weight. Can't use an alias as the context.

commented

Thanks for the clarification on world!= context. I thought perhaps the context was a boolean that was checked and returned whether to apply the permission or not.

As for aliases, I meant the world rewrite "aliases".

Snippet of my worlds listed from config.yml:

# Allows you to set "aliases" for the worlds sent forward for context calculation.
#
# - These aliases are provided in addition to the real world name. Applied recursively.
# - Remove the comment characters for the default aliases to apply.
world-rewrite:
  new_nether: normal
  new_the_end: normal
  new: normal
  survival_the_end: normal
  survival_nether: normal
  survival: normal
  creative: normal
  games: normal
  world: sky
  world_nether: sky
  world_the_end: sky

When using those as context it works fine for permissions within groups.
Like:
2018-05-13 14_09_32-window

However when the same context is applied to a prefix via the same command style
2018-05-13 14_08_02-minecraft 1 12 2

it does not seem to work. It saves it correctly, but the prefix never loads if set this way.
2018-05-13 14_11_07-window

If I set the prefix with global, or a world name that isn't a world-rewrite alias, it works.

commented

It's not really possible to add negated contexts.

The whole concept of contexts is deeply embedded within LuckPerms, and other systems within the plugin (and other plugins depending on LP) rely on the behaviour of it.

See:

https://github.com/lucko/LuckPerms/tree/master/api/src/main/java/me/lucko/luckperms/api/context
https://github.com/SpongePowered/SpongeAPI/tree/bleeding/src/main/java/org/spongepowered/api/service/context

I'm not sure what you mean re: the bug with aliases.

Prefixes should work fine (although that depends on how they're resolved) - the resolution of aliases happens before prefixes are queried, so nothing special has to happen there.

Weights can't be set in specific contexts, so I'm unsure what you mean by that.

(also sorry for the late reply, I've had a busy week ๐Ÿ˜ข )

commented

How is the prefix being read / displayed?

Does the correct value show when you run /lp user <user> info?

commented

Indeed.

2018-05-14 16_46_14-window

commented

Thank you so much! ๐Ÿ˜„

commented

Then the most likely cause is that the plugin displaying the prefix is requesting it via Vault, and specifying the world argument in the request. This will bypass any LP systems for world rewrites.

The above commit should fix this. :)

Download is here https://luckperms.github.io/

commented

I'd like to ability to specify to not apply to a certain world. I'm trying to restrict the creation of automata (from Magic by NathanWolf) to 1 specific world. Since I load and remove worlds on the fly, this would mean constantly updating permissions. What I'm looking to accomplish is deny use of the spell unless the world is the one specific one I've chosen.