By default a trigger loop runs once every 31 frames, which on Fastest is about 1.3 seconds. That is far too slow for health bars, movement detection or skills.
The recommended way now is to enable EUD Turbo in EUD Editor 3's Plugin section. It is one setting, and it takes the trigger loop to roughly 24 cycles a second.
- 1Open your project in EUD Editor 3.
- 2Turn on EUD Turbo in the Plugin section.
- 3Compile. Nothing in your trigger file changes.
The old way was a hand-made “hyper trigger” packed with 63 Wait 0-millisecond actions. You will meet these in older tutorials and in other people’s maps, and recognising one is enough - there is no reason to add them to a new map yourself.
Speeding the loop up breaks every trigger that uses Wait. Count delays with a death counter instead - which is why every timer in the lessons that follow is a counter.
What Wait actually is: a queue, one per player. Hitting a Wait stops that player's trigger execution there and does not move on until the time is up. The default cycle is one every 31 frames, about 1.3 seconds, and a Wait 0 is about 0.084 seconds, so packing 63 Wait 0 actions into one trigger chops that 1.3 seconds up and keeps the cycle turning - which is all a hyper trigger is. And for the same reason, one Wait anywhere delays every other trigger that player owns. That is what people mean by tangled waits.
Two things worth knowing when you meet hyper triggers in someone else's map. First, there are usually three or more: with two, the Waits run out after 0.084 seconds x 64 x 64 - about 512 seconds, eight and a half minutes - and the map drops back to the default cycle for a moment. A third multiplies that by 64. Second, "a hyper on the same player tangles your triggers" is half true: it is an ordering problem, and putting the hyper trigger BELOW the triggers that use Wait keeps it clean. Even so, a computer player that uses no Wait is the better home - otherwise you re-order every time you add a Wait trigger, and a hyper owned by a human stops when that human leaves.
Even the EUD hyper is not entirely free of Wait. eudTurbo pins the trigger delay to 0 so triggers run every frame, and two things override that.
A Wait going from 1 to 0, and the countdown timer going from 1 to 0, both force the trigger delay to 1 - and trigger execution skips a frame. Anything that has to run every frame, such as an aura following a unit, a MoveUnit chain or a per-frame struct write, misses one pass and it shows.
The symptom is nasty: correct code failing occasionally - a following effect vanishing when a stage starts, when a button is pressed, or for no visible reason. The reported case went through three wrong hypotheses before landing here. Two fixes: never let the countdown timer reach zero by counting (stop it and write the 1-to-0 step yourself), and do not use Wait for in-game timing at all. Wait is for real-world time, and if that is genuinely what you need - a BGM length, say - read the system-time offset or hand the job to bgmplayer or soundlooper.