When an EUD map dies you usually get a dialog saying this EUD map is not supported, with a hexadecimal number on it. That number is not decoration: it is the address the payload touched.
실제 오프셋 = 0xFFFFFFFF - 창에 적힌 값 real offset = 0xFFFFFFFF - the value in the dialog
If the error came from a Deaths condition you can go one step further. The death table is four bytes per player and 48 per unit id, so the EPD distance from its base is player plus twelve times the unit id. Factor the decoded number that way and it narrows down which player and which unit id the condition used.
EPD 128355 = 3 + 12 × 10696
-> Deaths(P4, ..., 10696) // 유닛 번호가 범위 밖입니다A unit id like 10696 usually came from an array index. A constant index past the end is a compile error; a variable one is not checked at all - with a size-10 array a variable index folds to its remainder mod 16, and 10 through 15 read whatever sits after the array. Silently, with no error.
Which is why the break and the symptom are far apart: nothing happens where the index went wrong, and the EUD error comes from wherever that value was used later. Bound any index that comes out of a computation yourself.
If an error names something beginning f_f_, do not hunt for the typo. epScript prefixes a lowercase function name with f_, so function foo is really f_foo and a call can leave the prefix off. Call a function that does not exist and the compiler assumes you omitted the prefix, tries again with it added, and reports the doubled name. It means one thing: there is no such function.
| 에디터의 줄 번호를 믿지 마세요 | EUD Editor 3 prepends code of its own, so the line numbers in the editor pane are not the real ones. Right-click the file and view the compile result. |
|---|---|
| epTrace는 아무 때나 켜도 됩니다 | It does not have to run from the start of the game. Launch it at the moment you want to look, including while the map is already stuck. |
| 오류 코드가 매번 같은가 | If the same code comes back every run the value is fixed; if it changes per game it is computed. That alone halves the candidates. |