Game-time wait: Horrid Accuracy

When using game-time waits, are massive accuracy problems common? Not just off by a few half seconds or seconds, but minutes?

Does a game-time wait of "0.1" seconds hold any special meaning? Perhaps, increased inaccuracy?

The economy in Norbo's War is split up into (up to) 12 parts, 1 tick for each player. Between each tick is a wait of 0.1 seconds.

For each (Integer A) from 1 to 12, do (Actions)
Loop - Actions
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
If - Conditions
InPostSettlerAge[(Integer A)] Equal to True
Then - Actions
Trigger - Run Economy of 29 <gen> (ignoring conditions)
Wait 0.10 game-time seconds
Else - Actions

Is there a reason why, sometimes, the game-time wait becomes so grossly inaccurate that the maximum of 1.2 seconds (if lag was not present) wait is extended past even 20 seconds, thus skipping over a player occasionally? This problem has become very common as of late, and it is beginning to annoy me.

use polled wait.

He IS using Polled Wait

Perhaps the Wait being inside an If/Then inside of a For Loop might hold some significance?

I've come to believe that polled wait is horridly inaccurate inside loops. It also appears that it has a minimum wait time(maybe it's just because it's waiting longer than it should?)

I've rewrote most of my triggers that used small polled waits to turn on a periodic event trigger. These seem to be much more accurate, and can do loops faster, but not instantly like when there is no wait. Just make sure to turn your trigger off when it finishes the loop.

Hrm. Now to devise another method of halting the computations of the economy trigger. If I took it out, a sizable grind on all computers would occur, and may even make slower computers stop for enough time to prompt the lag window opening.

I suppose I could just do it the.. somewhat.. interesting way. 12 seperate if's with waits.

Game-Time waits or Polled Waits, actually create a timer and wait for it to expire, calling TriggerSleepAction(0.1) while it check the remaining duriation of the timer. (Meaning it has a minimum duriation of 0.1 seconds). And because of processing time, and other code in your trigger, that 0.1 seconds might actually be 0.11 seconds.

Also take note that if you call a trigger via Trigger-Run(...) and that trigger has a wait in it, the calling trigger will not wait for it to finish before it continues with the rest of its actions, but if there are no waits, the calling trigger will wait for it to finish.

If it comes to making timers for this, I might. But that is a lot of work for something that may have an easier solution.. At least, in this case.