Is your feature request related to a problem? Please describe.

It is very easy to find use cases where a user needs to write code in order to get custom Acitvation to work. This can turn some people who are afraid of writing code away, and it just speaks to the fact that our current builtin options are not very powerful.

We have also had a few tickets relating to this. I wrote one a few weeks ago, requesting that trigger activation be given an “always” option, and there have also been requests that the custom code option be given access to the trigger states. In the absence of that, people have also begun to access the trigger states via internal structures as well.

Describe the solution you'd like

A new property on every aura, which is named something like “Aura Visibility”. This would allow users to use the full expressive power of conditions to also set the active state of an aura.

Describe alternatives you've considered

Nothing else comes to mind as an alternative which allows the same level of generality.

Additional context

This will not be very easy to implement, since we will have to decide how to handle custom activation code. Additionally, conditions only check when the aura is active, which is not compatible with aura activation being a property.

We could perhaps implement an upgrade system which inserts a condition for aura visibility, and requires that the user initiate it manually. For auras which are newly created, do not show the trigger activation logic option (but maybe some kind of help text to point them to conditions?)

There are a few checks in each trigger that could be more easily expressed via such a system.

E.g. the Bufftriggers choice of always/on buffed/on missing or the remaining time check of cooldowns. It would be much more natural to have a trigger for just the spell, and to control the visibility via such a system. That would also make those checks a lot more capable, by e.g. allowing for expressing >= 5 && <=7 checks.

But!
That's hard to do in a backwards compatible way, e.g. in the standard setup of buff +cd trigger, the trigger activation also controls which trigger's dynamic info is shown.

And it gets even more complicated for e.g. buff triggers with a stack > x check. The %matchCount variable for such a trigger will obviously only count the buffs with stack > x.

But if the stacks check is done as part of a visibility check, how could %matchCount work in the same way?