Macro editor - node removal

Improved item removal UX and aligned it with other parts of the program

Links

Changed how Enabling Conditions and References in BTs and Macros look like:

P.S. Note the icon to the left of the path - by clicking on it, you will be taken to that specific item.

Double-clicks in Macros

• C# Script node - when double clicked, code editor will be Maximized
• Nodes with Links in them - when double clicked, you will be taken to the first link in the list

Bugfixes/Improvements

• [UI] Fixed a crash which happened if invalid aura name was set
• [Scripting] Fixed(?) a problem with LoginWidget not working properly
• [UI] Fixed a problem with script messages being duplicated in Event Log

Screen capture - BREAKING CHANGE

For years, Target Window was a prerequisite in all Capture triggers (Image/Color/Text/ML) - EyeAuras worked only with windows. Starting from this version, we'll try a different approach:

• If Target Window is not set, EA will start capturing Primary Screen

What this means in practice?

• previously, clearing Target Window basically stopped Triggers from working. From now on, this will only switch the mode to Primary Screen capture and I would suggest to use Enabling Conditions to control the capture. This is very important! Check your old triggers to ensure that there are no "test" or "leftover" triggers as they will start eating up CPU.
• minus extra step if you're setting up something for a personal use - setting up Target Window in many cases is not really required if you're playing games in Borderless Windowed or other similar modes where the game occupies the entire screen
• as soon as we remove window-related stuff from the picture, working with mouse coordinates becomes more simple - every coordinate becomes absolute
• everything related to clicking on objects on the screen will continue to work as is. If you'll notice some problems - please report

IMPORTANT! Multi-monitor setups are not supported yet. Only the primary screen will be captured. I'll extend support in the future

Bugfixes/Improvements

• [Capture] Fixed a problem with FPS selector - it was not working properly and was showing Range selector even if "Min" option was not set

Authentication improvements

First steps toward offline mode - added new option in Settings which allows the client to function without connectivity to the server, even if the client gets restarted. For now, this is just a few hours, but as soon as I will be sure that the system properly works, this will be extended to days. This option will be removed in the future and will become default behavior of the client.

Bugfixes/Improvements

• [UI] Fixed a problem with Start Minimized not working properly under some conditions

Packing - added Start Minimized and Minimize To Tray

Added two new options in Packaging. Both of them are indended to be used by setups with custom scripts having their own UI. By leveraging Lifecycle Events trigger and C# script creating a custom Blazor Window, you can make it so YOUR user interface will be shown instead of EyeAuras.

Start Minimized

If set, when the app gets fully loaded, main window will be minimized.

Minimize To Tray

If set, the window won't even be displayed on the Taskbar, leaving only your custom window there.

C# Scripting - LoginWidget

Added two new examples which use BlazorWindows - Basic Window and Custom Login. Login Widget allows to very easily integrate EyeAuras authentication into your app. It will get more customizable and extensible when I'll receive first feedback.

Bugfixes/Improvements

• [BlazorWindows] Fixed a problem with Transparent background - if set, the window would become unclickable

New Trigger - Lifecycle Events

This trigger is designed to cover scripting scenarios such as running the script right when the app is opened. For now, there are only two events. We'll see whether some other events such as AppFocused could be useful.

In combination with other packing- and scripting-related features, I am targeting to streamline mini-app creation and make it possible to not bootup main EyeAuras UI at all. This is one of the steps.

Detailed information is available here

Bugfixes/Improvements

• [UI] Minor startup time optimization

C#-скриптинг — упаковка NuGet

Использование NuGet-пакетов в скриптах открывает множество новых возможностей — их важность трудно переоценить.
Но загрузка и распаковка пакетов занимают время. Оно небольшое, но для конечного пользователя вполне заметное.
Теперь при скачивании любого Pack сервер EyeAuras будет анализировать ваш код и заранее загружать все необходимые пакеты.

Что это дает:

• более быстрый запуск — потому что все NuGet-пакеты по умолчанию уже включены в pack
• более высокую стабильность — даже если что-то случится с конкретной версией NuGet-пакета, которую вы использовали, или возникнут проблемы с интернетом, скачанный pack все равно будет работать нормально

Это изменение НЕ имеет обратной силы — оно затронет только new ревизии pack.

Исправления и улучшения

• [UI] Исправлена ошибка, из-за которой ссылки Import, взятые со страницы AuraLibrary, в некоторых случаях не работали

C# Scripting - Script Protection - Closed Alpha

In the changelog for the previous version I've mentioned that script compilation will be followed by script protection mechanism. It is extremely rough on edges still, so for a few weeks will be available only to very small group of people. Eventually this will become available for anyone.

How to use it

Script Protection is part of Packaging options and is available only when you've set Compilation Mode to Binaries Only - it does not make much sense to apply it to binaries if you're distributing source code. All you have to do is select desired mode, save options and upload your auras, just like you did before. Ideally, nothing should change for the end-user.

Please note, that infrastructure for this service is still extremely unstable and there could be problems spread everywhere - even if you have access to that feature, it may be worth giving it some time to cool down.

Bugfixes/Improvements

• [UI] Using dots (".") in aura names historically led to a whole group of issues as EA saves auras to your local file system using those names. And usually dot denotes file name from its extension. For now, I've made it so EA will show error when you're trying to rename to a name which contains a dot - just like it currently does for a non-valid names containing special characters.

C# Scripting - Pre-compilation for Packs

Major feature which opens up a lot of new possibilities. In short - from now on, when you're exporting new version of the pack(be it auction sniper or L2 helper or any other pack in the Library), you can make it so EA will pre-compile all the scripts which are part of that pack and include binaries into exported data. Not only this saves up compilation costs for end-users, but it also makes it possible to exclude script code from exporeted project altogether!

IMPORTANT! To apply new compilation mode, first select desired mode, save settings and then Upload new revision of the pack. For now, compilation is done on a client-side. Eventually, it will be shifted to server-side, like the rest of Packing configuration, but this is something for 2026.

Binaries? Scripts?

I've covered this in depth here. TL;DR; Scripts - text version of your program. Binaries - compiled program. A lot of information gets lost (intentionally) during compilation, but for .NET it is still possible to recover most of the program if you know what you're doing.

For now, EA will include "pure" binaries, without any changes done to them. This is good from performance perspective and a step towards script protection, but for a person, who knows what he is doing, it is still possible to recover text of the program using tools called decompilers.

E.g. this is how decompiled code of one of PoE2 packs looks like - for a programmer this is like an open book.

Compilation modes

The new switch, available on pack configuration page, allows you to select one of three available compilation modes. They all come with pros and cons.

Script only

This is the default one. Nothing changes from how it worked for years - when you're exporting something, all your script code gets exported with no strings attached and compiled on-demand on end-user PC.

Pros:

• the script could be easily edited by anyone

Cons:

• there is a compilation cost involved, which may take hundreds and, sometimes, even thousands of milliseconds, which makes the entire UX feel sluggish
• the script could be easily edited by anyone

Script and binaries

Pros:

• the script could be easily edited by anyone
• no compilation cost whatsoever - when the program gets booted, everything is already compiled and ready-to-run. Compilation will occur only if you'll make some changed in the script

Cons:

• the script could be easily edited by anyone

Binaries only

Pros:

• the script is no longer available. At all. It is physically never touches end-user PC
• no compilation cost whatsoever - when the program gets booted, everything is already compiled and ready-to-run. Compilation will occur only if you'll make some changed in the script
• it is possible to protect your code and make it harder for anyone to steal your intellectual property

Cons:

• the script is no longer editable by end-user. Instead of script code there will be some read-only technical info.

What is next?

More protective layers. As soon as current functionality will be stabilized, I will add another feature, which will allow you to automatically obfuscate your code. With a good obfuscator, it is immensely hard to restore the program to its initial ("pure") state.

For comparison, this is that same script which I've shown above, but obfuscated - as you can see, it is barely readable due to all tricks applied to the code. Restoring it to initial state, even having the binary, is a very complex task.

For you, EA users, this will be just an additional checkbox. For EA this will be a major new compilation pipeline involving a whole bunch of services and tools.

Eventually, there will be even more protective layers added on top of obfuscation, such as native compilation and virtualization. I will share more details later this year.

Bugfixes/Improvements

• [SendSequence] Fixed a problem with SendSequences - under some conditions sequences of key presses could be interrupted prematurely, meaning that only part of the sequence would be sent. Thanks to @Rowenor for finding this out!
• [Macros] Made it so Comment node no longer throws exception when executed - this defeated the whole purpose of having that node in the tree

C# Scripting - Precompile/Preserve binaries

Details about both features were in this changelog. I've got the first feedback and done a few bugfixes/improvements in the mechanism - the most major is that the feature is now supported in Behavior Tree nodes as well.

Please keep in mind, that there may still be bugs and problems, I'll continue working on them in Q1-Q2. Eventually we'll get there.

Macros - no longer cancellable

Previously, when Enabling condition for the macro toggled back to Inactive state, EA interrupted Macro in the middle of whatever it was doing. This was intentionally implemented behavior which turned out to bring more problems than it solved. For now, I've completely disabled any ways of prematurely stopping Macros - there will be tools which would allow to do that, which I will release in the nearest future (something like Exit and Break commands).

Bugfixes/Improvements

• [SendSequence] Fixed a problem with SendSequences - under some conditions sequences of key presses could be interrupted prematurely, meaning that only part of the sequence would be sent. Thanks to @Rowenor for finding this out!
• [Macros] Made it so Comment node no longer throws exception when executed - this defeated the whole purpose of having that node in the tree

C# Scripting - Precompile/Preserve binaries

Those scripts, which you write in EyeAuras, are actually full-blown C# programs, which have to be compiled to their intermediary form (CIL, intermediate language) before getting executed by .NET platform.

By default, scripts are stored in their source code form all the way up to their execution. Only when some action or node gets executed for the first time, the script gets compiled and then executed. This is how the system has worked for almost 3 years.

But. In many-many cases, this leads to noticeable delay for the first time when something gets called, be it some UI which gets drawn by the script or some C# action which presses a bunch of buttons - first call will always take much more time than all the rest. This is not a great UX and with two new features I'd like to solve that.

Important! Initially these changes will affect only C# Action, but eventually they will be spread to all other places where you can use scripting, such as BT nodes, Overlays, etc.

Precompilation

EyeAuras tries to optimize compilation process by storing everything needed for that process in-memory - this allows to reduce compilation time to tens and hundreds of milliseconds in most cases. Unfortunately, in some cases this may take much more time - some dependencies are too heavy to hold them in ready-to-use state, meaning they have to be loaded/unloaded on demand and this increases compilation time to 2-5 seconds, which is definitely noticeable by the user.

With the new option, whenever the program loads the script for the first time, it will automatically try to compile it. This will prevent that delay when the script gets actually executed.

Preserve binaries

When the code gets compiled, its binary form could be stored and re-used for subsequent launches. This may bring some problems to the table, such as the compiled code no longer being valid after some EA infrastructure changes, but in most cases, previously compiled code should be compatible. This option allows to make it so EA will try to store not only the source code of your script, but its binary form as well. Best-case scenario - after the program is reloaded, there will be no re-compilation, meaning zero delay for end-user.

What is next?

One of the next improvements in that area will be wiring both of these into Packing mechanism. Ideally, when you'll publish the Pack, EA server will compile everything for you and will include only the binary version of your code into the final package (ofc optionally you will be able to include source code as well, just like it currently does). This should end up improving overall end-user experience.

Bugfixes/Improvements

• [SendText] Fixed incorrectly sized input text field