|Yeah. I tried to think of one that would be better and they only got worse. lol A many to many case could be useful in some cases, I suppose, so yeah, that could be interesting. Perhaps subgrouping. I.e., you could have a set that belong to "combat", with a sub-category of, "spell caster", with a sub-sub-category of "mage", "druid", and so one, or "fighter", with subs for "monk", "weapon master", and so on, where "some" of the triggers might exist in most than one subgroup, but you still want to disable the entire subgroup, depending, in this example, on which type of character you are playing.|
Its and interesting thought, though, you *still* have the same problem unless you "name" every single trigger you plan to have in sets, so you *know* which ones are in which group. However, that is the advantage of existing groups. The triggers themselves don't need to be named, just assigned to the right set. You lose that if the system used has to be done via Lua.
Now, one solution would be to adjust the code for handling names, so you could do something like:
You could disable "combat:caster", "combat", or "combat:caster:mage", the later would disable anything that had the "mage" designation (and any shared with druid by the ",", but not those *specific* to "druid". Getting a druid character up would be a simple matter of doing:
enablegroup "combat:caster", vbfalse
enablegroup "combat:caster:druid", vbtrue
Or, you could have a "enableuniquegroup" function, which "only" disabled the ones that had "mage", but *not* "druid" in them.
Or, you could code something in Lua to do that, but you would have to set it up to auto-name triggers, so they are grouped properly. And you lose the ability to use the feature in anything other than Lua that way, **or** changing the display code to take advantage of the sub-category list in the trigger list, if you wanted to make things a lot nicer.