Бот на Memory API с интерфейсом ImGui

Поле	Значение
Сложность	Высокая
Пример	Игровой бот в стиле BankaBot с живой панелью управления на ImGui.
Конечная цель	Собрать бота, который читает данные из другого процесса, показывает статус и элементы управления в ImGui и при необходимости позволяет пользователям добавлять свои скрипты.
Ключевые технологии	Memory API, ImGui SDK, встроенные скрипты, выбор окна и процесса

Когда использовать

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

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

Начните с двух входов: выбранного IProcess с известным layout цели и скриптового контейнера EyeAuras с подключённым EyeAuras.ImGuiSdk. До получения IImGuiExperimentalApi добавьте ImGuiContainerExtensions. Для обычного app/plugin-класса оба объекта передаёт композиция хоста; GetService и cancellationToken не являются глобальными C# API.

В цикле чтения получите значения через process.Memory.Read<T>(absoluteAddress), соберите неизменяемый снимок с PID, временем и статусом и атомарно опубликуйте ссылку на него. Render callback AddRenderer берёт только эту ссылку, рисует поля и записывает команды пользователя в состояние, которое обработает рабочий цикл. Он не ищет модуль и не читает память каждый кадр. Кнопка остановки меняет состояние владельца; закрытие окна само по себе не обязано остановить бота.

Результат — панель продолжает обновляться, даже если очередное чтение задержалось; пользователь видит возраст снимка и ошибку подключения. На завершении владелец останавливает цикл и дожидается его выхода, снимает renderer, закрывает принадлежащие ему окна и освобождает reader и API. Полный пример времени жизни renderer.

В EyeAuras 20fd3d4 экземпляры ImGui API арендуют общий overlay Main. FPS, VSync, шрифты и изображения не изолированы по запуску; ReplaceFont меняет общий шрифт по умолчанию. ImGuiWindowManager статический: закрывайте своё окно через Close(window), не чужие через CloseAll(). Подписка AddRenderer требует отдельного Dispose; получение API из DI не заменяет этот шаг. Пользовательские скрипты, если они нужны, запускаются в отдельном явно настроенном sandbox с разрешёнными зависимостями, а не наследуют произвольные сервисы панели.

Общая схема

• Используйте сервисы Memory API для чтения процесса.
• Держите чтение памяти и данные бота отдельно от кода рендера ImGui.
• Используйте ImGui как основной интерфейс бота, который всегда открыт.
• Выносите тяжёлые редакторы и длинные формы в окна Blazor только если в ImGui становится тесно.
• Добавляйте встроенные скрипты только тогда, когда пользователям действительно нужна настройка поведения во время работы бота.

Что нужно решить заранее

• Какой backend Memory API будет поддерживать бот.
• Как пользователь будет выбирать окно игры или процесс.
• Где будет жить логика бота — в C# сервисах, Behavior Trees, aura actions или пользовательских скриптах.
• Будет ли интерфейс только на ImGui или на ImGui с дополнительными окнами-редакторами на Blazor.

Какие API посмотреть

• ScriptContainerExtension
• IWindowHandle
• IWindowSelector
• IWindowHandleProvider
• IProcess
• IImGuiExperimentalApi
• ICanBeDisplayedInImGui
• IImGuiWindowContent
• ImGuiWindowManager
• AuraScriptRunner<TSandbox>
• AuraScriptSandbox

Чего избегать

• Чтения памяти напрямую внутри render-кода.
• Собственной системы скриптов, если пользователям на самом деле не нужны runtime-расширения.
• Смешивания данных из разных подключений к процессу.
• Предположения, что ImGui встроен по умолчанию — он поставляется отдельным SDK-пакетом.
• Сохранения volatile handle-объектов и живых объектов процесса.

Что ещё почитать

• nuget/imgui-sdk.md
• memory/processes.md
• nuget/frida-sdk.md
• windows-subsystems/window-handles.md
• scripting/runtime.md
• core/deployment.md