EUD Editor 3 is largely the buttons and windows. What produces the EUD sits underneath it.
| eudplib | The Python library that generates EUD. Memory addresses, trigger generation and optimisation all live here. |
|---|---|
| euddraft | The tool that drives eudplib to build the map. |
| epScript | A language for writing EUD without touching eudplib directly. It compiles down through eudplib. |
Three ideas make the rest of the reference legible.
- EPD - a memory offset converted into the “player number” form the death-counter condition takes. That conversion is how EUD reaches arbitrary memory, and EPD(offset) performs it.
- Current Player - the value holding who a trigger is running as. eudplib moves it around to reach memory; f_setcurpl moves it and f_getcurpl reads it.
- Reads are expensive, writes are cheap - a write is one action, while a read has to evaluate conditions repeatedly. The documentation puts writes at roughly 32 times faster. When performance matters, read less.
This is why the f_dwread_cp family runs about twice as fast as f_dwread_epd - it reads relative to Current Player. And f_getcurpl is around 32 times faster than reading 0x6509B0 yourself.
eudplib syntax and epScript syntax are not the same, and a model will mix them. As the Claude Code module says, always have syntax confirmed against your own files.