Most EPScript problems are behavioural rather than syntactic. A clean compile is not the reassurance it looks like.
| Forgetting the player loop | Without EUDPlayerLoop, every player shares one value while CurrentPlayer is used. It looks fine when you test alone. |
|---|---|
| Not filtering out computer players | The loop covers 0-7. Logic meant for humans has to filter on f_getcurpl() yourself. |
| Declaration order | With no hoisting, a function above a global that it uses will not compile. |
| Reading too much | Reads are expensive. Reading many values every cycle slows the game down. |
| A value beyond the range | When reading by binary search, an upper bound below the true maximum silently truncates the value. |
| The counter unit actually dies | If a unit used as a variable exists on the map, its value climbs on its own - the same trap as on the trigger side. |
Structural changes deserve care too. Adding one more variable and one more comparison to a script that ran fine can produce an EUD error in game. It is a matter of scale rather than syntax, so the compiler says nothing.
So when editing a script that works, prefer changing values to changing structure. Add new features in the shape the existing ones already have.
Two more catch nearly everyone who came over from classic triggers.
CurrentPlayer is not “this trigger's player”. In classic triggers the two are always the same so the distinction never arises; in an EUD map they are different things. An eudplib trigger has no owning player at all - it runs once regardless of how many players are in the game. CurrentPlayer is simply the value at 0x6509B0 and your code is what sets it, which is why setcurpl(3) makes P4 the subject and not the third player: the value is 0-based.
The performance half of the same point flips, too. Checking eight players in a classic trigger makes eight copies of it; EUDLoopPlayer copies nothing and runs one trigger once per player present. The classic instinct that “per-player costs map space” does not carry over, and spelling eight players out by hand is strictly worse than the loop.
Unlike if, a switch is not one scope per case - the whole switch is one block, so a local declared in one case is still in scope in the next. Declaring the same var name in two cases is a duplicate-declaration error; using it without declaring is no error at all and quietly touches the earlier case's variable, which is the worse half.
switch (a) {
case 1:
var b = 5; a += b; break;
case 2:
var b = 25; // 오류 — b는 이미 선언됨 / ERROR, b already declared
a *= b; break;
default:
b = 3; // 오류 없음. 그리고 의도한 것도 아님 / no error, and probably not what you meant
a -= b; break;
}