By IllogicTC on Mar 29, 2011
Another silly little snippet that may have some sort of use to some people. Rather than the standard time stamp (e.g. [12:34:56]), this snippet will "sync" with your computer clock and offer a higher-precision timestamp, on the order of hundredths of a second (e.g. [12:34:56.78]). This will only replace the timestamps IN-CHANNEL (not for logs, or queries) and only acts on other people's text and actions.
Right click a channel and select HRTimer > Enable/Disable to turn on. It may take upwards of one second to sync with your computer clock. Select the same option again to disable. This snippet will automatically disable itself when you exit mIRC.
While this is enabled, your timestamp will appear as [HH:nn:ss.xx] where xx = hundredths of a second. When you disable the snippet, or exit mIRC, it reverts back to your original timestamp setting.
NOTE: This snippet may be a little resource-intensive on older computers.
Thanks to jaytea and Jethro_ for ideas on how to improve it. And also another huge thanks to jaytea for helping me make this thing much more precise and reliable! (And on a sidenote, trimming the filesize quite a bit too by doing that. =P )
alias timestampsync {
set -e %ts_original $timestampfmt
var %ts_sync_source $ctime
while (%ts_sync_source == $ctime) /
set -e %ts_ticks $ticks
.timerts -o 0 0 .timestamp -f $eval($+([HH:nn:ss:, $mid(00 $+ $calc(($ticks - %ts_ticks) % 1000), -3, 2), ]), 0)
}
alias ts_sync_off {
.timerts off
.timestamp -f %ts_original
}
menu channel {
HR Timestamp
.Enable/Disable: $iif($timer(ts),ts_sync_off,timestampsync)
}
on *:EXIT: $iif($timer(ts), .timestamp -f %ts_original, /)
Update: Changed quite a few things around. Took Jethro_'s set -e suggestion, and also the $event suggestion.
Did a half-rewrite of the core, now relies on $ticks to try providing more accuracy. It grabs its needed $ticks values where necessary as soon as possible to minimize "latency" on the reported value.
Ran some tests using a dummy nick doing an /timer -h 0 (X) msg $active Test, etc, seems to hold a good amount of accuracy. Have not yet tested resilience to flood.
gooshie: Considering you can set many globals very quickly, as compared to say a lengthy /writeini operation (where it would open, write, close, open, write, close....) which would run quite slowly for the same amount of operations, I would be quite certain it acts more like a form of /fopen and /fclose. I do understand your concern for what appeared to be constant writes, but with the purchase of an SSD comes inherent problems and risks which one has, at best, taken into account and agreed to work with, or at worst, has not done their research but will find out over time anyway.
jaytea: I will focus on bringing more reliability and accuracy to this snippet. I myself have never run across another snippet that does this so I just kind of came in with a blank slate and an idea on what I wanted to achieve, but no pointers on how to help meet that end. lol. Also, I honestly never realized that with |pipes| you can do multi-line commands on timers. :( That will be a big help, not making constant calls to an alias for synchronization in the first place.
Jethro_: I never thought of just using the set -e switch for the variable %ts_current. I just realized with the .disable it wouldn't throw an error if it was already disabled (which is why I did the check for %ts_current on EXIT), I could definitely trim some excess there. Thanks.
when mIRC closes successfully, when you click 'Ok' or Save the variables file in the Scripts Editor, when you perform /saveini... that's all i can recall off the top of my head. but you can be damned sure mIRC won't go through the trouble of writing data to disk in the middle of an executing script. that would be silly :D
what, gooshie? :P /set doesn't involve any writing to disk. it takes fractions of a millisecond to set a global variable (<0.01ms on my machine) when mIRC has to create then traverse a linked list of size 1, and around 1.5 times longer to traverse a linked list of size 100 (that is, 100 variables with the same first letter). when considering which data structure to use here, it is not sensible to choose between a hash table and a variable based solely on the difference in execution times, since in all but the extreme cases we are dealing with a truly negligible difference.
IllogicTC
So basically you use high precision timers to write one variable to file one hundred times per second and another variable to file once per second. At the very least you should use hash to store the data in ram. This could be renamed 'how to wear out your solid-state drive quicker'. ALMOST NEVER should you use a set (global) variable to store data other than semi-permanent settings no matter what type drive stores the data.
$+($time,$chr(46),$base($r(0,99),10,10,2))
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!
