1.4.7036

Enabling Conditions rework

A lot of internal changes were made to the system that manages enabling conditions. Some of them fix bugs, while others improve the overall user experience.

• If a trigger is disabled because its enabling conditions are not met, its header will now show orange text, as shown in the screenshot below.
• If you hover over that text, you will see very detailed information that helps you figure out exactly what is affecting the trigger. Right now this block is still quite technical, but it clearly shows which elements caused the disabled state.
• If an aura is selected and the main window is currently focused, all enabling conditions are ignored.
• Similar logic now applies when a folder is selected: all enabling conditions for its child elements are ignored.
• Fixed a bug that could sometimes happen on application startup and disable auras even when their enabling conditions were actually satisfied.

Triggers, Actions, and Overlays can now be minimized

This state is saved as part of the element configuration, which means it will stay that way until you change it again.

HotkeyIsActive improvements

UI improvements:

• Added tooltips
• Improved the aura-linking mechanism inside the trigger: Interception conditions, explained in more detail below

Interception conditions

This feature has actually existed for years, but never got much public attention, even though it can be extremely useful in some cases.

In general, this mechanism is responsible for enabling or disabling hotkey processing. By adding one or more auras, you can define the exact set of conditions that must be met before HotkeyIsActive starts intercepting and processing events.

For example, if you link an aura that contains WindowIsActive, the trigger will only react to key presses while the game window is active.

In more advanced setups, you can link the trigger to some in-game condition. For example, when you press RMB (= part of HotkeyIsActive) AND some powerful skill is ready to use (= linked condition), instead of doing whatever RMB normally does, you can simulate pressing the key that casts that skill. A good example would be automatic Vaal Skill usage in Path of Exile: you have the normal version of the skill bound to a button you already press, and once the Vaal version has enough souls, it will be used automatically. You do not even need to remember it yourself.

To better explain the next two settings, here is an example based on the screenshot above:

There is a HotkeyIsActive trigger that watches for F3 in Toggle mode. That means the first time I press F3, the trigger is activated, and to deactivate it, I need to press it a second time. This is simple and very useful for enabling or disabling more complex auras, such as auto-flasks. I also enabled Suppress Key, which prevents F3 from reaching the game window at all, so the game does not react to whatever is bound to F3.

The problem with this setup is that if I leave it as-is, F3 will be blocked in every application, not just in my game, which is not very convenient.

To fix that, I can add Interception conditions with WindowIsActive, which limits F3 interception to a single game window.

This works, but it introduces two more issues:

Interception conditions - Ignore if Hotkey is set

Problem:
To disable HotkeyIsActive, the game window must be focused. So if I want to turn off something bound to F3, I first have to switch back to the game window. If F3 enabled some aggressive clicker, bringing your window back to the foreground may not be easy.

Solution:
Enable this option, and now you can require the game window to be active only when enabling the trigger, while still allowing disabling it from anywhere. Forgot to turn off your clicker before alt-tabbing away? No problem, just press F3 again and the trigger will be disabled.

Note that this option only applies while the toggle is currently active.

Interception conditions - Automatically deactivate Trigger

Problem:
There is no quick way to disable HotkeyIsActive without pressing the button again. In some cases this is inconvenient, because you need to remember that some automation is still running. For example, you switch to your browser and forget that some script is active. Then, unexpectedly, one of the trigger conditions becomes true and you start doing something in the game. This can cause problems.

Solution:
Just enable this new option. Now, if the trigger's interception condition is no longer met, the trigger will deactivate automatically. In our example, if I switch away from the game window, all functionality controlled by F3 will be deactivated. Note that you will need to activate it again after switching back to the game. With this option enabled, the whole setup becomes much more resistant to human error.

Image Capture Triggers UX improvements

Historically, when editing Image Capture Trigger settings (Image/Text/Color/ML), the preview window updated using the exact same Capture rate you configured, or lower if the trigger could not reach that FPS. In most cases this is fine, but it becomes inconvenient once you start working with very low FPS values, such as a trigger updating once every 10 seconds, or even 0 FPS triggers used together with C# scripts and Behavior Trees.

Previously, you had to click the Refresh button manually to force a redraw, which was not very convenient. Now you can set a minimum preview FPS for the entire application, and it will be used instead of the trigger's Capture Rate.

Minimum Preview FPS only applies while preview is enabled. It does not affect FPS outside of preview mode and is not exported as part of the trigger configuration.

Trigger UI improvement: status display

From now on, you can hover over a trigger state to better understand why it has that value. For example, if enabling conditions are not met, the trigger state description will say exactly that. If a trigger is misconfigured, it will tell you what is missing. Coverage is still far from complete right now, but we will get there over time.

Bugfixes/Improvements

• [UI] Fixed a crash that could happen on startup and cause EventViewer to appear on top of the splash screen
• [Pack] Packaging improvements: packed versions no longer react to eyeauras:// links, unlike the main version
• [UI] Unload All / Load All now also affect Behavior Trees