Forums Feature Suggestions $asctime with maybe an option for $ticks/millisec?

I did a little search in this forum, and didn't find anything, so:
Could it be possible to add an option to $asctime (and thusly allowing timestamps to have these options) a $ticks, or milliseconds to the Nth, place? (i.e. $asctime(HH:nn:ss:MM) or MMM, MMMM, etc) I've scripted my version with a $tstamp alias, : and replaced all my echo -*t or $timestamp's with $tstamp to output: {070506¦09:43:04:9571}. I'm not sure how many other users out there would need it, but it might be useful.

That wont work for 2 considerably large reasons.

(1) $ticks shows 1/1000ths of a second NOT 1/10000th so using he last 4 digits means your showing a value that represents from 0.000 seconds to 9.999 seconds, but u show it at .0000 to .9999, this means that should you loop enought times you would see 8:00:00:5000 >>> 8:00:01:6000 >>> 8:00:02:7000 the .#### well never have rolled over in 3 seconds becuase it takes 10 to roll over.

(2) which may have confused you when looking at yopur results is that $ticks does not roll over the 1000 marker when the second rolls over, as the second rolls over it might be 1111111543 then one second later be 1111112543 then 1111113543, this of course makes the above (1) problem harder to see as it might look like this 8:00:00:5543 >>> 8:00:01:6543 >>> 8:00:02:7543

Heres the code i use, its actually for something else (it inserts ms .000 time stamping into the timestamp format anywhere there is a .000 to .999 in it (dot and 3 digits))
But you can also just request $mstime and it brings back the 3 didgits of the ms so u could use $asctime($+({mmddyy¦HH:nn:ss:,$mstime,$(},)))
Or you could just set the timestamp format to {mmddyy¦HH:nn:ss.000} and it well update on its own.

I wouldn't have pasted my code if it didn't work, so I'm not getting what you mean when you say it won't. I made it take the last 4, because if an event happens exactly one second apart, that's where $ticks changes (I understand that part..1.000, 2.000 etc). All this is for when things happen in the same second. (some examples)

However I do like the infinite millitimer setting the timestamp..that fixes places I couldn't easily get the timestamp to display, without a major scripting feat, so thanks! I appreciate the input

hmmm ok i didnt explain myself well so

Here is a simple example, in mirc create a timer that goes off 25 times at .1 second intervals, this well cover roughly 2.5 seconds.
(remember that mirc can not make an exacte interval at this smaller rate it does however get close)

ex
/timer -m 25 100 echo -at <-- mine & yours --> $tstamp

[2006-07-07 11:18:39.704] <-- mine & yours --> {070706¦11:18:39:5397}
[2006-07-07 11:18:39.813] <-- mine & yours --> {070706¦11:18:39:5507}
[2006-07-07 11:18:39.922] <-- mine & yours --> {070706¦11:18:39:5616}
[2006-07-07 11:18:40.032] <-- mine & yours --> {070706¦11:18:40:5725} *1
[2006-07-07 11:18:40.141] <-- mine & yours --> {070706¦11:18:40:5835}
[2006-07-07 11:18:40.250] <-- mine & yours --> {070706¦11:18:40:5944}
[2006-07-07 11:18:40.360] <-- mine & yours --> {070706¦11:18:40:6053}
[2006-07-07 11:18:40.469] <-- mine & yours --> {070706¦11:18:40:6163}
[2006-07-07 11:18:40.579] <-- mine & yours --> {070706¦11:18:40:6272}
[2006-07-07 11:18:40.688] <-- mine & yours --> {070706¦11:18:40:6382}
[2006-07-07 11:18:40.797] <-- mine & yours --> {070706¦11:18:40:6491}
[2006-07-07 11:18:40.907] <-- mine & yours --> {070706¦11:18:40:6600}
[2006-07-07 11:18:41.016] <-- mine & yours --> {070706¦11:18:41:6710} *2
[2006-07-07 11:18:41.125] <-- mine & yours --> {070706¦11:18:41:6819}
[2006-07-07 11:18:41.235] <-- mine & yours --> {070706¦11:18:41:6928}
[2006-07-07 11:18:41.344] <-- mine & yours --> {070706¦11:18:41:7038}
[2006-07-07 11:18:41.454] <-- mine & yours --> {070706¦11:18:41:7147}
[2006-07-07 11:18:41.563] <-- mine & yours --> {070706¦11:18:41:7257}
[2006-07-07 11:18:41.672] <-- mine & yours --> {070706¦11:18:41:7366}
[2006-07-07 11:18:41.782] <-- mine & yours --> {070706¦11:18:41:7475}
[2006-07-07 11:18:41.891] <-- mine & yours --> {070706¦11:18:41:7585}
[2006-07-07 11:18:42.000] <-- mine & yours --> {070706¦11:18:42:7694} *3
[2006-07-07 11:18:42.110] <-- mine & yours --> {070706¦11:18:42:7803}
[2006-07-07 11:18:42.219] <-- mine & yours --> {070706¦11:18:42:7913}
[2006-07-07 11:18:42.329] <-- mine & yours --> {070706¦11:18:42:8022}

(1) Your last 4 digits are incrementing in only 10/1000th of a second, when they should be going up in 100/1000ths aka 1/10th of a second, this is becuase $ticks is 1/1000th of a second, so showing the last 4 digits of $ticks shows from 0/1000ths of a second to 9999/1000ths of a second, aka the most significant digit represents 1 second not 1/10th of a second.

(2) now if we look past the extra digit used and examine only the last 3 digits of ticks, you still have the 2nd problem. As shown by *1 (725) *2 (710) *3 (694) that the last 3 digits are no where near zero when the second rolls over.

--

I looked at why you migth not have spotted this, and i came to the conclusion that problem (1) has hidden it from you, the fault would have appead fare less often becuase of 4 digits
Heres what 4 digits looks like
{070706¦11:18:41:6928}
{070706¦11:18:41:7038}
{070706¦11:18:41:7147}
Looks ok if u take that as 1/10000ths of a second, but now after correcting it
{070706¦11:18:41:928}
{070706¦11:18:41:038}
{070706¦11:18:41:147}
Now the problem becomes apparent.

In case i didnt make (2) clear, the problem is as the clock rolls over from 11:59:59 to 12:00:00 the value of $ticks well not have the last 3 digits as 000, they can be anything, becuase $ticks is a 1/1000th of a second counter since the system started, whcih is unlikely to have started exactly as a second started.

Ok, I think I get what you're coming at finally! Yes, $ticks won't be a true measure of seconds in a timestamp/$asctime sense. It does however, for now, just give some foundation as to when a message is displayed, and how closely to another message. On your test, looking at your extended 3, and my extended 4, both extensions increase between 109 and 110 each time, but yes, it's not "resetting" when the seconds do. 11:59:00:8635 12:00:00:9781. This would be easier with an $asctime(mmddyy|HH:nn:ss.mmm) Maybe I can reset the system time exactly when the seconds reset to 00 >:D

Of course they both increment at the same rate, thats becuase they are both soured from the same value $ticks.
What I have repeatedly tried to explain to you is that you cant use the bottom four digits of $ticks to represent mmmm the bottom 4 digits of $ticks represent s.mmm

There are 1000 ticks per second, so only the bottom 3 digits of $ticks can be used to represent a decimal position of a second.

PS: to my knowledge from inside mirc u cant reset the system bootup counter. (although i have never tried either)

You could try out game_tools.dll to query for an acurate $ticks to <1ms instead of the 10ms+ acuracy (OS dependent) of mIRC to get it acurate to s.mmmmm.