¶ C# Scripting - Pre-compilation for Packs
Major feature which opens up a lot of new possibilities. In short - from now on, when you're exporting new version of the pack(be it auction sniper or L2 helper or any other pack in the Library), you can make it so EA will pre-compile all the scripts which are part of that pack and include binaries into exported data.
Not only this saves up compilation costs for end-users, but it also makes it possible to exclude script code from exporeted project altogether!
IMPORTANT! To apply new compilation mode, first select desired mode, save settings and then
Uploadnew revision of the pack. For now, compilation is done on a client-side. Eventually, it will be shifted to server-side, like the rest of Packing configuration, but this is something for 2026.
¶ Binaries? Scripts?
I've covered this in depth here.
TL;DR; Scripts - text version of your program. Binaries - compiled program. A lot of information gets lost (intentionally) during compilation, but for .NET it is still possible to recover most of the program if you know what you're doing.
For now, EA will include "pure" binaries, without any changes done to them. This is good from performance perspective and a step towards script protection, but for a person, who knows what he is doing, it is still possible to recover text of the program using tools called decompilers.
E.g. this is how decompiled code of one of PoE2 packs looks like - for a programmer this is like an open book.
¶ Compilation modes
The new switch, available on pack configuration page, allows you to select one of three available compilation modes. They all come with pros and cons.
¶ Script only
This is the default one. Nothing changes from how it worked for years - when you're exporting something, all your script code gets exported with no strings attached and compiled on-demand on end-user PC.
Pros:
- the script could be easily edited by anyone
Cons:
- there is a compilation cost involved, which may take hundreds and, sometimes, even thousands of milliseconds, which makes the entire UX feel sluggish
- the script could be easily edited by anyone
¶ Script and binaries
Pros:
- the script could be easily edited by anyone
- no compilation cost whatsoever - when the program gets booted, everything is already compiled and ready-to-run. Compilation will occur only if you'll make some changed in the script
Cons:
- the script could be easily edited by anyone
¶ Binaries only
Pros:
- the script is no longer available. At all. It is physically never touches end-user PC
- no compilation cost whatsoever - when the program gets booted, everything is already compiled and ready-to-run. Compilation will occur only if you'll make some changed in the script
- it is possible to protect your code and make it harder for anyone to steal your intellectual property
Cons:
- the script is no longer editable by end-user. Instead of script code there will be some read-only technical info.
¶ What is next?
More protective layers.
As soon as current functionality will be stabilized, I will add another feature, which will allow you to automatically obfuscate your code. With a good obfuscator, it is immensely hard to restore the program to its initial ("pure") state.
For comparison, this is that same script which I've shown above, but obfuscated - as you can see, it is barely readable due to all tricks applied to the code. Restoring it to initial state, even having the binary, is a very complex task.
For you, EA users, this will be just an additional checkbox. For EA this will be a major new compilation pipeline involving a whole bunch of services and tools.
Eventually, there will be even more protective layers added on top of obfuscation, such as native compilation and virtualization. I will share more details later this year.
¶ Bugfixes/Improvements
- [SendSequence] Fixed a problem with SendSequences - under some conditions sequences of key presses could be interrupted prematurely, meaning that only part of the sequence would be sent. Thanks to
@Rowenorfor finding this out! - [Macros] Made it so Comment node no longer throws exception when executed - this defeated the whole purpose of having that node in the tree