Zwiebelchen
You can change this now in User CP.
- Reaction score
- 60
Hello everyone. After reading the discussion in the smoothtimers-thread (http://www.thehelper.net/forums/showthread.php?t=149544), I did intense testing on trigger waits in Starcraft II and got some weird results that may be influence map making in the future.
For all of my tests, I assumed that Timers are accurate - at least if used on a longer period of time. (1 second in that case)
These are the functions I used:
So here are the things I found out:
So basicly, what does this tell us?
To sum it up:
Timer systems are not required anymore. In terms of accuracy, there is no difference between timers and waits. Always remember that timers get updated AFTER waits!
For all of my tests, I assumed that Timers are accurate - at least if used on a longer period of time. (1 second in that case)
These are the functions I used:
Code:
bool gt_Nahkampfinitialisierung_Func (bool testConds, bool runActions) {
// Actions
if (!runActions) {
return true;
}
Wait(1.0, c_timeGame);
TimerStart(gv_t, 1.0, true, c_timeGame);
while (true) {
Wait(0.0, c_timeGame);
gv_i=gv_i + 1;
}
return true;
}
bool gt_UnbenannterAuslser001_Func (bool testConds, bool runActions) {
// Actions
if (!runActions) {
return true;
}
TriggerDebugOutput(1, IntToText(gv_i), true);
gv_i = 0;
return true;
}So here are the things I found out:
- The game engine consists of 'ticks' of 0.03125 seconds (1/32 of a second)
- Both Timers and waits can only fire in intervals based on multiples of 0.0625 ... 0 second waits are an exception to that rule
- It seems that some weird rounding is made for the wait input (I think because of GUI compatibility, which doesn't allow more than 4 digits). The input of 0.0626 will also result in a 0.0625 wait, whereas an input of 0.0627 will result in a 0.125 wait.
- Using values between two 0.0625 multiples will result in the next higher interval being used, except for said rounding last-digit
- Hosting games in Battle.net (instead of using the single-player "Test map"-mode) had absolutely no effect on waits. All results I got were exactly the same in Battle.net games. At least with nobody else in the game. However, as Battle.net games behave like ordinary multiplayer games (Higher delay on keypress events than in singleplayer), you can expect that the result will not differ in games with more than just one player
- A waiting time of 0.00s will expire after 0.03125 seconds.
- A waiting time higher than 0.00 seconds and lower than or equal to 0.0626 seconds will result in a "true" waiting time of 0.625 seconds
- A waiting time of 0.03125*3 = 0.09375 seconds can not be achieved, no matter what the input parameter is - only multiples of 0.0625 are possible.
- Timers get updated AFTER wait ticks
So basicly, what does this tell us?
- Using both waits and timers does not make sense, as timers get updated after waits. That means if you fire a 0.0625 second timer and a 0.0625 second wait, the timer will return 0.0625 seconds time left when the wait expired. Either use timers OR use waits. Everything else may cause nasty bugs in your script
- Waits are able to achieve 32 fps frequencies, whereas timers can only achieve 16 fps
- Both timers and waits are not able to achieve non-even multiples of 0.03125
- Both flavours seem to have perfect accuracy in Battle.net - at least when used after these rules
- Odd multiples of 0.03125 seconds may be achieved by using multiple 0.00 waits after another.
To sum it up:
Timer systems are not required anymore. In terms of accuracy, there is no difference between timers and waits. Always remember that timers get updated AFTER waits!
