Bugfixes/Improvements

• [BehaviorTree] Fixed a very nasty bug which lead to parts of the tree not being shown after certain sequences of actions
• [UI] Aura Tree sorting is now properly updated after rename
• [UI] A lot of changes in mechanism that is responsible for UI updates - may be buggy a bit at first, but will end up much more effective in the long term
• [UI] Fixed a bug with Enter handling in numerical fields
• [UI] Implemented prototype of mechanism which will allow to login via license key instead of username/password - should make things easier for new users

Bugfixes/Improvements

• [UI] Aura Tree is now sorted by Type => Name, previously it included last modification time
• [UI] Error reporting now allows to include your all auras into report, unchecked by default
• [UI] Improved error reporting when user attempts to Import share that does not exist

Bugfixes/Improvements

• [VCS] Manual save now automatically commits config data to .git repository
• [Scripting] Fixed a bug which lead to unexpected disposal of services rented by GetService method
• [UI] Bugfixes related to absence of scrollbar in some cases, especially noticeable on smaller screens

New feature - server-side packing

From now on, any shared pack of auras could be downloaded as a separate portable application which can be running in parallel with the main EyeAuras. This should drastically reduce complexity of onboarding of new users - to them, your pack of auras will look just like a usual program, which they can download, unzip and run. This is especially powerful in combination with Custom UI - you can basically create entirely new program and then distribute it as a portable app, which will have multiple layers of anti-cheat protection, almost dozen different input simulators, high-performance image capture and ML-capabilities.

This is still in early stages and will be the recommended way of distributing your work to other users, even those who are already using a program themselves - portable format guarantees that the program will keep working even if the main version of EyeAuras was updated in some breaking way.

P.S. Client-side packing will be enabled a bit later

Bugfixes/Improvements

• [UI] Changed folder editor UI - now there are two tabs, one for Synchronization, one for everything else
• [Capture] Increased default MaxFramesPerSecond from 30 to 144
• [Scripting] Added Execute and ExecuteAsync to IAuraAccessor
• [Scripting] Sleep with under-10ms values now is much-much-much more accurate than before
• [Packs] A lot of improvements in packing and
• [UI] Decreased min window size to 1200x620

Behavior Tree UI changes

• Made the panel with nodes collapsible + changed how nodes look (they take much less space now)
• Fixed problems with some nodes icons not being shown properly
• Improved UX when operating with many(>3) BTs simultaneously

Added "About" aka Credits

EyeAuras includes almost two hundreds of libraries covering different parts of its functionality and I want to give credits to authors.

Bugfixes/Improvements

• [Crash] Safer overlay toggling #EA-451 by n1katio
• [TimerTrigger] Fixed trigger not activating properly
• [Pack] Added two new options in packing - now you can bundle your personal config
• [Crash] Fixed crash in PropertyEditor #EA-454 y madscream
• [Crash] Changed initialization routine #EA-453 by dutiful6005

Scripting improvements

Made it possible to write custom mouse input smoother - more on this

Input smoothers are used to make mouse movement appear.... well... smooth. There are many-many different algorithms out there and EyeAuras currently incorporates only two of them. In this version I've made it possible to implement custom smoother via scripts and then use it wherever you want to - in behavior trees, in auras, in other scripts. The next thing I am planning to allow to do is implement an entire input simulator in the code - that way you can implement input method which will be able to send inputs to background window, for example. I want to add one myself but new things keep popping up and by adding this I will unblock those who can code it themselves.

Bugfixes/Improvements

• [Capture] Restored bit of lost functionality that allowed to capture entire screen, for now I made it available only in CopyFromScreen method, will extend to more performant methods a bit later
• [Pack] Fixed bug in Packing algorithm related to creating new directory

Scripting improvements

Added cross-aura references

Long-awaited change that allows you to link mutiple auras, that contain some C# code together and re-use methods, classes and everything else as if it would be a single script. This allows you to write some utility functions once and then use them whenever you need. From now on, amount of copy-paste required for large programs hopefully will be close to 0. The change affects both Auras and Behavior Trees - by referencing Aura from Behavior Tree you will make shared code available across all nodes of that tree.

To link auras together just add Reference like on the picture below

How is it useful to me ?

For example, in your "library" Aura you can store a bunch of classes which will be used for storing user configuration or will simulate user input in some specific way. Or maybe you want to draw something on the screen using OnScreenDisplay.

Bugfixes/Improvements

• [Crash] Fixed crash which rarely occurred in TimerTrigger during startup
• [Crash] Muted crash which happened if overlay is already disposed #EA-441 v7008 by n1katio
• [BehaviorTrees] UI refactoring - more space, moved blackboard to separate tab
• [BehaviorTrees] Made it possible to zoom in/zoom out the whole control - that way you can make side panels occupy less space if needed
• [BehaviorTrees] Improved Copy/Paste experience - the program will now try to position pasted nodes right where your mouse is
• [BehaviorTrees] Wait and Cooldown nodes now allow to configure randomized time spans
• [UI] Enabled config Version Control System by default for new users
• [Scripting] IBehaviorTreeAccessor now offers Tick method which allows to manually control ticks of the tree
• [Scripting] IBehaviorTreeAccessor now allows to remotely access Blackboard
• [Scripting] Improved user-level exceptions visualization
• [Scripting] ScriptVariable now does not erase previously stored values in case of type mismatch

Scripting improvements and bug fixes

The first — and most important — change

Previously, when a script did something really wrong — something that would cause a normal “classic” application to crash — EyeAuras followed the same pattern. In other words, if there was an error in your script, the program would immediately crash, show an error report window, and offer to send that report to me. That made some sense at first, but over time I started receiving a LOT of error reports that I simply cannot fix, because the issue has to be fixed in the script itself.

In practice, there are 3 possible approaches:

• a) leave everything as it is and keep telling people they need to use proper exception-handling practices, just like in normal applications
  This does not work very well, especially with the growing number of new users. The more popular the program becomes, the more new users will try scripting, and the more of them will run into exceptions. It does not scale well.

• b) run scripts in an isolated environment — essentially create small separate executables that communicate with the “main” program through some fast transport
  This is the best option, but technically it is extremely difficult, especially because that “small” program would need to communicate with the main one with very low latency, otherwise it simply would not be usable in real scenarios. At some point this will become a goal, but I estimate the development cost at at least 3–4 months, which makes it one of the most expensive potential new features.

• c) since EyeAuras fully controls the source code and the execution pipeline, try to make the entire scripting process as robust and fault-tolerant as possible
  This is the option we are trying now. I built a test solution that tries to catch all errors coming from user scripts, and instead of crashing the application, it attempts to handle them, restore state where possible, and continue running. I will also start adding automatic code improvements that are applied to user code during compilation — for example, inserting proper exception handling where it is missing (such as button click handlers), or handling exceptions thrown by tasks.
  We’ll see how it goes.

A few more fixes and improvements are also included in this release:

• [Bugfix] Previously, the internal system that disposes services created by GetService<T> could accidentally dispose (in other words, “kill”) some important EyeAuras services...
• [Improvement] Compilation time should now be shorter, especially for the first compilation after startup
• [Improvement] The mechanism that runs scripts now has much lower internal latency, which means your scripts can run much more often — this optimization was made primarily for Behavior Trees, since a single cycle there may execute dozens of small script nodes

MouseMove verification is now disabled

For several years, EyeAuras used a mechanism that checked the result of every mouse movement — it verified that the cursor had actually moved to the intended position.

Historically, the main reason for this was hardware input emulators such as Usb2Kbd and custom Arduino-based devices. In those cases it made sense, because they do not always perform the movement instantly. That means if you send two inputs in a row (MouseMove + Click), there is a chance the mouse will not yet be in the correct position when the click happens.

Now that input tools are much more powerful — SendSequence, BehaviorTrees, Scripts — this mechanism seems to cause more problems than it solves.

In test mode, this mechanism is now disabled for all input methods. In theory, this should not be very noticeable in most cases, but keep in mind that you may need to add some extra delays between mouse movement operations.

Aura Tree copy/paste improvements

Full Ctrl+C/Ctrl+V support has been added. Previously, Ctrl+C behaved more like an export mechanism, which meant you could not simply copy an item and paste it into another folder because that would lead to conflicts.

Now you can copy and paste items anywhere, just like in Windows Explorer. The naming scheme for cloned items also now follows the Windows style. For example, if you copy Aura, the first clone will be named Aura - Copy, the second Aura - Copy(2), and so on.

Please note that copying and pasting items between multiple EyeAuras instances still does not work. For that, you still need to use Export and Import.

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

HotkeyIsActive Trigger Improvements

Added a new option that resets the trigger state (deactivates the trigger) whenever linked auras are deactivated.

The most practical application of this feature is for a linked aura that includes a WindowIsActive trigger. By default, the behavior is as follows:

• If the selected window is active, the trigger behaves normally and can be activated by a simple key press.
• If the selected window is not active, the trigger won't capture key presses. To deactivate the trigger, you must first bring the selected window to the foreground.

With the new option ("Reset trigger state when linked auras are not active") enabled, the behavior changes to:

• If the selected window is active, the trigger behaves normally and can be activated by a simple key press.
• If the selected window is not active, the trigger will automatically deactivate as soon as it detects this state.

This makes it extremely easy to set up a key that activates certain functionality only when a game is active and automatically deactivates it when you alt-tab or minimize the game.

Bug Fixes and Improvements

• [Overlays] Fixed a longstanding issue where overlays were sometimes sent to the background. This fix affects all overlays in the program, including OSD.
• [Crash] Fixed a crash that occurred when the configuration was copy-pasted to another computer. Additional steps will be taken towards improving program portability in the near future.
• [Scripting] Exposed properties that control OnScreenDisplay in Search Triggers, allowing you to toggle them via code.