While hacking around in the new patch's code, I found a list of 582 1.16.1 memory addresses that are accepted by the new EUD emulation feature:

https://pastebin.com/pgT7EZst

The first column is 1.16.1 address, second is length of the address, and third column seem to be some kind of flags. No idea what the flags do, but it seemed that flag 0x2 makes the value read-only, and pointers have more unusual flag values.

I also added comments for some of the memory addresses whose meaning I knew.

There may be other supported addresses which are not part of this group, most notably I noticed that the entire game structure seems to be missing from this list.

Contributions welcome. I felt like formatting these to a google doc or something would make sense, but I also can't be bothered to do that =)

Post has been edited 1 time(s), last time on Dec 8 2017, 2:52 am by Neiv.

I asked the developers for the official list and they gave me start, end, and attributes. I then quickly annotated the list with my information. (missing a bit but it's fine for now)

This can be found here: https://docs.google.com/spreadsheets/d/195jZK7Ap71eO1-qdVskC2xsVl7EbNdVp0hbh7N3D38A/edit#gid=0

Here's a map which demonstrates the execution of a trigger cycle every frame, instead of every other frame (super-hyper triggers).

Attachments:

Good-bye crazy location/unit grids and mobile grids and whatever! This is a random EUD test map I made shortly after making EUD Enabler, and it works awesome here xD

eDIT:
I just realized location tables aren't listed on either of those, and yet they still work?

Attachments:

Location table definitely is supported, I also tested that.

E: Oh and the newest couple of scmdraft 2 alpha builds have support for EUD actions added to classic trigedit.

Post has been edited 2 time(s), last time on Dec 9 2017, 1:15 am by Suicidal Insanity.

Yay Finally

I wrote a hack which can dump active EUD mappings.

It showed that the game structure (0057F0F0 - 005967F0) is fully editable, but more importantly, it shows that the EUD emulator is even emulating some of the memory allocation patterns that depend on map:






The addresses change depending on size of the string table, and amount of triggers in the map

Also, editing stat_txt.tbl by writing bytes to the memory after 190a9680 works, as does swapping wireframes to another by writing over frame header of tranwire.grp. Rewriting the graphics itself didn't seem to work though. The other 2 grps are likely grpwire.grp and wirefram.grp. Writing over trigger structures worked.

Ya you can only swap a wireframe for a different existing wireframe, you can't customize them. (Because the game doesn't use GRPs anymore)

I am a simple man. In the Supported EUD Addresses googledoc thing, if it says "simple data," does that mean that it is editable using EUD Actions, and if it says "readonly", does that mean it is only referenceable in EUD Conditions?

@Zoan: Yes.

How does this work exactly? I see that the provided list has some trigger pointers and string table pointers "backed by code".

@SI: How does one write a trigger plugin for SCMD again?

Right now trigger plugin is a DLL with a special set of exported functions. I'm no longer happy with the interface I came up with, so if there is demand I'm willing to come up with and support a gen2 trigger plugin interface.

My understanding of this is that EUD mappers figured out that 1.16.1 has so predictable memory allocation that they can just access memory at address 19xxyyzz, and it'll always contain these dynamically allocated structures like wireframe grps, triggers and the map string table.

Maybe Koreans had a plugin that actually makes the memory allocation consistent, or maybe it was just ridiculously fragile, I don't know.

And now Blizzard is emulating the 1.16.1 memory allocation; It is possible to write to the dynamically allocated trigger structures that were read from the .chk, but the offset isn't just a simple 190bd120, it depends on how large those previous allocations were.

Ew.

Or maybe it's not meant to be predicted based on the previous allocations, but to be somehow read from the player's trigger list pointers/etc. I just didn't think there are any ways to do that, but maybe people had figured a way to dereference arbitrary addresses with death trigger manipulation. No idea really.

The koreans have a python EUD library that generates triggers which determine the value of the pointer to the string data, and then update all triggers using that value. (So the triggers store offsets relative to the string data chunk, and other triggers convert those to absolute)

How???

EDIT1:
Always set this one to zero?


EDIT2:
Now it's possible to detect a unit killed with 100% accuracy with move somewhere and check if it was actually moved. YAY!

And many, many other cool stuff like the following for maps that utilize vision tricks.


Post has been edited 2 time(s), last time on Dec 8 2017, 10:09 pm by Wormer.

Yep. Just set that to 0, preserve and don't use any waits/transmission at all.

So what are the greatest EUD maps?

Fireball by Roy is my favorite so far

You can of course read via pointers We just set the Current Player to the desired address EPD and read via current player. We call this 'Current Player trick', or for short CP trick.

We have a framework to dynamically generate and modify triggers, namely eudplib.

Unfortunately, for some reason, some of the addresses that are supposed to be supported are not working in fact. Notably many of the unit struct addresses are not supported.
For example, 0x59CCB0, which is the HP of the 0th unit, is not supported, while the list has "0059CCA8-006283E8" (which definitely includes 0x59CCB0) in it.

So edit game state to set current player to offset, and then use 'Deaths for current player is at least XYZ'? I assumed the framework edited the offset in the trigger directly, this way is easier !



Make sure to report stuff that doesn't work, otherwise they may not know about it and then can't fix it. I'm sure they didn't expect to catch everything in the first pass.

The current player trick sounds pretty neat. That's probably why g_LocalNationID and g_ActiveNationID are on the list.

EDIT: That would be currentTrigPlayerID @ 006509B0

Post has been edited 1 time(s), last time on Dec 9 2017, 8:59 pm by Heinermann.