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

Bugfixes/Improvements

• [SendInput] Fixed a problem where interchanging Delays/SendInputs could block each other. This is a bug that has been introduced in the last version.

Новый релиз - 1.6 (RU/EN)

Большая часть изменений за последние 3 месяца была посвящена скриптингу. Добавлена новая подсистема диалоговых окон и оверлеев - Blazor Windows, крупные улучшения в интеграции NuGet-пакетов и внешних сборок, улучшения редактора и, наконец, появились экспорт и «Live Import», позволяющие использовать EA и любимую IDE одновременно.

Что дальше?

Packing – оптимизация паков и сублицензии

Прикладывать 600+ МБ исполняемый файл к 200КБ скриптам выглядит странновато, особенно если учесть, что со временем вы сами сможете публиковать лицензированный контент. Пугать новых пользователей UI со сотней кнопок/галочек и слайдеров, мягко говоря, не хочется. Плюс добавочный «груз», который таскает программа. В 2025 основная цель – реализовать систему, которая будет автоматически отключать те части интерфейса, что не используются. Например, авторам скриптов позволять прятать UI EyeAuras, отключать компьютерное зрение или модули ML и т.д. Технических моментов тут много, но все они решаемы. Посмотрим, как пойдут дела в ближайшем будущем.

Memory reading API – интеграция DMA

DMA-карты – это небольшие устройства, позволяющие считывать память ПК напрямую, без участия операционной системы, посредством прямого взаимодействия железа. Выявить такое чтение крайне сложно, что дает высокий уровень безопасности для конечного пользователя. Memory API, добавленное в ноябре, призвано унифицировать работу с оперативной памятью (через ReadProcessMemory), через драйверы и, со временем, через DMA-карты. Вы можете спокойно разрабатывать всё через привычный RPM, а затем переключиться на DMA, если нужен более безопасный вариант. Смена одной строчки кода – и пользователь сам решит, какой уровень защиты ему нужен.

Производительность UI

В 2024 она улучшилась благодаря новому UI-фреймворку, который вытеснил старый на большей части приложения, но впереди еще много работы, особенно при большом количестве аур (500+). В 2025 основной упор будет на максимально быстрое чтение/загрузку «Pack»-паков, ведь именно через них люди в основном распространяют скрипты. Возможно, появится облегченный вариант UI без обилия функций, который будет запускаться быстрее и работать эффективнее.

Доработки паков

Теперь, когда вы скачиваете «пак» с сайта — например, бота для рыбалки в Throne&Liberty(1 или 2), Path of Exile Helper или что-то другое — стало намного проще отслеживать, когда автор выложит новую версию. Теперь вы получите уведомление прямо в паке — пока это всего лишь небольшой бейдж у названия папки, но возможно, в будущем добавлю какой-то иной вид уведомления.

Слияние настроек пака

Но просто получать обновления — это лишь часть дела. Зачастую, если вы пользуетесь чьим-то паком, вы меняете там что-то под себя: свои хоткеи, названия окон, картинки и т.д. Теперь вы не потеряете все эти настройки, если автор выпустит новую версию. EyeAuras возьмет ваши локальные правки, сравнит их с правками автора (удалённые) и сольет вместе. Идеальный сценарий — вы получаете все обновления автора, сохранив свои изменения. Сейчас этот механизм довольно новый, могут быть ошибки, но теперь, когда он уже живой, все баги будут быстрее найдены (и исправлены).

В идеале, вы вообще не должны задумываться о работе этой системы. Посмотрим, как пойдет :-D

Rollback

Паки делают люди, а людям свойственно ошибаться. Все изменения, которые вносят авторы, версионируются и хранятся как ревизии. Сейчас вы можете откатить свои локальные изменения только до последней ревизии — это то же самое, что переустановить весь пак, но в 1000 раз быстрее. Когда механизм станет более отполирован, появится возможность переключаться на другие ревизии.

Preview

В другой вкладке можно увидеть содержимое пака, не скачивая его. Посмотреть хоткеи, общую логику, структуру. В будущем планируется возможность просмотра кода и Behavior Trees/Макросов прямо в этом же окне.

Activity Log

И последняя вкладка — это своего рода «Лог активности», где можно узнать, что поменялось, каков статус синхронизации и всё в этом духе.

Color Search – Добавлен выбор диапазона похожести (Similarity Range)

Появилась новая функция — теперь можно задать диапазон «Similarity», при котором триггер будет активен. По умолчанию триггер срабатывает, если Similarity выше заданного порога:

Теперь можно задать диапазон Min/Max значений для Similarity:

В таком случае, даже если Similarity дойдет до 100%, триггер все равно будет неактивным, потому что ожидаемое значение — в пределах 55.95 – 62.94 (включительно).

BT/Макросы – MouseMove – добавлен рандомный сдвиг (Random offset)

Добавлен простой способ рандомизировать X/Y. Вместе с «Input Smoothing» это должно сделать ввод более «человеческим».

Version History

Добавлена функция Version History, позволяющая просматривать и управлять снимками (snapshots) конфигурации, сохраненными во времени. Теперь можно сделать Soft Reset, чтобы вернуть состояние файлов без удаления истории, или Hard Reset, чтобы полностью откатиться к выбранному коммиту и убрать все изменения, сделанные после.

p.s. Русская версия доки доступна здесь

Улучшения Window Selector – добавлены «фильтр-свойства»

Window Selector – это тот контрол, который позволяет выбрать/указать целевое окно. Много лет он автоматически исключал все окна, которые принадлежат EA. Теперь это опционально и может быть отключено, если в выражении добавить [ownedBy=any], например: My Window [ownedBy=any] Это убирает фильтр и показывает все окна в системе, даже те, что созданы EyeAuras.

Похожий новый фильтр позволяет учитывать так называемые «Tool windows» (часто это оверлеи). По умолчанию они не отображаются. Но, если дописать [type=any], они тоже будут кандидатами: My Overlay [ownedBy=any][type=any] В таком случае перехватываем любые окна/оверлеи с заголовком My Overlay.

Напоминание – Replay в Capture-триггерах

Хочу напомнить о функции, добавленной довольно давно, но полезной в специфических случаях — например, если нужно определить цвет или картинку быстропропадающего баффа/дебаффа. За последнее время в нее было внесено несколько улучшений.

Просто нажимаете «Replay» — программа начинает записывать видимое изображение во временный видеофайл.

Когда закончили — жмете «Stop»

Окно предпросмотра переключается в режим, где данные берутся из записанного видео. Можно работать с этой «записью» так же, как если бы это была живая картинка — пипетка для пикселей, копирование регионов в буфер, и т.п. Когда закончите, просто переключитесь на Image as is в правом нижнем углу.

C# Сценарии – Экспорт/Импорт и Live Import в публичной alpha

Новый крупный функционал в стадии альфа: теперь можно экспортировать C# Overlays/Actions (Triggers и Nodes пока что нет) в виде .sln-проекта.

Зачем это нужно?

Современные IDE дают массу удобств, без которых сложновато разрабатывать что-то серьезное. Редактор скриптов в EA никогда не достигнет уровня полноценных IDE, это просто инструмент для быстрой работы со скриптами. Но к этому моменту SDK в EA настолько расширился, что вы можете делать полноценные приложения с NuGet-пакетами.

Экспорт

Затем вы можете открыть полученное решение в JetBrains Rider (рекомендую) или Microsoft Visual Studio.

В экспортированном решении может быть несколько проектов (зависит от того, что вы выгружали). Всё должно собираться без проблем, можете добавлять unit-тестыhttps://www.jetbrains.com/help/rider/Getting_Started_with_Unit_Testing.html).

Экспорт/Импорт

Про экспорт уже сказано, импорт обратно делается так же легко — просто выбираете .sln, который экспортировали, и EA загрузит изменения кода, которые вы сделали в IDE. Так как решение может состоять из нескольких проектов (например, отдельный проект для юнит-тестов), EA попытается сопоставить их с соответствующими объектами внутри программы (C# actions) и проигнорировать то, чего не знает.

Live Import

Естественно, вручную снова и снова жать «Импорт» — неудобно. Для этого есть «Live Import». Нужно выбрать .sln и EA начнет мониторить все изменения в папке с проектом. Как только что-то изменилось, EA тут же импортирует это обратно. По сути, код в C#-скрипте/оверлее становится «живым». Это особенно заметно для Overlays, которые тут же пересобираются при каждом изменении. Сделали правку в IDE — и EA почти мгновенно подхватил ее, пересобрал и загрузил. Это что-то вроде «колхозного Hot Reload» от Microsoft, но оно работает.

Интеграция с .git

Git — золотой стандарт систем контроля версий. Внутри EA он уже используется (например, для версии настроек). Поэтому при экспорте проектов автоматически создается git-репозиторий, или, если он уже был, делаются коммиты изменений. Это упрощает откат кода, если вдруг что-то пошло не так.

Отладка

На данный момент нельзя запустить проект прямо из IDE или отлаживаться в привычном режиме. Это планируется исправить в 2025. В идеале EA будет работать как рантайм для скриптов. Но тут еще предстоит много доработок.

C# Сценарии – добавлена поддержка Blazor/Razor

Серьезное расширение механизма скриптов — теперь он умеет компилировать Razor-компоненты. Blazor (Razor-компоненты — часть Blazor) — это, на мой взгляд, одно из самых удобных решений для UI на C#: сочетается мощь C# и производительность/удобство Web-технологий (HTML/CSS/JS).

EyeAuras сам на Blazor частично уже давно, с 2023. Приложение постепенно переписывается с WPF на Blazor. Где-то это уже видно (BT-редактор, редактор макросов, лог, биндинги, AuraTree). Если видите, что часть UI резво работает — скорее всего, там Blazor.

Раньше, чтобы сделать собственный интерфейс, нужно было использовать WebUI Overlay, где устаревший текстовый редактор и движок V2 от апреля 2023(!). Да, можно было подключить какую-то IDE (Visual Studio / Rider), но это лишняя морока. В то же время в BT, Макросах и C# Action/Trigger с января 2024 трудится улучшенный движок скриптов, хотя Razor там не было, потому что требовалось доделать кучу других систем. Сегодня мы имеем первый прототип — можно создавать свои окна прямо в коде.

Что уже работает:

• можно писать кастомные UI-компоненты прямо в редакторе
• есть полная автодополнение C#-части Razor-компонента и частичная — для Razor-разметки
• есть API, позволяющее создавать окна с вашими компонентами и управлять ими
• thread-safety – в отличие от WPF/WinForms (и даже официальной интеграции Blazor от Microsoft), в EA API потокобезопасен, то есть свойства окна можно менять из любого потока, программа сама разрулит все «глюки» с Invoke/BeginInvoke.
• API похож на нативный WPF, чтобы было проще писать код (и задавать вопросы ChatGPT)

C# Сценарии – Overlay v3

Добавлен новый тип Overlay, который использует последнюю версию движка скриптов EyeAuras (ту же, что и в C# Actions/Triggers/BehaviorTrees). Пока что старый C# оверлей и новый будут сосуществовать. Когда выйдет окончательная версия с поддержкой экспорта/импорта, старый, видимо, уйдет в прошлое, так как во всем проигрывает новому — в производительности, гибкости и т.д.

Помимо нового движка скриптов, оверлей v3 использует упомянутые Blazor окна, что делает оверлеи более отзывчивыми и приятными в работе.

ВНИМАНИЕ! Оверлей пока сырой — впереди много мелких (и не очень) доработок.

Примеры UI, сделанных в EA

Улучшения редактора скриптов

Редактор C# Script Action (пока только для Action, в BT/Triggers/Overlays все по-старому) получил кое-какие улучшения:

• теперь всплывает гораздо быстрее, обычно занимает ~1 секунду
• добавлена кнопка «Topmost», чтобы окно кода оставалось поверх остальных — удобно при редактировании «на ходу»
• теперь во всплывающем редакторе есть «EventLog», похожий на тот, что в основном окне, но показывающий только логи именно этого скрипта, что облегчает отладку
• исправлено несколько багов

C# Сценарии – Memory API – добавлен паттерн-скан (pattern scanning)

Что такое Pattern Scanning?

Это метод поиска определенных байтовых последовательностей в памяти. Он полезен для поиска функций, данных или кода, которые не всегда загружаются по одному и тому же адресу при работе программы.

Зачем это нужно?

1. Динамические адреса: Код и данные программы могут загружаться каждый раз в разные участки памяти. Паттерн-скан помогает найти нужное место, где бы оно ни оказалось.
2. Уникальные совпадения: Паттерны выступают как «отпечатки пальцев», позволяя определить искомые области в памяти на основе уникальных байтовых последовательностей.

BytePattern

Добавлен класс BytePattern, который поддерживает несколько способов описания паттернов. Это упрощает работу с различными вариантами, commonly используемыми при сканировании памяти.

Паттерн-сканирование доступно для любого объекта, реализующего интерфейс IMemory. Например:

using var process = LocalProcess.ByProcessName("pathofexile"); //uses naive RPM under the hood
Log.Info($"Process: {process}");
var modules = process.GetProcessModules(); //enumerate all loaded modules

using var memory = process.MemoryOfModule("pathofexile.exe"); //memory implements IMemory
Log.Info($"Process memory: {memory}, base: {memory.BaseAddress.ToHexadecimal()}");

// will find a singular offset pointing at 4th byte in the sequence
var offset = memory.FindOffset(BytePattern.FromTemplate("55 8B ?? ^ EC 00")); 

// will return dictionary with all found offsets for all given patterns
var playerPattern = BytePattern.FromTemplate("55 8B ?? ^ EC 00");
var targetPattern = BytePattern.FromTemplate("BB AA ??");
var offsetsByPattern = memory.FindOffset(playerPattern, targetPattern);

// by using Get* instead of Find* the code will throw an exception in case pattern is not found
var criticalOffset = memory.GetOffset(BytePattern.FromTemplate("55 8B ?? ^ EC 00")); 

Поддерживаемые типы паттернов

1. Byte Arrays:

   • Указываете точный массив байтов.
   • Пример:

   var pattern = BytePattern.FromPattern(new byte[] {0x55, 0x8B, 0xEC});
   

   Сопоставляет ровно эти байты.

2. C-Style Patterns:

   • Использует escape-последовательности типа \xAA\xBB\xCC.
   • Пример:

   var pattern = BytePattern.FromTemplate("\x55\x8B\xEC");
   

   Эквивалентно массиву байтов [0x55, 0x8B, 0xEC].

3. Hexadecimal Strings с Wildcards:

   • Паттерн задается в шестнадцатеричной форме с ?? в качестве любого байта.
   • Пример:

   var pattern = BytePattern.FromTemplate("55 8B ?? 83");
   

   Ищет любой участок, начинающийся на 55 8B, затем один байт, потом 83.

4. Masked Patterns:

   • Позволяет указать массив байтов и маску, где x — «фиксированный байт», ? — «любой байт».
   • Пример:

     var pattern = BytePattern.FromMaskedPattern(new byte[] { 0x55, 0x8B, 0xEC, 0x00, 0x08 }, "xxx??");
     

     Ищет 55 8B EC, а затем любые два байта.

5. Templates с оффсетом:

   • Паттерн задается в виде шаблона с символом ^, чтобы указать смещение.
   • Пример:

   var pattern = BytePattern.FromTemplate("55 8B ?? ^ EC 00");
   

   Ставит итоговый смещение непосредственно перед EC (пропуская 3 байта). То есть после нахождения паттерна итоговый адрес будет Offset + 3.

C# Сценарии – добавлена возможность подключать сборки по пути/имени

Уже несколько месяцев в скриптах есть возможность подключать nuget-пакеты

#r "nuget: Coroutine, 2.1.5"

Log.Info("Hello, World!"); //you can use Coroutine classes in that script

Теперь поддерживаются еще 2 способа подключения сборок. Внимание! Этот метод доступен только внутри Script.csx, что эквивалентно Program.cs в «обычном» C#.

Подключение сборки по пути (с диска)

Синтаксис очень похож.

#r "assemblyPath: D:\Work\EAExile\EAExileAgent.Shared.dll"

Log.Info("Hello, World!"); //you can use EAExileAgent classes in that script

Подключение по имени сборки

Этот способ позволяет подключать сборки, которые:

• уже загружены EyeAuras, но не попали в список сборок по умолчанию
• были загружены через Assembly.Load или другим способом и уже есть в AssemblyLoadContext/AppDomain
• лежат в GAC

Исторически в EA подключалось ОЧЕНЬ много сборок (больше 300) «по умолчанию», чтобы упростить жизнь пользователям. Но в перспективе это неудобно и усложняет обновления. Постепенно количество сборок, подключаемых по умолчанию, будет уменьшаться, а взамен появятся инструменты автодополнения, упрощающие подключение нужных библиотек.

#r "assemblyName: Grpc.Net.Client"

Log.Info("Hello, World!"); //you can use Grpc.Net.Client classes in that script

В рамках улучшений скриптового движка теперь можно использовать NuGet-пакеты с нативными библиотеками (например, ImGui). Многие разработчики уже знакомы с ImGui и могут теперь создавать оверлеи на его базе прямо в коде.

Ниже пример «живого» оверлея на ImGui, содержащего любые нужные вам элементы, работающего внутри EA и способного использовать все возможности — компьютерное зрение, нейросети, чтение памяти, эмуляцию ввода и т.д.

C# Сценарии – BlazorWindows – добавлено NoActivate

Добавлено полезное свойство NoActivate, которое делает так, что окно реагирует на клики мышью, но не перехватывает фокус. Это значит, что вы можете сделать оверлей с разными элементами управления, при этом активным останется игровое окно, и пользователь легко будет вносить изменения прямо поверх игры.

C# Сценарии – BlazorWindows – добавлен ComplexFileProvider

В IBlazorWindow добавлены новое свойство и метод, позволяющие подключать собственные провайдеры для данных файлов. Вы можете использовать RegisterFileProvider или AdditionalFileProvider, и любой файл, на который вы ссылаетесь в Blazor-коде, станет доступен в окне. Это могут быть стили, картинки, видео и т.д., в том числе сгенерированные динамически.

    /// <summary>
    /// Gets or sets a value indicating whether the window should NOT be activated when clicked
    /// </summary>
    bool NoActivate { get; set; }

Рекомендовано начать с встроенных провайдеров:

• ComplexFileProvider — позволяет комбинировать несколько FileProviders. Ищет файлы в порядке добавления
• InMemoryFileProvider — хранит файлы в памяти, кешируя их
• InMemoryFileInfo — создает один файл «на лету». Данные загружаются сразу при создании
• LazyInMemoryFileInfo — «лениво» загружает данные, только когда они реально нужны

Так вы можете без труда добавлять разный контент на страницу.

    /// <summary>
    /// Gets or sets additional file provider which will be used by Blazor
    /// </summary>
    IFileProvider AdditionalFileProvider { get; set; }

    /// <summary>
    /// Adds additional file provider which will be used by Blazor. Added to the end of the list.
    /// Removed on disposal
    /// </summary>
    IDisposable RegisterFileProvider(IFileProvider fileProvider);

Пример кода, который грузит файл с диска и делает его доступным для HTML или стилей:

var fileProvider = new InMemoryFileProvider();
fileProvider.AddOrUpdate(new InMemoryFileInfo("hello.png", File.ReadAllBytes(@"D:\hello.png")));

Разумеется, данные можно и сгенерировать в реальном времени.

YoloEase – вышла новая версия 0.1.65

Главный упор — исправлены проблемы с авто-аннотацией и обеспечена корректная работа Google Collab. Скоро будет видео на эту тему. Также улучшена производительность, особенно на средних и больших датасетах (5–10 тысяч изображений).

Local Training

При «Local Training» модель обучается на вашем «железе». Плюс — вы платите только за электроэнергию, минус — нужно все настроить самостоятельно.

Google Collab

При использовании Google Collab обучение идет в облаке — реальный процесс запущен на серверах. Вы можете выбирать бесплатный режим или платный, как удобнее.

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

• [Crash] Исправлен краш при установленных Offset Width + Position/ContentAnchor в Overlays
• [Crash] Исправлен краш при одновременном использовании Offset+Anchor
• [Crash] Изменено, как обрабатываются внутренние «app channels» — теперь не должно быть редкого краша
• [Crash] Исправлен краш из-за неправильной очистки BehaviorSubject
• [Crash] Исправлен краш при FPS = 1e-10
• [UI] Уменьшено количество выделений памяти на старте — программа чуть меньше ест RAM
• [UI] Незначительные изменения при первом запуске — панель лога стала больше, а вместо ауры по умолчанию создается Macro
• [UI] Добавлены новые действия — Execute Tree и Execute Macro, чтобы «связать» макросы и BT-деревья
• [UI] Исправлен баг, из-за которого C#-экшен отменялся в некоторых случаях, даже если Ignore Cancellation был включен
• [UI] Добавлен узел SendText (и в BT, и в Макросах)
• [UI] Исправлен счетчик Effects #EA-753 Effects counter v7668 by Headway9016
• [UI] В редакторе Bindings при сбое теперь выводится ошибка
• [UI] Исправлен баг, когда биндинг BT-to-BT не работал корректно
• [Scripting] Починен баг с BlazorWindow Opacity, когда в некоторых случаях значение не задавалось
• [Scripting] Исправлен баг, когда ScriptingAPIs освобождался раньше времени, из-за чего вырубался OSD/окна и т.д.
• [Scripting] Добавлен IPerformanceMetricsAddon, позволяющий трекать производительность приложения
• [Scripting] Изменен порядок компиляции скриптов — поправлен баг, когда Razor не собирался корректно
• [Scripting] Исправлены подсветки ошибок в редакторе (возвращено подчеркивание строк, как было до добавления Razor)
• [Scripting] Улучшен вывод Log.Info/Debug/Warn — теперь переносы строк в UI обрабатываются корректно
• [Scripting] Исправлен баг в «Loop rewriter» — вложенные классы обрабатывались неверно
• [Scripting] Доработки CodeEditor — новая подсветка ошибок и единый «шаблон» Razor-файла
• [Scripting] Console.WriteLine теперь выводит текст в EventLog (чтобы ChatGPT-сгенерированные скрипты лучше «читались»)
• [Scripting] Исправлен баг с nuget-пакетами в скриптах — иногда они обрезались рерайтером
• [Scripting] Исправлен баг, когда новые/удаленные файлы не всегда отображались в UI
• [Scripting] Исправлено поведение кнопок при изменении размеров окна редактора — теперь его удобнее «отдельно» подвигать на экране
• [Scripting] Повышена производительность редактора — переключение между файлами быстрее
• [Scripting] Исправлен баг с INotifyPropertyChanged, связанный с привязками в скриптах
• [Capture] В эффектах и Color Search поправлен баг с пипеткой в режиме «Replay»
• [Capture] Исправлен баг, когда WGCS пытался захватывать изображение, пока окно не отобразилось (Argument out of range)
• [SendInput] Улучшен лог клавиш/мыши
• [SendInput] Поднята производительность Windows Message API при работе с несколькими окнами
• [Sync] Исправлена ошибка в механизме слияния аур v7612 #EA-735 by Steamy Index is equal to or greater than Count
• [Bindings] Исправлен баг, когда в Bindings Editor связь создавалась к предыдущему выделенному элементу, а не к текущему
• [BehaviorTrees] Улучшения в BT — теперь пустое BT не выбрасывает исключение при тике
• [BehaviorTrees] Добавлен узел KeyPress и MouseMoveRel (с привязками)

Mostly hotfixes of NY release.

Bugfixes/Improvements

• [Crash] Fixed a problem with SendSequence in some cases leading to crashes ("Window activation failed")
• [UI] Made it so if there is some disconnect from the server, NetworkMessages try to re-connect with more aggressive strategy
• [WebUI] Fixed compatibility bug with IEyeContext - should fix a problem with older overlays not working properly
• [Scripting] Minor Memory API changes - addded MemoryOfModule (which accept module name OR module descriptor) to IProcess
• [Scripting] Memory API improvements - better logging and formatting

C# Scripting - BlazorWindows - added NoActivate

Added very useful property called NoActivate, which, when set, makes it so the window will react to mouse clicks, but will not intercept user focus. Meaning you can have an overlay with a bunch of controls, allowing user to easily disable and enable some functionality of your bot while game window will remain active.

    /// <summary>
    /// Gets or sets a value indicating whether the window should NOT be activated when clicked
    /// </summary>
    bool NoActivate { get; set; }

C# Scripting - BlazorWindows - added ComplexFileProvider

Added to IBlazorWindow one new property and one method. Both of those could be used to provide custom providers for file data. You can pick whichever flavour you want - add your custom file provider either via RegisterFileProvider or by using AdditionalFileProvider and any file, which you will be referencing in your custom Blazor code, will have access to that file. It could be runtime-generated styles, could be images, video or anything you may need to create a really dynamic user interfaces.

For now, I would recommend to use built-in:

• ComplexFileProvider - allows to combine multiple FileProviders together, resolution will happen in order of addition
• InMemoryFileProvider - allows to store file data in-memory, files will be cached for better performance
• InMemoryFileInfo - allows to create one in-memory file reference. The data is loaded as soon as FileInfo is constructed
• LazyInMemoryFileInfo - allows to create lazy file reference, which will be loaded only when accessed

which allow you to easily add new content to your pages.

    /// <summary>
    /// Gets or sets additional file provider which will be used by Blazor
    /// </summary>
    IFileProvider AdditionalFileProvider { get; set; }

    /// <summary>
    /// Adds additional file provider which will be used by Blazor. Added to the end of the list.
    /// Removed on disposal
    /// </summary>
    IDisposable RegisterFileProvider(IFileProvider fileProvider);

Example of the code, which will load file from the disk and make it available for use in styles or HTML:

var fileProvider = new InMemoryFileProvider();
fileProvider.AddOrUpdate(new InMemoryFileInfo("hello.png", File.ReadAllBytes(@"D:\hello.png")));

Of course, you can generate the displayed data in runtime as well.

Bugfixes/Improvements

• [Scripting] Fixed problem with BlazorWindow Opacity not being set properly under some circumstances

Packing improvements

Now, after you've downloaded a pack from the website - be it a fishing bot for Throne&Liberty(1 or 2), Path of Exile Helper or any other one - you can now much-much easier track when it will be updated by the author. You will get a notification in the pack right away - for now it will be a small badge in the folder name. Afterwards, I may add some other form of notification.

Pack settings merging

But just getting updates is not everything thing feature brings. More often than not, when you started using someone elses pack, you do some changes in it - set up your own keybinds, change window name, change some image, etc. Now you won't be losing those changes even when new version of the pack gets released by the author - EyeAuras will pick your local changes, compare them with author's changes(remote) and will Merge them together. Best case scenario - you get all the new changes which author of the pack did AND you have your previously done changes intact. This mechanism is still fresh out of the oven and could have some problems in it, but now, when this feature finally came into play, those bugs will be discovered(and fixed!) much quicker.

Ideally, you won't have to think about that system ever. We'll see how it goes :-D

Rollback

Packs are developed by human beings, and we tend to make mistakes. All changes done by authors of the packs are versioned and stored as revisions. For now, you can reset your changes only to the current latest revision, this is equivalent of re-downloading the entire pack, but 1000 times faster. As soon as the mechanism will be polished enough, I will enable ability to switch between revisions.

Preview

Another tab allows you to see how the pack looks like without even downloading it. Check hotkeys, general logic, structure. In one of the future updates you'll be able to check out the code and Behavior Trees/Macros as well from that very same window.

Activity Log

And the very last tab is just another form of Event Log - it contains information about changes, current sync status and everything else around it.

YoloEase - new version 0.1.65 released

Primary focus - fixed problems with auto-annotation and ensure that Google Collab now properly works. I'll post a video on this soon. Plus several improvements to performance, which are especially noticeable on mid+ sized datasets (5-10k of images).

Local Training

With Local Training you're training the model using your own hardware. Positive side - you're paying only for electricity, negative - you have to have everything setup and ready to go

Google Collab

With Google Collab you're using cloud infrastructure to do the training, meaning that the actual training code runs elsewhere. You can either use a free tier or a paid one, your choice.

Bugfixes/Improvements

• [UI] Tuned memory allocations a bit - the app should consume less memory on startup.

C# Scripting - Export/Import and Live Import are in public alpha

New major feature entering alpha phase - it is now possible to Export your C# Overlays/Actions (Triggers and Nodes are still not allowing that) into .sln solution.

How is it useful ?

Modern IDEs provide a lot of QoL features without which it is inconvenient to do any kind of serious development. EA script editor will never be able to close that gap between "text editor with syntax highlighting and autocompletion" and real IDEs. It is a tool for script development, that is it. But at that point set of features that EA SDK provides has gone far beyond what is required for usual scripting - you can create a full-blown program with NuGet packages

Export

You can then open this solution in JetBrains Rider (recommended) or Microsoft Visual Studio.

Solution which you'll get will consist of one or multiple projects (depending on what you've exported). It is build-able and you can add unit-testshttps://www.jetbrains.com/help/rider/Getting_Started_with_Unit_Testing.html).

Export/Import

Export I've already briefly covered, importing changes back is as simple as selecting Solution file you've previously exported. EA will load changes in source code files which you've made in IDE. As solution can have multiple projects in it (e.g. unit-tests project), EA will try to match projects which you already have in the program (in a form of C# actions) to those in solution and will ignore those which it is not aware of.

Live Import

Importing changes over and over and over again could be exhausting and is not even close to desired workflow. That is where another feature comes into play. Click on Live Import, select .sln and EA will start monitoring for any changes made in that directory where solution resides in. As soon as it will detect those changes, it will import them back to EA. Essentially, this make it so the code in C# action/overlay you're working on becomes live. This is especially noticeable for Overlays, which are inherently recompiled as soon as any changes are made. So as soon as you'll do some changes in Overlay code, it will be almost instantly picked up by EA, recompiled and loaded. Think of it as of ghetto spin-off of Hot Reload feature, but that works.

Integration with .git

Git is a golden standard of version control systems. EA internally uses it for many things such as configuration version control. So it was just natural to set exported projects as git repositories during export. Whenever you're exporting/importing changes back to EA, it automatically creates git repository OR commits changes you've made. This makes it easy to rollback the code in case something goes wrong.

Debugging

For now, you cannot debug or run the project from IDE. This will be one of the improvements I'll be working on in 2025. Eventually, you should be able to use EA as a script runner. But to make it happen I still have to do some changes.

Bugfixes/Improvements

• [UI] Minor changes for the first start - event log panel is larger, Macro gets created instead of an aura
• [Scripting] Fixed a bug which lead to premature disposal of ScriptingAPIs, this would correspondingly lead to disposal of OSD/Windows/etc created by script

Bugfixes/Improvements

• [Scripting] Changed how buttons behave when editor gets resized - now it is much easier to have small floating panel with the script somewhere on the screen, while you're editing the code in IDE
• [Scripting] Editor performance tweaked - should switch between files faster
• [Scripting] Added Restart button which... well, restarts the script. More convenient than stop-starting every time. Keep in mind that this is NOT needed in C# Overlays - they operate in always-live mode by default.

MouseMove - added Random offset

Added simple way of randomizing XY. Together with Input Smoothing, this should make inputs appear more humane.

Bugfixes/Improvements

• [UI] Added two new actions - Execute Tree and Execute Macro which could be called from Auras. This is a "glue" which allows to wire together two automation approaches which exist in EA
• [Scripting] Changed how assemblies are loaded - fixes a problem with transitive dependencies
• [Scripting] Exposed IPerformanceMetricsAddon - could be used to track performance of the app via scripting
• [Scripting] Changed script compilation order - fixes a problem with Razor sometimes not being compiled correctly

C# Scripting - added ability to reference assemblies by path/name

For several months we've had the feature in scripts, which allows to reference nuget packages

#r "nuget: Coroutine, 2.1.5"

Log.Info("Hello, World!"); //you can use Coroutine classes in that script

The support has not been extended and you can reference assemblies in 2 other ways now. Important! This method of referencing assemblies is available only inside Script.csx which is equivalent of your Program.cs in "normal" C#

By assembly path - from file

Syntax is very similar.

#r "assemblyPath: D:\Work\EAExile\EAExileAgent.Shared.dll"

Log.Info("Hello, World!"); //you can use EAExileAgent classes in that script

By assembly name

This method of referencing assemblies allows you to reference those assemblies which are either:

• already loaded by EyeAuras, but have not been included into default referenced assemblies list
• were loaded using Assembly.Load or via any other means, but they are already part of AssemblyLoadContext/AppDomain
• are in GAC

Historically, EA referenced A LOT of assemblies by default, more than 300 assemblies. This allows users to save some type on pre-configuring these dependencies on each and every C# action/BT node/etc, but this is not a good way long-term. Gradually, I'll be de-linking more and more default assemblies and will include a better auto-completion techniques which would allow to easily include those libraries which are needed for your script. In the future, this will make upgrading the program easier for everyone

#r "assemblyName: Grpc.Net.Client"

Log.Info("Hello, World!"); //you can use Grpc.Net.Client classes in that script

Bugfixes/Improvements

• [Scripting] Fixed a problem with CancellationToken rewriter - it was handling optional arguments incorrectly in some cases