Hi, pretty simple question, but I'm trying to script my entire map in normal Starcraft/TrigEdit style triggers. There are some functions that EUD Editor 2 lays out which are very handy because I don't have to look up the memory addresses manually, but I would prefer to not have two separate systems to work with (and I don't know how to actually code). So, for example:



This is a trigger where it loops through the unit pointers that belong to a player and identifies if any of them are Cybernetics Cores. How could I export this (these) trigger(s) in such a way that I could copy/paste them into the systems I've already built in TrigEdit? What language is this written in? If I try to save the trigger files, it just saves as a .tf that only EUD Editor 2 seems to be able to parse. I thought maybe I could just open the map in SCMDraft 2 to read the triggers that way, but I can't seem to find any way to get it to read my map, or "unprotect" my own work so that I can observe the triggers directly.

I realize that these triggers may be large and unwieldy when parsed into TrigEdit triggers, but I'm willing to suffer that. Any help appreciated!

Post has been edited 1 time(s), last time on Nov 13 2022, 2:45 pm by Brusilov.

The biggest problem you'll face I think is that reading/copying values with trigger EUDs is cumbersome as hell. As far as I'm aware, the only way to do it is through "binary countoffs". I'm a little short on time at the moment, but the gist of it is that you'll want to:
1) read the address of player 1's last unit (0x006283F8), and from there on...
2) read the unit ID value (current address + 100)
3) do your thing if it's 164 (cyber core)
4) read the address of the player's previous unit (current address + 104) and, if it's not 0, repeat from step 2.

The "Current Player Trick" is useful here, but I'm not sure if there's good documentation about this concept somewhere. I can try to elaborate further if no one else has by the time I have more free time.

I would very much appreciate you elaborating either way when you have the time, since I find this kind of stuff really fascinating, and documentation on the "Current Player Trick" is either very sparse or very technical – that's literally all I can find – and I'm really not grasping the theory behind it.


This seems to make sense to me, although I'm having some trouble understanding how the memory offsets interact, since 0x006283F8 and 0x0059CD0C (unit type) and 0x0059CD10 (previous player unit) seem to be far off from 100 and 104 bits respectively?

So you've noticed how each EUD address has some player ID value associated with it (for example, 203151 for the "Trigger Execution Timer"). That is because this address is 203151 bytes after the original position of the "Unit Deaths" table. It advances by 4 bytes instead of 1 because 'set unit death' writes 32-bit integers.

The first 4 bytes in the death table are Player 1 marine deaths (position 0). When you set marine deaths for Player 2, it modifies the value 4 bytes after (position 1). "Current Player" is simply an offset for the player position in memory, so when for instance Player 2 executes a trigger with set deaths for Current Player, CP has a value of 1 and modifies the unit death accordingly.

The so-called "Current Player Trick" revolves around that concept of dynamically accessing memory addresses, where setting CP to 203151 and subsequently changing marine deaths for "current player" will modify the value of the aforementioned EUD. Which brings us to:
You would use the binary countoff method to copy the value found at 0x006283F8 (Player 1 Last Unit) to Current Player.

If for instance there is only one unit on the entire map owned by player 1, then Player 1 Last Unit's value will be 0x0059CCA8 (which would be a player value of 19025. Additional units would be found at addresses between this and 0x00628298). When copying the value to CP using binary countoff, you want to add 1 to CP for every 4 you subtract (remember CP is a 4-byte offset). Also set CP to 0 first if the triggers are executed by players 2+. If I remember correctly---don't quote me on that just yet---you also have to add 1073741824 if your CP value is at most 1452249 to account for "negative" memory offsets, and subtract 1452250 to correct for the relative memory offset (in that order). I'll try to verify this later.

From that point on, you can then add 25 (an offset of 100 bytes) to 203155 (Current Player), which would point to 19050 (0x0059CD0C, Unit Type). Now you can check to see if Current Player has exactly 164 marine deaths to know if the unit is a cyber core.

If so, add 1 to 203155 (resulting in an offset of 104) and check if Current Player has at least 1 marine death. Since in this example this is the only unit on the map/owned by that player, it will be 0. But if it isn't 0, that means your player has at least one more unit for you to check. So you use binary countoff again to change the CP value to the value found here (as you initially did with the Last Unit pointer) and repeat the process.


The annoying thing with this is the amount of triggers required to achieve this. Not only do you need to re-add the values to the addresses you read to avoid breaking the game, but also requiring a lot of trigger duplication to read through the unit table in 1 trigger cycle. I believe it could be possible to achieve goto jumps/loops in triggers using "current trigger node" (0x006509AC), "next trigger node" (value of current trig node + 4), and "current trigger action index" (value of current trig node + 967), to arbitrarily choose which trigger/action to execute next in the trigger cycle, but I'll need to do some tests to see if it can actually work.