Usb2Kbd is hardware input emulator. It has been supported by EyeAuras since ~2021.
Now you can create your own for approximately 5$
- the only thing that is needed is small device from AliExpress/Amazon.
Here is the detailed step-by-step guide (russian / english).
I've also improved technical part and reworked settings window for better user experience.
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.
ReadManaged<T>
which is slower than Read<T>
, but respects MarshalAs
and managed structuresEyeAuras 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
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.
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.
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.
.NET is a platform upon which EyeAuras is built. It affects all the tiny bits - startup, memory allocation, data management, literally every small bit of the program is affected by this change.
NET8 is not the latest version (there is already a preview of .NET 10), but platform upgrade is not something you do "just because", there must be a reason. I've picked .NET8 (and not .NET9/.NET10) because only for that specific version there is a prototype of a new memory management mechanism, which, from the current tests, just blows out of the water literally everything else that we had in .NET since its inception.
That is one of the primary characteristics of this new mechanism in comparison to what we have now ("workstation-sustainedlowlatency"). Basically this is the duration of those "hiccups" which tend to happen and are in worst cases become noticeable.
Traditionally, there is always a tradeoff when you're developing a system - you can spend less CPU time, but it will cost you some extra memory OR you can save some memory, but it will increase CPU consumption. EyeAuras has almost always been picking the first option - memory is cheap and cpu cycles are expensive in consumer PCs (purely my opinion). But, aligning to that strategy also means that any improvements in the very core of memory management system should affect us greatly and that memory management mechanism seems to be a perfect fit. We'll see how it goes, but I am expecting to achieve a measurable performance jump in the nearest future.
ScriptContainerExtension
prototype - there will be a separate article on this later. For now it is in alpha-stage.Эта функция позволяет вам привязать из BT/макроса другую ауру, содержащую действие C# Script
— это эквивалентно тому, как если бы вы «ссылались» на другой проект в программировании.
Все классы и типы, определённые в этом скрипте, станут доступны для использования в BT.
Механизм ссылок существует уже несколько месяцев, но ранее он был «спрятан» от глаз, так как был неполноценным и не работал так, как мне хотелось.
Теперь вы можете создать класс C#, который будет анализировать игру — через триггеры компьютерного зрения или напрямую читая память — и предоставлять BehaviorTree
необходимые данные для принятия решений.
Вместо того чтобы загромождать дерево десятками переменных и проверок, вы просто создаёте один класс, например TheGame
, который инкапсулирует всё получение информации.
Этот бот использует именно тот подход, который описан ниже. Он знает окружение, статы свои и окружающих монстров, может строить план действий и т.п. В целом в таком подходе ограничение я пока встретил только одно - свой собственный потолок.
Посмотрим на "Shared"-ауру и её файлы.
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}");
}
}
Класс готовит всё для логики: инициализация триггеров, чтение из памяти, создание OSD — всё, что нужно.
Когда вызывается Refresh
, происходит обновление состояния.
[Inject] IAuraTreeScriptingApi AuraTree {get; init;}
Log.Info("Bot is being started!");
var tree = AuraTree.GetBehaviorTreeByPath("./New tree");
var game = GetService<TheGame>();
tree["TheGame"] = game;
Так мы передаём объект TheGame
в BT через переменные.
Это ключевая часть, которая раньше отсутствовала. Теперь передаваемые через переменные объекты доступны полностью и без ограничений.
Пример структуры дерева:
var game = Variables.Get<CheatCrescendo.TheGame>("TheGame").Value;
game.Refresh();
В этом узле вызываем Refresh
, который обновляет состояние игры. Переменная "TheGame"
к этому моменту уже инициализирована — либо скриптом, либо другой нодой.
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;
}
}
Это пример создания OSD, который визуализирует текущее значение IntValue
.
Используется новая возможность — IEnumerator<NodeStatus>
, позволяющая "разбивать" жизненный цикл ноды.
В первом запуске создаётся OSD, далее оно просто обновляется.
Под селектором можно размещать сколько угодно нод, проверяющих текущее состояние.
Всё, что нужно — обращаться к TheGame
и вызывать его методы.
Например, хотите получить HP напрямую из памяти? Напишите метод в TheGame
— вызывайте его из BT-ноды.
Нужна проверка по цвету через ColorSearch
? То же самое.
Даже движение между локациями можно вынести в метод: открыть портал, выбрать опцию, кликнуть — всё в TheGame
, один вызов из BT.
Добавлено множество улучшений, влияющих на производительность. Если заметите проблемы — сообщайте.
PoeShared.Blazor.Controls
, содержащее элементы управления, теперь доступно из скриптов по умолчанию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.