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

Подробности по обеим возможностям были в этом changelog.

Я уже получил первые отзывы и внёс несколько исправлений и улучшений в сам механизм. Самое заметное изменение — теперь эта функция поддерживается и в узлах Behavior Tree.

Имейте в виду, что в ней всё ещё могут встречаться баги и другие проблемы. Я продолжу дорабатывать её в Q1–Q2. Постепенно доведём всё до ума.

Macros — больше не прерываются

Раньше, когда условие Enabling для макроса переключалось обратно в состояние Inactive, EA прерывал Macro прямо посреди выполнения. Это было сделано намеренно, но на практике оказалось, что такое поведение создаёт больше проблем, чем решает.

На данный момент я полностью отключил любые способы преждевременно останавливать Macros. В ближайшем будущем появятся отдельные инструменты, которые позволят делать это корректно — что-то вроде команд Exit и Break.

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

• [SendSequence] Исправлена проблема с SendSequences — при некоторых условиях последовательности нажатий клавиш могли прерываться раньше времени, из-за чего отправлялась только часть последовательности. Спасибо @Rowenor, что заметил это!
• [Macros] Узел Comment больше не выбрасывает исключение при выполнении — раньше это полностью сводило на нет сам смысл существования этого узла

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

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

• [SendInput] Исправлена проблема, из-за которой при чередовании Delays и SendInputs они могли блокировать друг друга. Эта ошибка появилась в последней версии.

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

Большая часть изменений за последние 3 месяца была связана со скриптингом.

Появились новые оверлеи, крупные улучшения в работе с NuGet-пакетами и внешними сборками, доработки редактора и, наконец, Export и Live Import — функции, которые позволяют использовать EyeAuras вместе с вашей любимой IDE.

Что дальше?

Паки: облегчение сборок и сублицензии

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

Цель на 2025 год — реализовать систему, которая будет автоматически отключать неиспользуемые части интерфейса. Авторы смогут скрывать UI EyeAuras, отключать модули computer vision или ML и так далее. В таком подходе хватает технических сложностей, но все они выглядят решаемыми. Посмотрим уже в ближайшем будущем.

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

DMA-карты — это небольшие устройства, которые позволяют читать память ПК без участия ОС, через прямое взаимодействие hardware-to-hardware. Из-за этого обнаружить такое чтение памяти крайне сложно, а значит, конечный пользователь получает очень высокий уровень безопасности.

Memory API, добавленный в ноябре, призван унифицировать работу с RAM: через команды уровня ОС (ReadProcessMemory), через драйверы и в перспективе — через DMA-карты.

То есть вы разрабатываете всё на удобном и простом RPM, а затем переключаетесь на гораздо более безопасный DMA. По сути, поменяв всего одну строку кода, вы дадите пользователю возможность самому выбрать желаемый уровень безопасности.

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

В 2024 году она уже стала лучше: новый UI framework заменил старый во многих частях программы. Но работы ещё много — особенно если речь идёт о больших наборах аур (500+).

Главный фокус 2025 года — сделать загрузку паков максимально быстрой, потому что именно паки становятся основной формой распространения ваших скриптов. Возможно, появится и облегчённый альтернативный UI: менее функциональный, зато очень быстрый и эффективный при загрузке.

Улучшения паков

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

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

Объединение настроек пака

Но обновления — не единственное, что даёт эта функция. Очень часто, когда вы начинаете пользоваться чужим паком, вы подстраиваете его под себя: меняете хоткеи, имя окна, изображения и так далее.

Теперь такие локальные изменения не будут теряться при выходе новой версии от автора. EyeAuras возьмёт ваши локальные правки, сравнит их с удалёнными изменениями автора и выполнит Merge. В идеальном сценарии вы получаете все новые изменения от автора и при этом сохраняете все свои настройки.

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

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

Rollback

Паки делают люди, а люди ошибаются. Все изменения, которые вносят авторы паков, версионируются и сохраняются как revisions.

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

Как только механизм станет достаточно отлаженным, я включу возможность переключаться между revision.

Preview

Отдельная вкладка позволяет посмотреть, как выглядит пак, вообще не скачивая его. Можно проверить хоткеи, общую логику и структуру.

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

Activity Log

И последняя вкладка — это ещё одна форма Event Log. В ней отображаются изменения, текущий статус синхронизации и всё, что с этим связано.

Color Search — добавлен выбор диапазона Similarity

Появилась новая возможность: теперь можно задавать диапазон Similarity, при котором триггер считается Active.

По умолчанию триггер активен только если Similarity выше заданного порога, например:

Теперь можно указать диапазон Min/Max для similarity, например:

В этом случае, даже если Similarity дойдёт до 100%, триггер всё равно будет Inactive, потому что ожидаемое значение должно попадать в диапазон от 55.95 до 62.94 включительно.

BT/Macros — в MouseMove добавлен Random offset

Добавлен простой способ рандомизировать XY.

Вместе с Input Smoothing это должно сделать ввод более «человечным».

Version History

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

P.S. Русская версия документа доступна здесь

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

Window Selector — это контрол, через который вы выбираете или задаёте Target Window. Много лет он автоматически отфильтровывал все окна, находящиеся под управлением EA.

Теперь это поведение опционально: его можно отключить, добавив [ownedBy=any] в выражение, например:

My Window [ownedBy=any]

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

Также добавлен ещё один фильтр похожего типа, который позволяет захватывать так называемые Tool windows — к этому типу обычно относятся оверлеи.

По умолчанию такие окна игнорируются, но их можно включить в кандидаты, добавив в конец match expression [type=any], например:

My Overlay [ownedBy=any][type=any]

Такое выражение захватит любое окно/оверлей с заголовком My Overlay.

Напоминание: Replay в Capture triggers

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

Вы просто нажимаете Replay, и программа начинает сохранять запись во временный видеофайл.

Когда всё записано — нажимаете Stop.

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

C# Scripting — Export/Import и Live Import вышли в публичную alpha

Большая новая функция вошла в стадию alpha: теперь можно экспортировать ваши C# Overlays/Actions (Triggers и Nodes пока это не поддерживают) в .sln solution.

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

Современные IDE дают огромное количество QoL-функций, без которых заниматься хоть сколько-нибудь серьёзной разработкой неудобно. Редактор скриптов в EA никогда не сможет закрыть разрыв между «текстовым редактором с подсветкой синтаксиса и автодополнением» и полноценной IDE. Он и не должен — это инструмент именно для разработки скриптов.

Но при этом набор возможностей EA SDK уже давно вышел за рамки обычного скриптинга: с помощью NuGet packages можно собирать полноценные программы.

Export

После этого solution можно открыть в JetBrains Rider (рекомендуется) или Microsoft Visual Studio.

Полученная solution будет состоять из одного или нескольких проектов — в зависимости от того, что именно вы экспортировали. Она собирается без проблем, и в неё можно добавлять unit-tests.

Export/Import

Экспорт я уже кратко описал выше, а импорт изменений обратно ещё проще: достаточно выбрать файл Solution, который вы ранее экспортировали. EA загрузит изменения в исходных файлах, которые вы внесли в IDE.

Так как solution может содержать несколько проектов (например, проект с unit-tests), EA попытается сопоставить проекты из solution с теми проектами, которые уже существуют в программе в виде C# actions, и проигнорирует те, о которых ничего не знает.

Live Import

Импортировать изменения снова и снова довольно утомительно — и это совсем не тот workflow, который хочется получить.

Именно для этого и появился Live Import.

Нажимаете Live Import, выбираете .sln, и EA начинает отслеживать любые изменения в директории, где лежит solution. Как только изменение будет обнаружено, оно сразу импортируется обратно в EA. По сути, код в C# action/overlay, над которым вы работаете, становится «живым».

Особенно хорошо это заметно на Overlays, которые по своей природе перекомпилируются при любых изменениях. То есть как только вы меняете код Overlay, EA почти мгновенно подхватывает эти изменения, перекомпилирует и загружает их. Можно считать это таким кустарным аналогом Hot Reload, но рабочим.

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

Git — это золотой стандарт среди систем контроля версий. Внутри EA он уже используется во многих местах, например для контроля версий конфигурации. Поэтому было вполне естественно во время экспорта превращать экспортированные проекты в git-репозитории.

При каждом экспорте/импорте изменений обратно в EA программа автоматически либо создаёт git-репозиторий, либо коммитит внесённые изменения. Благодаря этому код легко откатить, если что-то пошло не так.

Отладка

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

C# Scripting — добавлена поддержка Blazor/Razor

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

Сама EyeAuras тоже использует его внутри с 2023 года и постепенно переписывается с WPF на Blazor. В будущем приложение, как ожидается, станет полностью Blazor-driven. Уже сейчас на нём работают: BT editor, Macro editor, EventLog, Bindings, AuraTree. Если какая-то часть программы ощущается особенно быстрой и отзывчивой, почти наверняка там используется Blazor.

---

Раньше, если вы хотели сделать собственный UI для своего бота, единственным по-настоящему рабочим вариантом был WebUI Overlay. Но там используется уже сильно устаревший текстовый редактор и, что важнее, старая версия движка скриптов (V2) ещё из апреля 2023(!). Конечно, можно было открыть проект в своей IDE — например, Visual Studio или Rider, — но это было не слишком удобно и требовало лишних действий.

При этом BT, Macros и C# Action/Trigger с января 2024 уже используют более новую версию движка скриптов, но поддержки Razor там не было — технически это оказалось сложной задачей, и сначала пришлось подготовить другие системы.

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

Что уже умеет:

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

C# Scripting — Overlay v3

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

В ближайшие несколько недель старый C# overlay и новый будут существовать параллельно. Как только я выпущу Export/Import functionality, старый вариант уйдёт, потому что новый лучше буквально во всём: производительность, гибкость и так далее.

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

IMPORTANT! Overlay ещё очень далёк от завершения — в ближайшие недели я продолжу убирать шероховатости.

Несколько примеров UI, созданных в EA

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

Редактор C# Script Action (пока только для Action — редакторы в BTs/Triggers/Overlays остались прежними) получил несколько полезных доработок:

• всплывающее окно редактора теперь должно открываться заметно быстрее, обычно примерно за ~1 секунду

• добавлена кнопка Topmost, которая позволяет закрепить редактор поверх остальных окон — очень удобно при редактировании в реальном времени

• в вынесенном редакторе теперь есть свой EventLog, похожий на тот, что в главном окне приложения, но он показывает только сообщения, сгенерированные самим скриптом — отлаживать стало проще

• исправлено несколько багов тут и там

C# Scripting — Memory API: добавлен pattern scanning

Что такое Pattern Scanning?

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

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

1. Dynamic Locations: программы часто загружают код и данные в разные места при каждом запуске. Pattern scanning помогает найти нужное независимо от того, куда именно всё попало.
2. Unique Matches: паттерны работают как отпечатки пальцев — позволяют находить конкретные участки памяти по уникальным последовательностям байтов.

---

BytePattern

Для поддержки разных способов описания паттернов был добавлен класс BytePattern. Благодаря этим изменениям стало проще работать с разными типами паттернов, которые обычно используются при сканировании памяти.

Pattern scanning доступен для любого типа, реализующего интерфейс 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, как в C-style patterns.
   • Пример:

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

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

3. Hexadecimal Strings with Wildcards:

   • Паттерны задаются как hex-строки с ?? для wildcard-байтов (любой байт).
   • Пример:

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

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

4. Masked Patterns:

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

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

     соответствует любой последовательности, начинающейся с 55 8B EC, после которых идут любые два байта.

5. Templates with Offsets:

   • Паттерны задаются через template, а смещение совпадения помечается символом ^.
   • Пример:

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

   задаёт offset прямо перед EC (то есть после пропуска 3 байт). Это значит, что после нахождения паттерна итоговый offset будет равен Offset + 3.

C# Scripting — добавлена возможность ссылаться на сборки по пути/имени

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

#r "nuget: Coroutine, 2.1.5"

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

Теперь эта поддержка расширена, и ссылаться на сборки можно ещё двумя способами.

Важно! Такой способ подключения сборок доступен только внутри 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. С одной стороны, это экономит время пользователям и избавляет от необходимости заранее настраивать зависимости в каждом C# action/BT node и т. д. Но в долгосрочной перспективе это не лучший подход.

Постепенно я буду убирать всё больше default-assembly references и добавлять более удобные механики автодополнения, чтобы нужные библиотеки было легко подключать под конкретный скрипт. В будущем это упростит обновление программы для всех.

#r "assemblyName: Grpc.Net.Client"

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

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

Ниже — пример живого кликабельного ImGui overlay, который может содержать любые данные и работать с любыми возможностями EA: computer vision, neural networks, memory read, input emulation — да с чем угодно.

C# Scripting — BlazorWindows: добавлен NoActivate

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

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

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

C# Scripting — BlazorWindows: добавлен ComplexFileProvider

В IBlazorWindow добавлены одно новое свойство и один метод. Оба можно использовать для подключения собственных providers для файловых данных. Выбирайте любой вариант: либо добавляйте provider через RegisterFileProvider, либо используйте AdditionalFileProvider — и любой файл, на который вы ссылаетесь в своём кастомном Blazor-коде, будет доступен через этот provider.

Это могут быть runtime-сгенерированные стили, изображения, видео — всё что угодно, что нужно для действительно динамичных интерфейсов.

Пока что я рекомендую использовать встроенные варианты:

• ComplexFileProvider — объединяет несколько FileProvider'ов, разрешение идёт в порядке их добавления
• InMemoryFileProvider — хранит данные файлов в памяти, файлы кешируются для лучшей производительности
• InMemoryFileInfo — создаёт одну ссылку на in-memory файл; данные загружаются сразу при создании FileInfo
• 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

Главный фокус — исправлены проблемы с auto-annotation и сделано так, чтобы Google Collab теперь работал корректно. Скоро выложу видео на эту тему.

Плюс есть несколько улучшений производительности, особенно заметных на датасетах среднего и большого размера (5–10k изображений).

Local Training

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

Google Collab

В случае с Google Collab обучение идёт в облачной инфраструктуре, то есть сам код тренировки выполняется не у вас локально. Можно использовать как бесплатный тариф, так и платный — на ваш выбор.

Bugfixes/Improvements

• [Crash] Исправлен краш, возникавший в Overlays, если были заданы Offset Width + Position/ContentAnchor
• [Crash] Исправлен краш, возникавший при одновременном использовании Offset+Anchor
• [Crash] Изменена обработка внутренних app channels — это должно предотвратить один редкий тип падений
• [Crash] Исправлен краш, связанный с disposal BehaviorSubject
• [Crash] Исправлен краш, возникавший, если значение FramesPerSecond было слишком маленьким, например 1e-10

---

• [UI] Немного оптимизированы выделения памяти — приложение должно потреблять меньше памяти при запуске
• [UI] Небольшие изменения для первого запуска — панель event log стала больше, вместо aura теперь создаётся Macro
• [UI] Добавлены два новых actions — Execute Tree и Execute Macro, которые можно вызывать из Auras. Это «клей», позволяющий связать два подхода к автоматизации, существующие в EA
• [UI] Исправлена проблема, из-за которой C# Action в некоторых случаях отменялся, даже если был включён Ignore Cancellation
• [UI] Добавлен узел SendText, доступный и в BTs, и в Macros
• [UI] Исправлен счётчик эффектов #EA-753 Effects counter v7668 by Headway9016
• [UI] Улучшение в Bindings Editor — теперь при ошибке binding'а будет показано сообщение
• [UI] Исправлена проблема с некорректной работой bindings BT-to-BT
• [Scripting] Исправлена проблема, из-за которой Opacity у BlazorWindow в некоторых случаях применялась неправильно
• [Scripting] Исправлен баг, приводивший к преждевременному disposal ScriptingAPIs, а это, в свою очередь, вызывало disposal созданных скриптом OSD/Windows и т. д.
• [Scripting] Экспортирован IPerformanceMetricsAddon — его можно использовать для отслеживания производительности приложения через скрипты
• [Scripting] Изменён порядок компиляции скриптов — это исправляет проблему, из-за которой Razor иногда компилировался некорректно
• [Scripting] Исправлена проблема в rewriter для CancellationToken — в некоторых случаях он неправильно обрабатывал optional arguments
• [Scripting] Исправлена подсветка ошибок в текстовом редакторе — теперь ошибочные строки должны снова корректно подчёркиваться, как это было до изменений с Razor
• [Scripting] Улучшено форматирование Log.Info/Debug/Warn — теперь UI корректно отображает переносы строк
• [Scripting] Исправлена проблема в Loop rewriter — вложенные классы обрабатывались неправильно
• [Scripting] Улучшения CodeEditor — изменена подсветка ошибок, добавлен single-file Razor template и обновлён сам шаблон
• [Scripting] Console.WriteLine теперь выводит сообщения в EventLog. Это сделано, чтобы повысить удобство работы со скриптами, сгенерированными ChatGPT
• [Scripting] Исправлена проблема с nuget-пакетами в скриптах — в некоторых случаях rewriters удаляли их
• [Scripting] Исправлена проблема, из-за которой новые/удалённые файлы не всегда отображались в UI
• [Scripting] Изменено поведение кнопок при изменении размера редактора — теперь гораздо проще держать где-то на экране маленькую плавающую панель со скриптом, пока код редактируется в IDE
• [Scripting] Подкручена производительность редактора — переключение между файлами должно происходить быстрее
• [Scripting] Исправлена проблема с реализацией INotifyPropertyChanged в скриптинге
• [Capture] В effects и в Color Search исправлена проблема, из-за которой Color picker некорректно работал с Replay
• [Capture] Исправлена проблема, когда WGCS пытался захватить изображение до того, как окно становилось видимым (Argument out of range)
• [SendInput] Улучшен вид логов keypresses/mousemove
• [SendInput] Улучшена производительность Windows Message API в сценариях с несколькими окнами
• [Sync] Исправлена ошибка в механизме merge аур v7612 #EA-735 by Steamy Index is equal to or greater than Count
• [Bindings] Исправлена проблема в Bindings Editor — в некоторых случаях bindings создавались для ранее выбранного элемента, а не для текущего
• [BehaviorTrees] Улучшения BT — пустой BT больше не вызывает exceptions при Ticked
• [BehaviorTrees] Добавлены новые bindings для узлов 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.