Confirmed on 6.35.

Interestingly, if you change the number of iterations, it changes how much the timer is off by.

For instance at 5 we get:
Timer 1 finished at 00:21:27
Timer 2 finished at 00:21:28
Timer 3 finished at 00:21:29
Timer 4 finished at 00:21:30
Timer 5 finished at 00:21:35

And at 3 we get:
Timer 1 finished at 00:22:25
Timer 2 finished at 00:22:26
Timer 3 finished at 00:22:29

It seems the last timer is always off by X seconds where X is the number of loops you use. The pattern continues all the way up to at least 10. It didn't text any higher.

Edit: Also, -m may have the same bug. I did a bit of testing an 9 out of ten tries it functioned as expected. However, one one of them it had the exact same error as we're getting with -h. This is very odd behavior, as one would expect them either all to work or all to fail.

Edit2: Upon further testing another odd thing occurs using the following code.

Code:
//var %i = 1 | while ( %i <= 3 ) { .timer -h 1 $calc( %i * 1000 ) echo -a Timer %i finished at $!ticks | var %i = $calc(%i + .5) }


We get this (which is the same bug as above):

Timer 1 finished at 63625187
Timer 1.5 finished at 63625687
Timer 2 finished at 63626187
Timer 2.5 finished at 63626687
Timer 3 finished at 63629687

However, if we adjust the 3 loops to 5 loops, we get this:

Timer 1 finished at 63713281
Timer 1.5 finished at 63713781
Timer 2 finished at 63714281
Timer 2.5 finished at 63714781
Timer 3 finished at 63715281
Timer 3.5 finished at 63715781
Timer 4 finished at 63716281
Timer 4.5 finished at 63716781
Timer 5 finished at 63716781

The above error goes away but there is a new one. The boldest numbers should be 500 ms apart, but mirc reports them as the exact same. Interestingly, they appear on my screen about 500 ms apart (which is what should happen).

Last edited by Thrull; 01/07/10 04:49 AM.
Yar