Now that I think of it, it's actually almost always the A or B option here. Beginning of the second or end, not some shady "almost half but not quite" second.
the only thing milliseconds would do is clutter the timer up. the fact that sometimes you add some "at the beginning / at the end of the second" to the timer doesnt call for a millisecond display and is perfectly covered by gut instincts already.
For me it's easier to calculate routes when watching the demos from pro players and that helps me to understand some of their decisions.
Also the timer format could look like xx : xx : x (example 05 : 23 : 3) not necessarily xx : xx : xx.
Overall I think it speeds up analyzing demos process.
I know it's not that powerful tool like sound clues and cg_wh 1 from WolfcamQL but wouldn't hurt to have this in the game.
IF you were to add another subdivision of time, it should probably be server frames. Not much point assigning 1000 points of precision to something that only has 40 possible values. SMPTE time code is an example of something that already exists where frames is the smallest subdivision.
I don't know much about programming but I remember that in:
- "Quake 3" >> last minute had deciseconds displayed on clock.
- "Warsaw" >> cg_showTimer 1 was displaying milliseconds on clock.
The point I was trying to make I guess is that items spawn on server frames, not between them. Deciseconds is only showing a quarter of possible time states and 960 of the 1000 milliseconds won't correspond to something actually happening in the game. Sorry about my autism