C# Scripting - Export/Import and Live Import are in public alpha

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.

How is it useful ?

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

Export

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/Import

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.

Live Import

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.

Integration with .git

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.

Debugging

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.

Bugfixes/Improvements

• [UI] Minor changes for the first start - event log panel is larger, Macro gets created instead of an aura
• [Scripting] Fixed a bug which lead to premature disposal of ScriptingAPIs, this would correspondingly lead to disposal of OSD/Windows/etc created by script

Bugfixes/Improvements

• [Scripting] Changed how buttons behave when editor gets resized - now it is much easier to have small floating panel with the script somewhere on the screen, while you're editing the code in IDE
• [Scripting] Editor performance tweaked - should switch between files faster
• [Scripting] Added Restart button which... well, restarts the script. More convenient than stop-starting every time. Keep in mind that this is NOT needed in C# Overlays - they operate in always-live mode by default.

MouseMove - added Random offset

Added simple way of randomizing XY. Together with Input Smoothing, this should make inputs appear more humane.

Bugfixes/Improvements

• [UI] Added two new actions - 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 EA
• [Scripting] Changed how assemblies are loaded - fixes a problem with transitive dependencies
• [Scripting] Exposed IPerformanceMetricsAddon - could be used to track performance of the app via scripting
• [Scripting] Changed script compilation order - fixes a problem with Razor sometimes not being compiled correctly

C# Scripting - added ability to reference assemblies by path/name

For 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#

By assembly path - from file

Syntax is very similar.

#r "assemblyPath: D:\Work\EAExile\EAExileAgent.Shared.dll"

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

By assembly name

This method of referencing assemblies allows you to reference those assemblies which are either:

• already loaded by EyeAuras, but have not been included into default referenced assemblies list
• were loaded using Assembly.Load or via any other means, but they are already part of AssemblyLoadContext/AppDomain
• are in GAC

Historically, 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

Bugfixes/Improvements

• [Scripting] Fixed a problem with CancellationToken rewriter - it was handling optional arguments incorrectly in some cases

C# Scripting - added pattern scanning

What is Pattern Scanning?

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.

Why is it Needed?

1. Dynamic Locations: Programs often load code and data into different places each time they run. Pattern scanning helps find what you’re looking for, no matter where it ends up.
2. Unique Matches: Patterns are like fingerprints—they help identify specific areas in memory based on unique byte sequences.

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")); 

Supported Pattern Types

1. Byte Arrays:

   • Define patterns using exact byte values.
   • Example:

   var pattern = BytePattern.FromPattern(new byte[] {0x55, 0x8B, 0xEC});
   

   matches exactly those bytes.

2. C-Style Patterns:

   • Use escape sequences like \xAA\xBB\xCC, like in C-Style patterns.
   • Example:

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

   is equivalent to the byte array [0x55, 0x8B, 0xEC].

3. Hexadecimal Strings with Wildcards:

   • Define patterns as hex strings with ?? for wildcards (any byte).
   • Example:

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

   matches any sequence starting with 55 8B, followed by any byte, and then 83.

4. Masked Patterns:

   • Combine a byte array with a mask to specify which bytes are fixed (x) and which are wildcards (?).
   • Example:

     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.

5. Templates with Offsets:

   • Define patterns using a template and mark the match offset with ^.
   • Example:

   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

Bugfixes/Improvements

• [UI] Minor layout fix in popped-out C# editor

Script editor improvements

C# Script Action editor (only Action for now, editor in BTs/Triggers/Overlays is still the same) got some love:

• should popout much faster, usually takes ~1 second
• added Topmost button which could be used to make it so code editor will stay on top of other windows - very useful when editing something in real-time
• now popped out editor has EventLog similar to one that main app window has, but that log will contain only messages generated by the script. Should be easier to debug things
• fixed few bugs here and there

Bugfixes/Improvements

• [UI] Fixed a problem with C# Action being cancelled in some cases even if Ignore Cancellation is set.

Bugfixes/Improvements

• [Scripting] Fixed a problem with new/removed files not always being displayed in UI
• [BehaviorTrees] BT improvements - made it so empty BT does not throw
• [BehaviorTrees] Added new bindings to KeyPress and MouseMoveRel nodes
• [Scripting] Fixed a problem with INotifyPropertyChanged implementation in scripting
• [UI] Improvement in Bindings Editor - if binding fails, error will be shown
• [UI] Fixed a problem with bindings BT-to-BT not working properly

C# Scripting - sneak peek into live import

You may have noticed that for the last 3-4 weeks number of changes has been lower than usual. The primary reason is me focusing on a new feature - live import in C# scripts, which will allow you to use full-blown IDEs such as Visual Studio and Rider for editing scripts. For smaller scripts this is not that important, but for larger projects it is hard to overestimate quality of life that IDEs bring to the table.

In one of the following weeks this will be available for public testing, need some time to polish things. Also, as a part of scripting subsystem improvements, there were some changes done in the engine, which now allow you to use NuGets which rely on native libraries, such as ImGui - a lot of programmers out there have experience with it an now you can leverage that knowledge and create ImGui overlays straight from the code.

This is an example of a live clickable ImGui overlay, which can contain any kind of data you want, running inside EA and being able to leverage any functionality - computer vision, neural networks, memory read, input emulation - anything.

Bugfixes/Improvements

• [UI] Fixed a problem with items in AuraTree sometimes not reacting to selection

Color Search - added Similarity Range selection

Added new feature - now you can specify Similarity range which is required for trigger to be Active. By default, trigger is active only if Similarity is above given threshold, e.g.

Now you can specify range of Min/Max values for similarity, e.g.

In this case, even if Similarity would reach 100%, trigger still will be Inactive, because expected value must be in range 55.95 to 62.94 (inclusively)

Reminder - Replay in Capture triggers

Just want to highlight a feature that was added long time ago and is extremely useful in some niche situations, e.g. when you need to capture the color or image of some short-living buff or debuff.

You just press Replay, the program starts saving the footage into temporary video file.

When done, just press Stop

Preview window will now switch to mode which loads image data from the video file. You can now work with that footage just like if that would be the real captured image - pick pixels, copy regions to clipboard, etc. When no longer needed, just switch to default Image as is option in bottom right corner.

Bugfixes/Improvements

• [Capture] In effects and in Color Search fixed a problem with Color picker not working correctly with Replay

Early-early prototype - C# Overlay v3

Added new type of Overlay, which uses the latest version of EyeAuras scripting engine - same one, that is used in C# Actions/Triggers and BehaviorTrees. For the next few weeks old C# overlay and new one wil co-exist. As soon as I will releat Export/Import functionality, old one will go away as it is worse in everything - performance, flexibility, etc.

Aside from scripting engine changes, this new overlay is using recently added Blazor Windows, which should make overlays more responsive and just in general more pleasant to work/interact with.

IMPORTANT! The overlay is far from being completed - there are still a lot of rough edges which I will work on in the following weeks.

Bugfixes/Improvements

• [UI] Fixed minor bug in authentication