WeakAuras

Triggers and Untriggers

Triggers and Untriggers

Some status triggers (and most custom triggers) in WeakAuras have a Hide option which allows you to choose between "Automatic" and "Custom". When "Automatic" is selected, the trigger will simply "turn off" whenever the specified options are not true. However, when "Automatic" is selected, you will be able to specify a second set of options for the trigger, which will determine when the display should be hidden. This is referred to as an "untrigger". Unfortunately, untriggers do not work how you might expect, so this page will briefly explain how they do work.

The most important thing to know about untriggers is that a display's untrigger will not even be checked unless its trigger has already been checked, and failed. This means that an untrigger cannot be used simply as a second set of constraints on when a display should trigger. For example, you might want to create a Health type trigger which will turn on when your target's health goes below 66%, but will shut off when your target's health goes below 33%, so you set the trigger to "< 66%", enable the untrigger, and set it to "< 33%". This does not work. The correct way to accomplish this is to use two triggers; click the "Add Trigger" button at the top of the trigger tab, give your display a second Health trigger, set one to "< 66%" and the other to "> 33%".

So what is the point of untriggers if they do not provide a second set of constrictions on a trigger? Untriggers are instead meant to allow a trigger to have a "grey area" - a set of values for the trigger in which its display's visibility is only determined by its past visibility. For example, consider a Health trigger set to "< 35%" with an untrigger set to "> 50%". This will make the trigger's display appear when the player dips below 35%, but it will not disappear when the player is healed from 35% to 45%; the player must be healed above 50% for the display to disappear. This makes the values between 35% and 50% a "grey area". If you only know that the player's health is 45%, you cannot determine whether the display should be showing or not. If the player was below 35% just before being brought to 45%, the display will be visible. If the player was above 50% just before being brought to 45%, the display will not be visible.

For custom triggers, the trigger vs. untrigger paradigm is important, because it allows the user to ignore events. For example, consider creating a custom trigger that appears when the player begins casting a spell and disappears when the player finishes casting a spell. The custom trigger would have to register for the COMBAT_LOG_EVENT_UNFILTERED event. However, there are many combat log events other than SPELL_CAST_START and SPELL_CAST_SUCCESS. Having a separate trigger and untrigger allows the custom trigger to only trigger when a SPELL_CAST_START message is detected, and untrigger when a SPELL_CAST_SUCCESS message is detected, with all other message types being ignored.

This system does create some inefficiency for custom triggers with the "Status" type, because such triggers will usually have an untrigger that returns true exactly whenever the trigger would return false, but both must be explicitly defined anyway. However, the separation still allows more flexible behavior because it allows for grey areas.

You must login to post a comment. Don't have an account? Register to get one!

  • 1 comment
  • Avatar of schult461 schult461 Apr 04, 2012 at 02:37 UTC - 0 likes

    For what it's worth, you should add a checkbox to default the untrigger to the inverse of the trigger. Saves quite a bit of headache of cut/pasting the whole thing, and inverting the return value.

  • 1 comment

Table of contents

  1. 1 Triggers and Untriggers

Facts

Date created
Nov 21, 2010
Last updated
Nov 21, 2010

Author