Oh the timer i showed was only ment to be in refrence to showing how mirc seems to tick a second off if your over 900ms (aprox) from the time you created the timer to the time the seconds tick over occurs, as in if assume that the second ticks over, at $ticks = 100950, 101950, 102950, 103950, then if the timer was created at 101025, then since 925ms have passed since it was created, a second well be ticked off, however if it was created at 101500, then only 450 well have passed and it wont be counted as a second, and must wait another full 1000ms before a second is ticked off. I was using a 3 repeat timer, to show that the following events matched a one second delay from the previous, but the first could be from 900ms to 1899ms (aprox). I also ment to show how the decimal offset (ms) of the seconds of $ctimems produces the same offset, which I believe points to a regular once per second internal action of mirc that processes timers. For my tests I had been using 9 times going off from 1 to 9 seconds, and as i said untell i went online they would always come up in perfect sync. As you have clearly shown, there does appear to be some unusal behavour as I could easily see a timer being delayed by other events, however the jump is in the area of a acceleration of the timer, so two go off in one second. I guess unlesss Khaled actually told us how he worked them we wont ever know the exact reasoning for some behavours.
