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.
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:
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?
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.