well TC, this is certainly a unique way of going about adding hundredths of a second to a timestamp. i'm a little skeptical as to its accuracy though :P

the delay of mIRC's timers have a resolution of ~15ms. you will notice if you execute the following test, that most of the timer executions occur within that amount of time of each other:

//editbox //timerjt.test off $(| unset %jt.*, 0) | set %jt.start $ticks | .timerjt.test -h 0 0 echo -a Diff in $!!ticks since last echo: $!calc($ticks -%jt.last) -- Average difference since start: $!calc(($ticks -%jt.start) /%jt.times) $(|) inc %jt.times $(|) set %jt.last $!ticks

(press enter to stop it)

and that's even with a delay of '0' ms. you'll notice a slight increase if you change the delay to 10ms (i observe a jump of about 0.3ms in the average time). as i'm sure you can see, if the average delay between you increasing %ts_current is 15ms, then it's likely to become inaccurate very quickly :( one way to improve this would be to use /timer's -c switch to force mIRC to 'catch up' by sometimes executing the command more than once in order to maintain an average delay roughly equal to the one you specified. what's screwy is that if you test it with -c in my earlier example, specifying a delay of 10ms results, in practice, of an average delay much closer to 9ms (9.02 on my machine). a specified delay of 11 then produces 10.02 for me, and i suspect this is due to the overhead of having to interpret the command, although i would have hoped mIRC would factor that into its calculations.

there is a second problem, however! since this isn't synchronized with $ticks, it is possible to see, for example, [11:00:00:45] and then [11:00:01:46] a split second later. this is a more difficult issue; a solution might be to continually check when $ctime changes and estimate the hundredths value of $ticks at which it does so. then you can base your timestamp hundredths value on that, rather than using an incrementing variable.

oh, and instead of creating those events, you should consider using /timestamp -f to alter the global timestamp on the fly. makes things much easier, and the time it takes for a single execution of /timestamp -f is approximately equal to the amount of time required to set a global variable - on the order of several microseconds.

a great idea, but unfortunately, it is tricky business!