Hello, I think the ability to create named groups of contexts might be a useful addition. With that, you could create a context group called "pvp" and list contexts specifying the worlds and servers with pvp enabled. When a new world gets added, you could just add it as another entry to the existing context group, and all of the existing permissions would work perfectly.

Thanks.

I've seen that terminology used with Sponge, but I'm actually using Bukkit. It might also make it easier to migrate the mirrors from GroupManager. It's also a bit like PermissionsEx's multiworld inheritance.

Huh, interesting idea.

I'm guessing you're using Sponge?

World inheritance with LP is possible via a config option: https://github.com/lucko/LuckPerms/blob/master/bukkit/src/main/resources/config.yml#L185

Grouping contexts is probably going to be tricky. The best I could do is to allow you to define pre-made context sets in the config, but these would just be copied when commands are run.

e.g.

contexts:
  pvp:
    server: "something"
    world: "something-else"
  thing:
    server: "idk"

Then, when you run the commands, it would just query this and select the appropriate set of contexts. However, it would be a copy, and wouldn't refer back to this, so changing the config later wouldn't update stuff you'd set already.

I think the uses for this are really limited, especially on Bukkit. There are only two contexts, so you're only really saving yourself the time to type a couple of words.

Also remember that contexts are satisfied via AND, not OR, so having...

contexts:
  pvp:
    world: "something"
    world: "something-else"

... would make no sense, because you can't be in two worlds at the same time.

Idk, does that make sense?

World inheritance is probably good enough in most cases. The only real difference is that a world could match multiple context groups. That would be a neat feature, but I understand if it's more complex than it's worth.

The last part wasn't quite what I was thinking. My idea would be more like:

"contexts": {  
      "pvp": [  
         {"server": "server1", "world": "world1"},
         {"server": "server2", "world": "world2"}
      ]
   }

Sorry for switching to JSON, but the YAML syntax for a list of objects is a little funny.
Basically, the "pvp" context group would be satisfied if the player were in both (server1 AND world1) OR if they were in both (server2 AND world2). I understand that a context is a single key and value, so maybe contexts group makes more sense. Better yet, I see that you have something called a ContextSet. What I should really have called it is a group of context sets. Of course, if you just want to use it as an alias, you could only include a single set of contexts.

I was looking into how to implement this in the hopes of creating a PR, but I can see why you said adding it would be complicated. A lot of the methods on Node, such as get(Full)Contexts(), getWorld(), and getServer(), would no longer make sense. However, I got an idea from how PEX handles its server-tags context. I've created a separate plugin that registers a ContextCalculator that adds context values under the "tag" key. For example, it turns the contextset

{"server": "server1", "world": "world1"}

into

{"server": "server1", "world": "world1", "tag":"pvp"}

It's not complete yet, but that's my problem. However, I'm not sure how to set a permission with a custom context. The set command only seems to take a server and a world. I'm going to go ahead and close the issue, though.

Yep, your example with the ContextCalculator is definitely the best way to achieve what you want. :)

Your other suggestion wouldn't be possible, as yeah, each "Node" only has one attached context set. If you wanted to attach multiple, then you'd just have to add multiple nodes.

And yeah, there currently isn't a way to attach contexts to permissions/parents using commands. It's been a low priority to-do for a long time, and I intend to get it added pretty soon. Some of the methods for it are already written. https://github.com/lucko/LuckPerms/blob/master/common/src/main/java/me/lucko/luckperms/common/commands/utils/ArgumentUtils.java#L139

It's just a case of modifying the command messages to support it, and then I'll be adding it. I also plan to combine that change with a chance to remove the exceptional behaviour from the setPermission methods. (a user/group already having a permission isn't really exceptional behaviour, so I want to fix that.)