EUD stands for Extended Unit Death. A death count is just data in StarCraft memory, and the whole technique is that putting out of range values in the player and unit fields of a death trigger makes it point somewhere else in that memory. It is arithmetic, not magic.
The death table starts at 0x58A364 and occupies 10,944 bytes: 12 players times 228 unit types times 4 bytes.
| 0x58A364 | P1 Marine, unit 0 |
|---|---|
| 0x58A368 | P2 Marine. One more player is four more bytes. |
| 0x58A390 | P12 Marine, the last of this unit's twelve slots. |
| 0x58A394 | P1 Ghost, unit 1. One more unit is forty eight more bytes. |
So these two triggers are exactly the same trigger. One is written as a death count and the other as memory.
SetDeaths(P1, SetTo, 3, "Terran Marine"); SetMemory(0x58A364, SetTo, 3);
PTR is short for pointer: the real memory address, which is what we have been calling an offset. EPD is that address divided by four, or more precisely how many four byte slots it sits from the start of the death table, because the player field of a death trigger IS that slot number.
EPD(addr) = (addr - 0x58A364) / 4 EPD(0x58A364) = 0 P1 Marine EPD(0x58A368) = 1 P2 Marine EPD(0x58A394) = 12 P1 Ghost
An address that is not a multiple of four cannot be reached by EPD alone. A death trigger moves in four byte steps, so to write a two byte or one byte field you read the containing four bytes, change the part you want and write it back. That is what eudplib's member access does for you under the hood.
You will rarely compute an EPD by hand now, because eudplib lets you address things by name. The reason to understand it is for reading failures: the hex in an EUD ERROR dialog is not the address but 0xFFFFFFFF minus it, and recovering the real offset to look up means knowing which of the two you are holding.
Addresses and ids you must not write