Большая часть изменений за последние 3 месяца была посвящена скриптингу. Добавлена новая подсистема диалоговых окон и оверлеев - Blazor Windows, крупные улучшения в интеграции NuGet-пакетов и внешних сборок, улучшения редактора и, наконец, появились экспорт и «Live Import», позволяющие использовать EA и любимую IDE одновременно.
Прикладывать 600+ МБ исполняемый файл к 200КБ скриптам выглядит странновато, особенно если учесть, что со временем вы сами сможете публиковать лицензированный контент. Пугать новых пользователей UI со сотней кнопок/галочек и слайдеров, мягко говоря, не хочется. Плюс добавочный «груз», который таскает программа. В 2025 основная цель – реализовать систему, которая будет автоматически отключать те части интерфейса, что не используются. Например, авторам скриптов позволять прятать UI EyeAuras, отключать компьютерное зрение или модули ML и т.д. Технических моментов тут много, но все они решаемы. Посмотрим, как пойдут дела в ближайшем будущем.
DMA-карты – это небольшие устройства, позволяющие считывать память ПК напрямую, без участия операционной системы, посредством прямого взаимодействия железа. Выявить такое чтение крайне сложно, что дает высокий уровень безопасности для конечного пользователя. Memory API, добавленное в ноябре, призвано унифицировать работу с оперативной памятью (через ReadProcessMemory), через драйверы и, со временем, через DMA-карты. Вы можете спокойно разрабатывать всё через привычный RPM, а затем переключиться на DMA, если нужен более безопасный вариант. Смена одной строчки кода – и пользователь сам решит, какой уровень защиты ему нужен.
В 2024 она улучшилась благодаря новому UI-фреймворку, который вытеснил старый на большей части приложения, но впереди еще много работы, особенно при большом количестве аур (500+). В 2025 основной упор будет на максимально быстрое чтение/загрузку «Pack»-паков, ведь именно через них люди в основном распространяют скрипты. Возможно, появится облегченный вариант UI без обилия функций, который будет запускаться быстрее и работать эффективнее.
Теперь, когда вы скачиваете «пак» с сайта — например, бота для рыбалки в Throne&Liberty(1 или 2), Path of Exile Helper или что-то другое — стало намного проще отслеживать, когда автор выложит новую версию. Теперь вы получите уведомление прямо в паке — пока это всего лишь небольшой бейдж у названия папки, но возможно, в будущем добавлю какой-то иной вид уведомления.
Но просто получать обновления — это лишь часть дела. Зачастую, если вы пользуетесь чьим-то паком, вы меняете там что-то под себя: свои хоткеи, названия окон, картинки и т.д. Теперь вы не потеряете все эти настройки, если автор выпустит новую версию. EyeAuras возьмет ваши локальные правки, сравнит их с правками автора (удалённые) и сольет вместе. Идеальный сценарий — вы получаете все обновления автора, сохранив свои изменения. Сейчас этот механизм довольно новый, могут быть ошибки, но теперь, когда он уже живой, все баги будут быстрее найдены (и исправлены).
В идеале, вы вообще не должны задумываться о работе этой системы. Посмотрим, как пойдет :-D
Паки делают люди, а людям свойственно ошибаться. Все изменения, которые вносят авторы, версионируются и хранятся как ревизии. Сейчас вы можете откатить свои локальные изменения только до последней ревизии — это то же самое, что переустановить весь пак, но в 1000 раз быстрее. Когда механизм станет более отполирован, появится возможность переключаться на другие ревизии.
В другой вкладке можно увидеть содержимое пака, не скачивая его. Посмотреть хоткеи, общую логику, структуру. В будущем планируется возможность просмотра кода и Behavior Trees/Макросов прямо в этом же окне.
И последняя вкладка — это своего рода «Лог активности», где можно узнать, что поменялось, каков статус синхронизации и всё в этом духе.
Появилась новая функция — теперь можно задать диапазон «Similarity», при котором триггер будет активен. По умолчанию триггер срабатывает, если Similarity выше заданного порога:
Теперь можно задать диапазон Min/Max значений для Similarity:
В таком случае, даже если Similarity дойдет до 100%, триггер все равно будет неактивным, потому что ожидаемое значение — в пределах 55.95 – 62.94
(включительно).
Добавлен простой способ рандомизировать X/Y. Вместе с «Input Smoothing» это должно сделать ввод более «человеческим».
Добавлена функция Version History, позволяющая просматривать и управлять снимками (snapshots) конфигурации, сохраненными во времени. Теперь можно сделать Soft Reset, чтобы вернуть состояние файлов без удаления истории, или Hard Reset, чтобы полностью откатиться к выбранному коммиту и убрать все изменения, сделанные после.
p.s. Русская версия доки доступна здесь
Window Selector – это тот контрол, который позволяет выбрать/указать целевое окно. Много лет он автоматически исключал все окна, которые принадлежат EA.
Теперь это опционально и может быть отключено, если в выражении добавить [ownedBy=any]
, например:
My Window [ownedBy=any]
Это убирает фильтр и показывает все окна в системе, даже те, что созданы EyeAuras.
Похожий новый фильтр позволяет учитывать так называемые «Tool windows» (часто это оверлеи). По умолчанию они не отображаются. Но, если дописать [type=any]
, они тоже будут кандидатами:
My Overlay [ownedBy=any][type=any]
В таком случае перехватываем любые окна/оверлеи с заголовком My Overlay
.
Хочу напомнить о функции, добавленной довольно давно, но полезной в специфических случаях — например, если нужно определить цвет или картинку быстропропадающего баффа/дебаффа. За последнее время в нее было внесено несколько улучшений.
Просто нажимаете «Replay» — программа начинает записывать видимое изображение во временный видеофайл.
Когда закончили — жмете «Stop»
Окно предпросмотра переключается в режим, где данные берутся из записанного видео. Можно работать с этой «записью» так же, как если бы это была живая картинка — пипетка для пикселей, копирование регионов в буфер, и т.п. Когда закончите, просто переключитесь на Image as is
в правом нижнем углу.
Новый крупный функционал в стадии альфа: теперь можно экспортировать 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».
Нужно выбрать .sln
и EA начнет мониторить все изменения в папке с проектом. Как только что-то изменилось, EA тут же импортирует это обратно. По сути, код в C#-скрипте/оверлее становится «живым». Это особенно заметно для Overlays
, которые тут же пересобираются при каждом изменении. Сделали правку в IDE — и EA почти мгновенно подхватил ее, пересобрал и загрузил. Это что-то вроде «колхозного Hot Reload» от Microsoft, но оно работает.
Git — золотой стандарт систем контроля версий. Внутри EA он уже используется (например, для версии настроек). Поэтому при экспорте проектов автоматически создается git-репозиторий, или, если он уже был, делаются коммиты изменений. Это упрощает откат кода, если вдруг что-то пошло не так.
На данный момент нельзя запустить проект прямо из IDE или отлаживаться в привычном режиме. Это планируется исправить в 2025. В идеале EA будет работать как рантайм для скриптов. Но тут еще предстоит много доработок.
Серьезное расширение механизма скриптов — теперь он умеет компилировать 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 там не было, потому что требовалось доделать кучу других систем. Сегодня мы имеем первый прототип — можно создавать свои окна прямо в коде.
Добавлен новый тип Overlay, который использует последнюю версию движка скриптов EyeAuras (ту же, что и в C# Actions/Triggers/BehaviorTrees). Пока что старый C# оверлей и новый будут сосуществовать. Когда выйдет окончательная версия с поддержкой экспорта/импорта, старый, видимо, уйдет в прошлое, так как во всем проигрывает новому — в производительности, гибкости и т.д.
Помимо нового движка скриптов, оверлей v3 использует упомянутые Blazor окна, что делает оверлеи более отзывчивыми и приятными в работе.
ВНИМАНИЕ! Оверлей пока сырой — впереди много мелких (и не очень) доработок.
Редактор C# Script Action (пока только для Action, в BT/Triggers/Overlays все по-старому) получил кое-какие улучшения:
Это метод поиска определенных байтовых последовательностей в памяти. Он полезен для поиска функций, данных или кода, которые не всегда загружаются по одному и тому же адресу при работе программы.
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"));
Byte Arrays:
var pattern = BytePattern.FromPattern(new byte[] {0x55, 0x8B, 0xEC});
Сопоставляет ровно эти байты.
C-Style Patterns:
\xAA\xBB\xCC
.var pattern = BytePattern.FromTemplate("\x55\x8B\xEC");
Эквивалентно массиву байтов [0x55, 0x8B, 0xEC]
.
Hexadecimal Strings с Wildcards:
??
в качестве любого байта.var pattern = BytePattern.FromTemplate("55 8B ?? 83");
Ищет любой участок, начинающийся на 55 8B
, затем один байт, потом 83
.
Masked Patterns:
x
— «фиксированный байт», ?
— «любой байт».var pattern = BytePattern.FromMaskedPattern(new byte[] { 0x55, 0x8B, 0xEC, 0x00, 0x08 }, "xxx??");
Ищет 55 8B EC
, а затем любые два байта.Templates с оффсетом:
^
, чтобы указать смещение.var pattern = BytePattern.FromTemplate("55 8B ?? ^ EC 00");
Ставит итоговый смещение непосредственно перед EC
(пропуская 3 байта). То есть после нахождения паттерна итоговый адрес будет Offset + 3
.
Уже несколько месяцев в скриптах есть возможность подключать 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
Этот способ позволяет подключать сборки, которые:
Assembly.Load
или другим способом и уже есть в AssemblyLoadContext/AppDomainИсторически в 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 и способного использовать все возможности — компьютерное зрение, нейросети, чтение памяти, эмуляцию ввода и т.д.
Добавлено полезное свойство NoActivate
, которое делает так, что окно реагирует на клики мышью, но не перехватывает фокус.
Это значит, что вы можете сделать оверлей с разными элементами управления, при этом активным останется игровое окно, и пользователь легко будет вносить изменения прямо поверх игры.
В 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")));
Разумеется, данные можно и сгенерировать в реальном времени.
Главный упор — исправлены проблемы с авто-аннотацией и обеспечена корректная работа Google Collab. Скоро будет видео на эту тему. Также улучшена производительность, особенно на средних и больших датасетах (5–10 тысяч изображений).
При «Local Training» модель обучается на вашем «железе». Плюс — вы платите только за электроэнергию, минус — нужно все настроить самостоятельно.
При использовании Google Collab обучение идет в облаке — реальный процесс запущен на серверах. Вы можете выбирать бесплатный режим или платный, как удобнее.
Mostly hotfixes of NY release.
IEyeContext
- should fix a problem with older overlays not working properlyMemoryOfModule
(which accept module name OR module descriptor) to IProcess
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; }
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 additionInMemoryFileProvider
- allows to store file data in-memory, files will be cached for better performanceInMemoryFileInfo
- allows to create one in-memory file reference. The data is loaded as soon as FileInfo is constructedLazyInMemoryFileInfo
- allows to create lazy file reference, which will be loaded only when accessedwhich 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.
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.
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
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.
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.
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.
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).
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
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.
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.
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
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 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.
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.
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.
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.
ScriptingAPIs
, this would correspondingly lead to disposal of OSD/Windows/etc created by scriptAdded simple way of randomizing XY. Together with Input Smoothing, this should make inputs appear more humane.
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 EAFor 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#
Syntax is very similar.
#r "assemblyPath: D:\Work\EAExile\EAExileAgent.Shared.dll"
Log.Info("Hello, World!"); //you can use EAExileAgent classes in that script
This method of referencing assemblies allows you to reference those assemblies which are either:
Assembly.Load
or via any other means, but they are already part of AssemblyLoadContext/AppDomainHistorically, 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
Pattern scanning is a method used to search for specific byte sequences in memory. It’s useful for finding functions, data, or code that doesn’t always stay at the same location when a program is running.
BytePattern
The BytePattern
class has been added to support multiple ways of defining patterns. These updates make it easier to work with different types of patterns commonly used in scanning memory.
Pattern scanning is available on any type implementing IMemory
interface, e.g.
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"));
Byte Arrays:
var pattern = BytePattern.FromPattern(new byte[] {0x55, 0x8B, 0xEC});
matches exactly those bytes.
C-Style Patterns:
\xAA\xBB\xCC
, like in C-Style patterns.var pattern = BytePattern.FromTemplate("\x55\x8B\xEC");
is equivalent to the byte array [0x55, 0x8B, 0xEC]
.
Hexadecimal Strings with Wildcards:
??
for wildcards (any byte).var pattern = BytePattern.FromTemplate("55 8B ?? 83");
matches any sequence starting with 55 8B
, followed by any byte, and then 83
.
Masked Patterns:
x
) and which are wildcards (?
).var bytes = ;
var mask = ;
var pattern = BytePattern.FromMaskedPattern(new byte[] { 0x55, 0x8B, 0xEC, 0x00, 0x08 }, "xxx??");
Matches any sequence starting with 55 8B EC
, followed by any two bytes.Templates with Offsets:
^
.var pattern = BytePattern.FromTemplate("55 8B ?? ^ EC 00");
sets the offset right before EC
(skipping 3
bytes). That means after the pattern is found, final offset will be Offset + 3