ImGui integration EN / RU

Started working on native integration with ImGui - this is alternative approach to script/UI creation in EyeAuras. This should be the simplest one for those who only recently started coding - yes, some boilerplate code is requires to get things started, but after that it is very easy to understand. And ChatGPT can greatly help you.

Finally, it is possible to create truly 1-script mini-apps that incapsulate both UI and automation logic.

Bugfixes/Improvements

• None that time

Bugfixes/Improvements

• [Scripting] Memory reading APIs are now case-insensitive by default
• [Scripting] Memory reading APIs - Added ReadManaged<T> which is slower than Read<T>, but respects MarshalAs and managed structures
• [Scripting] Memory reading APIs are now supporting both x86 and x64 as targets. Keep in mind that your own process is x64 anyways.
• [UI] Fixed a problem with new Folder Editor selection
• [Crash] Fixed nasty crash in a new Folder editor

DMA-integration improvements

EyeAuras uses LeechCore, which is a fantastic library developed by Ulf Frisk, to integrate with DMA-devices out there. De-facto, LeechCore is a standard with which most devices out there are compatible.

For now, that integration is still in alpha-stage, drop me a message if you want to help with testing and are interested in developing something. Realistically, development using FPGA-board does not differ in any way from using ReadProcessMemory - EyeAuras abstracts you from all the complexities of managing LC API, reconnects, error handling, etc. All you have to focus on is writing a code.

Added more info here

Bugfixes/Improvements

• [Scripting] Fixed a problem with FPGA-plate not being properly released upon script disposal

Enabling conditions changes

Made it so only a subset of all Triggers is not available for selection as Enabling Conditions. Yes, that removes some flexibility from the system, e.g. you no longer can use Image analysis triggers. But. This also makes the system a bit simpler to understand, especially for new users.

Enabling conditions always meant to be global On/Off switches. If you want something more dynamic - use Trees/Macros or Auras with Triggers in them.

Folder properties editor rework

I continue to rework existing EA components 1-by-1 to leverage new UI framework capabilities. Newer version of folder properties editor not only loads faster, but is also more flexible.

Legacy version

New version. For the first revision I just wanted to reach feature-parity with existing functionality.

Default properties in Trees/Macros

Made it so you can set Target Window/Input Simulator for each tree/macro separately. Keep in mind that they also respect the normal properties hierarchy. E.g. if you set Target Window on a folder, in which Tree is located, it will respect that. But will also allow you to override that by setting another value on the tree itself.

Bugfixes/Improvements

• Nothing in this version

Bugfixes/Improvements

• [Scripting] Fixed Export to .csproj
• [UI] Fixed crash which in some cases occured during resizing
• [UI] Improved script cancellation logging - show now print the reason why user script got cancelled, e.g. because of Main window activation

Переход на .NET 8

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

.NET 8 — не самая новая версия (превью .NET 10 уже существует), но обновление платформы не делают «просто потому что можно» — для этого нужна конкретная причина. Я выбрал именно .NET 8 (а не .NET 9/.NET 10), потому что только для этой версии есть прототип нового механизма управления памятью, который, судя по текущим тестам, буквально превосходит всё, что у нас было в .NET с самого начала его существования.

Вот одна из ключевых характеристик этого нового механизма по сравнению с тем, что используется сейчас (workstation-sustainedlowlatency). По сути, это длительность тех самых «подвисаний», которые иногда случаются и в худших случаях становятся заметны пользователю.

Память vs CPU

При разработке систем почти всегда приходится искать компромисс: можно тратить меньше CPU, но ценой дополнительной памяти, или экономить память, но увеличивать нагрузку на процессор. EyeAuras почти всегда выбирал первый вариант — память дешёвая, а процессорное время на обычных пользовательских ПК дорогое (это, разумеется, моё личное мнение).

Но у такого подхода есть и обратная сторона: любые улучшения в самой основе системы управления памятью должны особенно сильно влиять на EyeAuras. И этот новый механизм выглядит для нас очень подходящим вариантом. Посмотрим, как всё пойдёт, но в ближайшем будущем я ожидаю заметный прирост производительности.

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

• [Scripting] Добавлен прототип ScriptContainerExtension — позже будет отдельная статья. Пока это alpha-стадия.

C# Scripts — Advanced — Referencing Scripts from BT/Macros

This feature lets you link another aura from a BT/macro if that aura contains a C# Script action. In programming terms, this is similar to referencing another project.
All classes and types defined in that script then become available for use in the BT.

The reference mechanism has technically existed for several months, but until now it was mostly hidden because it was incomplete and did not work the way I wanted.

Why use this?

You can now create a C# class that analyzes the game—through computer vision triggers or by reading memory directly—and provides the data your BehaviorTree needs to make decisions.
Instead of cluttering the tree with dozens of variables and checks, you can create a single class, for example TheGame, that encapsulates all data collection.

Bot example

This bot uses exactly the approach described below. It understands its environment, its own stats and the stats of nearby monsters, can build an action plan, and so on.
So far, the only limitation I’ve run into with this approach is my own ceiling.

Aura with the script inside

Let’s look at the "Shared" aura and its files.

TheGame.cs

public sealed class TheGame {
    public TheGame(IFluentLog log){
        Log = log;
    }

    public IFluentLog Log {get;}

    public int IntValue { get; private set; }

    public void Refresh()
    {
        IntValue++; // в реальности здесь может быть чтение из памяти или обновление триггеров
        Log.Info($"Refreshed the state, value: {IntValue}");
    }
}

This class prepares everything needed by the logic: trigger initialization, memory reads, OSD creation—whatever is required.
When Refresh is called, the state is updated.

Script.csx

[Inject] IAuraTreeScriptingApi AuraTree {get; init;}

Log.Info("Bot is being started!");

var tree = AuraTree.GetBehaviorTreeByPath("./New tree");
var game = GetService<TheGame>();
tree["TheGame"] = game;

This is how the TheGame object is passed into the BT through variables.
This is the key part that was missing before. Objects passed through variables are now fully available, without restrictions.

Behavior Tree

Example tree structure:

Updating data

var game = Variables.Get<CheatCrescendo.TheGame>("TheGame").Value;
game.Refresh();

In this node, we call Refresh, which updates the game state. By this point, the "TheGame" variable has already been initialized—either by the script or by another node.

Rendering OSD

return Run();

public IEnumerator<NodeStatus> Run(){
    using var osd = GetService<IOnScreenCanvasScriptingApi>().Create();

    var game = Variables.Get<CheatCrescendo.TheGame>("TheGame").Value;

    var textOsd = osd.AddHtmlObject();
    while (!cancellationToken.IsCancellationRequested){
        textOsd.Html = $"{game.IntValue}";
        yield return NodeStatus.Success;
    }
}

This is an example of creating an OSD that displays the current IntValue. It uses the new IEnumerator<NodeStatus> capability, which lets you split a node’s lifecycle into stages. On the first run, the OSD is created; after that, it is simply updated.

Game logic

Under the selector, you can place as many nodes as you want that check the current state.
All you need to do is access TheGame and call its methods.

For example, want to read HP directly from memory? Add a method to TheGame and call it from a BT node.
Need a color check via ColorSearch? Same idea.
Even movement between locations can be moved into a method: open a portal, select an option, click—everything lives in TheGame, and the BT just makes one call.

Performance

A number of performance-related improvements were added. If you notice any issues, please report them.

Fixes / Improvements

• [Behavior Trees] Prototype of parallel node loading — should speed up loading for large trees
• [Scripting] The PoeShared.Blazor.Controls namespace, which contains UI controls, is now available in scripts by default

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

• [Behavior Trees] Исправлен вылет при использовании PopOut
• [Behavior Trees] Исправлена проблема, из-за которой узлы Action не вызывали связанные дочерние узлы
• [Behavior Trees] Исправлена некорректная работа "Toggle Nodes"
• [UI] Улучшено изменение размера и перетаскивание — интерфейс должен ощущаться немного более отзывчивым
• [DMA] Изменён порядок загрузки DLL — это должно исправить проблему, из-за которой LeechCore на некоторых ОС/ПК инициализировался некорректно

Behavior Trees - Action Nodes now have outputs

All action nodes (Wait, MouseMove, KeyPres, etc. - all of them) now have Outputs as well. Logic is exactly the same as it was with other nodes - linked node gets executed only if current node succeeded.

Bugfixes/Improvements

• [Behavior Trees] Fixed a bug - CTRL+A sometimes selected more than it should've

Performance - Macros UI optimizations

Done some major changes in how Macros are rendered, the overall UX should be better. Please, report any inconsistentices you may notice. There will be more changes in the following weeks, trying to address initial (first) rendering performance.

C# Scripting - Razor namespaces declaration

Probably it will be easier to show, lets take, for example a very basic Razor component created via :

That is what we get as a result

UserComponent.razor

@namespace GameGrind
@inherits BlazorReactiveComponent
<!-- your Razor/HTML markup here -->

UserComponent.cs

namespace GameGrind;

public partial class UserComponent : BlazorReactiveComponent {
    //some code here
}

Note that random namespace (GameGrind, in this case) which previously was automatically inserted whenever you added a new Razor Component. This is minor, but very inconvenient technical requirement that the scripting system had. One of such inconveniences would be the fact that such code could not be easily copy-pasted to another EyeAuras script - you either had to change the namespace OR had to deal with the fact that you have multiple different non-related namespaces in your code. None of those are good thing to have. From now on, namespace declaration is not a requirement anymore - you can omit namespace declaration in BOTH .razor and .cs files and EyeAuras will automatically insert them during compilation. Less code = less headache = better life.

Bugfixes/Improvements

• [Overlays] Changed how overlay is rendered on the screen (Hide/Show order during startup) - should make things appear on the screen a bit faster
• [UI] Improved responsiveness of drag'n'drop in Macros/BTs
• [Macros] Fixed a problem with Repeat/IfThenElse - drag'n'drop was not working properly
• [Macros] Fixed a problem with Cloning - from now, the entire hierarchy will be preserved and not only the selected node