A lot of internal changes in the mechanism powering enabling conditions. Some of them were towards bugfixes, some of them towards better UX.

This state is persisted as a part of item configuration meaning it will stay that way until you'll change it again.


Applied some face-lifting to how HotkeyIsActive looks and works.
In fact, they have existed for ages (multiple years at this point), but they were not given enough publicity despite the fact that they are extremely useful in some cases.
All-in-all, this mechanism is directly responsible for enabling/disabling hotkeys handling at any given moment. By adding one or multiple auras you can specify exact set of conditions, which must be met before Trigger will start doing anything.
For example, by linking Aura which has WindowIsActive in it, you will make Trigger react only to keys which were pressed while game window is active.
In more complex cases, you can link the trigger to some in-game condition, for example, you when you click RMB(part of HotkeyIsActive configuration) AND some powerful skill is off-cooldown(linked condition), instead of casting whatever is usually on RMB, you'll simulate key press of a button which casts that skill. A good example would be automating cast of Vaal Skills on Path of Exile - you have the usual version of a skill bound to some button which you spam and whenever Vaal version got enough souls, it will be automatically release without you having to remember about it.
To better understand why two next options are needed, let me provide an example:
I have HotkeyIsActive tracking presses of F3 in Toggle mode, meaning that when I first press on F3, trigger activates and to deactivate it I have to do a second press. Very simple and very useful to enable/disable some more complex auras (like auto-potions). Also I've set the option Suppress Key which blocks F3 from reaching game window at all - otherwise the game could react to something bound to F3. What is bad in this configuration is that if I leave it as is, F3 would be blocked in all applications, not only in my game - not really convenient, if you ask me.
To fix that, I can add Interception condition with WindowIsActive and this will restrict F3 to that single game window. Kinda works, but there are two problems with this:
Problem:
To disable HotkeyIsActive, I now have to have game window to be in focus. So if I want to disable something that is bound to F3, I have to activate game window first. If that F3 enabled some kind of an aggressive clicker, getting your window back to foreground could be challenging at times.
Solution:
By setting this option, you can now make it so enabling the trigger can be done only while game window is active, but disabling it could be done from anywhere. Forgot to turn off your clicker before alt-tabbing? Not a problem, just hit F3 again and the trigger will be disabled.
Note that this option will have effect only if toggle is currently active.
Problem:
There is no way to quickly disable HotkeyIsActive - you have to click the button. In some cases this is not very convenient - you have to remember that some automation currently runs. You alt-tab and forget about it. Then, out of nowhere, some trigger condition kicks in and you start doing something in the game. That could lead to problems.
Solution:
Just set this new option. Now, if trigger interception condition is no longer met, the trigger will automatically deactivate itself. In our example, if I alt-tab out of game window, the whole functionality that is powered by F3 will be deactivated. Note that you'll have to enable it back on again after you alt-tab back to the game. By having this option enabled you can make the overall system much more resistant to human errors.
Historically, when you were editing settings of Image Capture Triggers (Image/Text/Color/ML), Preview window was refreshing at exactly the same Capture rate that you had configured (or lower, if trigger was not able to reach that FPS). In most cases this is not really a problem, but as soon as for efficiency reasons you start working with very low FPS, such as trigger refreshing 1 time in 10 second, or even 0 FPS triggers which are used in combination with C# scripts and Behavior Trees. Previously, you had to manually click on Refresh button to force a redraw, which is not very convenient. Now, you can global app-wide minimum preview FPS, which will be used instead of Trigger Capture Rate.
Minimum Preview FPS will take effect only while you have Preview enabled! It won't affect FPS afterwards and won't be exported as part of a trigger configuration.

From now on, you can hover cursor over trigger state to get a better understanding of why exactly it has this value. For example, if enabling conditions are not met - trigger state description will tell exactly that. If trigger is misconfigured - it will tell what exactly is missing. Right now the coverage is far from completeness, but eventually we'll get there.



Unload all/Load all now affect Behavior Trees as well