https://www.youtube.com/watch?v=tmVgXGKWTIM

How was the eud sanc 2 made has bugged me for a long time now. I have an idea about how it was made, and recreated a few time locked maps myself using HAT. It was python based stuff and hardly releasable, so I decided to make this. It's only alpha (and will be for a long time now) and probably full of bugs that I didn't even consider testing.

The user interface is simple:

You load settings (that contain a session data, everything you set can be saved in that), and a map. Then everything becomes editable and you can mess with settings, add sounds (original from EUD Sanctuary 2, from your own map, or any sound file from your computer). You can also tweak your map and add touch revive, sanctuary colors or leaderboard.

You can leave those unchecked if you have these things in your map already (like if your map handles kill sounds, leave gunshot unchecked).

To use barrier, you must perform units recalculation. This is done automatically by the library, and you can adjust the values additionally.


Hyper triggers are stripped, you can replace map name, map description and set initial mission objectives, all in one place (korean friendly).



There are numerous limitations for using this tool:

• STR if f**ked up and you can only have like 5kb of your own string data (should be enough for no very talkative maps)
  
• UPRP is f**ked up (this is a work on progress). Using triggers like "Create units with properties" will lead to either broken units or worse.
  
• LOC is f**ked up (you can only use like 200 locations instead of full 255)
  
• You will probably need to use additional compressor to deflate the final map file (work in progress as well)
  
• Time lock triggers crash after map expires? (A feature)
  
• If you used EUD Editor to alter any aspect of the map, you should expect undefined behavior (by this tool and even sc)
  
• EPD Editor is fine though. EMP is parasite, so you can even mod it further with it
  
• Touch revive is ore based, any map that utilizes ore will break it
  
• Background music cannot be turned off?
  
• Hyper triggers break the EUD part. Before using the tool, remove all hyper triggers
  
• Slot 7 must be a computer slot (has the EUD stuff). Slot 8 doesn't get abilities (work in progress)
  
• Condition "Elapsed time is at least 3 seconds" will be added to all your triggers, so if there is a trigger with 16 conditions, expect a crash
  

This tool is highly experimental, and you should always have a backup of your map before using it. If you find a bug, please report it here.
Source files are located here.

Attachments:

Post has been edited 25 time(s), last time on Aug 15 2019, 10:05 am by T-warp.

Fixed anywhere remapping and triggers not being made. Also (kind) figured barrier (how to disable it)

Fixed a lot of stuff, including: Propert locations remapping, unit properties remapping, added support for barrier recalculation and stuff

Alpha 3 now supports additional unit settings recalculation! It's known to crash for units not present in game

Sorry for stupid question, but I couldn't figure it out from the video. What barrier and visor do?

Visor is something like auto-attack. It basically unallies computer so your unit shoots on its own. It lasts for a few seconds. Barrier restores health to 12 and adds short term shield.

Fixed unit names in alpha 4. I wonder how many times I have used those incorrect ones before.

There is also some kind of a jump-over-the-wall @9:57 when he clicks the "landing" button

You can teleport into some types of walls (not solid walls).

I solved the team kill issue. Simply add armor to ghost and set enemy weapons to ignore armor. If the map has enemy ghosts, add weapon bonus to high number and their upgrade level to 1.

There are different aporaches, each of them is not without a drawback. This is another quite interesting way to solve the problem. The price is players can't have meaningful custom armor upgrades, since enemies bypass armor anyway.

Finally fixed locations relocations. There are many ways to do it, I chose the only that required the least work inside the map editor. I can't possibly go through every single unit and recalculate damage to take armor in account.

Just updated (fixed STR partially -up to 7200 bytes can be used. Fixed locks, relocation of unit properties, locations work, unit settings work, all strings are copied, cloned and unified.

This is an impressive stuff. Although I am fond of the process of creating triggers on my own.

So am I. This is not for creating basic stuff like touch revive or leaderboard. This is for importing EUD stuff from EUDSanc and selecting pieces that should not be imported. If you find a way to decipher (reverse) the triggers, let me know. I can mostly guess which part does what, except for the extra stuff in STR and MRGN that actually contains the magic. It would be perfect to generate those as parametric barrier would eliminate the need for recalculation entirely.

It shouldn't be that hard to make an emulator and see what those binaries do. That's what I'm gonna try anyway. By emulator I mean a piece of code that can externalize the EUD emulator. Imagine having triggerless map and external application that has trigger execution core in it. Give it TRIG section (limited to EUD/EPD) and every memory access will actually take effect in game (read/write memory of external process is doable and relatively easy). What would be needed to translate are trigger pointers for individual players (also doable by execution proxy). Then assuming vanilly unit structure, iteration over units should be detectable, MRGN (either native or EUD) manipulation detectable (that section is tiny compared to STR, so there shouldn't be anything executable). Any changes to unit properties (by EUD) should also be visible (exact offset is not known - but assuming known chunk data it can be found dynamically). Another issue to deal with is selection of execution path, since there are trigger list pointers on known offsets of known structure (+(0xC*playerID)+0x8 to first list item for each player). Considering that evaluating trigger cannot change its contents, we can safely divite all triggers into 2 groups. First, EUD, contains all EUD actions of unknown meaning, and the rest. We can ignore some triggers from the other group, if its actions do not change any conditionable value of anything in the first group (execution/skip does not affect the first group). Next thing to deal with are execution loop timers (can safely be ignored, because - single thread, reasonble fixed timer). Utilizing it dynamically for gameplay would require skilled developer.

The resulting code would emulate EUD externally while keeping everything in the map working. That way we can debug (breakpoints, logging), comment and most importantly, analyze. It's just an idea and I will be working on it for a while. My hopes are that I will create a map of the binary data (as well as the stuff in TRIG that I yet don't know what means) and reverse it into a readable code, which will be compilable back into binary (that would ultimately allow me to lift any and every current restriction of the tool).

Post has been edited 1 time(s), last time on Aug 17 2019, 8:40 am by T-warp.

So far I'm here
TRIG
Execution

Another way to bypass STR limitation would be to just overwrite the additional code and insert preloader loop to restore original code values. It's possible that STR is not reflected in game once it starts, so it doesn't matter if strings get overwritten back to code.

That is a serious plan. I want to clear things out. It looks that you're talking about external emulator that can execute triggers (1.16.1 assumed). But the main intention is to reverse engineer the existing triggers, so I assume it's mainly a debugger/logger that observes the existing triggers behavior and logs trace.

As far as I understand the main problem with STR section triggers that they are heavily interleaved in memory. There is always a trigger header that consists of prev/next pointers, isn't it possible to reverse engineer STR triggers by matching a pattern against that header plus against stern of the trigger that contains flags?

Talking about runtime. Trigger that is being executed must be changing it's last byte to reflect the action being currently executed, can that be of help?

It wasn't any issue to make external emulator of TRIG section. This covers the core and this is how remapping of native address space to emulators is done. There is still the native trigger core, but we remove all triggers from map prior emulating (playing triggerless map disables native trigger loop). Important thing is, if you access any trigger execution core memory, it's remapped into emulators memory (so they are truly separate). These codes were used to externalize executions, which turned out to be detectable by eudplib (milions of triggers are executed during init phase, 500k -ish work fine, then it accessed 0x4 and one of a few reasons why that could be is that the generated STR triggers used some known pointer value (did not dereference it), that would otherwise be remapped by emulator - or I missed something). I will publish it (source included) once it's stable enough and won't require extensive setup (load DLL to enable debug, restart sc after each change, etc.).

Current emulator utilizes native trigger execution loop, so native address space is available and eudplib init triggers work (just like it would without emulation). That setup requires advanced hooking procedures and is significantly slower (no DLL is injected, binary code is, doesn't require restart after change). It didn't help me analyze the original sequences, because there are literally tens of thousands of triggers executed and one cannot possibly analyze every single one of them (even with labeling counters and variables).


Not a problem as there is no guaranteed sequence between them. They were (I suppose) interleaved in order to save space with maximal efficiency (their order may differ between builds)

You can access pointer to next trigger that is about to be executed. In fact, that's how sequences are made in interleaving (you know what exact address of next trigger, it takes 2 actions to set pointer of next trigger to that next trigger). The problem is, you need to evaluate conditions in order to see patterns, and there is no guarantee that there are any patterns at all (or complex enough to avoid detection). I'm currently working on a trigger generation code that would need only so much triggers. Interleaving linkage is being done either on demand (if/else/skip) or by default (next/end). There is no recursion (as no stack is possible), but iteration is possible and very easy, nothing else is needed.

Last by of trigger structure is execution for playerID 27. I did not detect changes in trigger structure by triggers (except for setting next trigger pointers) and did not really analyze native trigger execution core (I know of current trigger node pointer, current player index address and emulate both of them). Last flag byte of trigger structure is named "execution flags". Those flags are used mostly internally and besides setting "preserve trigger" there is no point in messing with them. Check link#1 for more details about its values.