Death counters are the shared variables of an EUD map. Twelve players times 228 unit types is plenty of slots, and any trigger can read or write any of them. That is exactly the trap.
If two places read one counter, what decides the behaviour is who sets it back to zero between them. If the clearing code runs first, the later reader sees zero forever. It compiles, the code looks right, and one feature quietly stops working.
// 상황: 항상 0으로 읽힙니다
readKeys(); // 이 안에서 키 카운터를 0으로 만듦
...
if (Deaths(CurrentPlayer, AtLeast, 1, KEY)) { /* 도달하지 않는다 */ }The fix is not to read it in one place. Counters have different lifetimes, so each has to be read where it is still live. Some are consumed by your own code and some by a plugin that runs later. The first kind must be read before the consumer; the second can be read anywhere in your own code.
So it pays to decide and record an owner for each counter: who writes it, who reads it, who clears it. Three lines of comment beside the constant make it obvious where a new reader has to go.
Where code depends on order, pin the order with a check. If you can assert at build time that the read comes before the clear, moving the line later fails the build instead of silently breaking the feature. A check on ordering is far stronger than a check on text.