Completely accurate timecounter?
I'm not terribly sure this is the section where I should ask but I think it's the most suitable. I've found a cool way to make a timecounter which counts even hundredths of the second, using much less entities than the original Kreedz one. However, like both the Kreedz and spr1n's timecounters, the time it accounts doesn't match the time the KZ mod does. I'm sure in my method so is it HL engine's fault? In other words, is it possible to make a completely accurate timecounter apart from AMX?
13/08/2011 12:14Well, the short answer is like this:
If it was possible to make a completely accurate in-game time-counter, it would have been done by now...
Oh, dear! I expected answer from someone who doesn't yet think that they've achieved complete perfection.
13/08/2011 14:11(edited 13/08/2011 14:12)I'm pretty sure its not possible to make 100% accurate timer. Entity work is frame dependent in hl engine, and mostly it can't keep constant 100.0 fps at all times even on new computers. That means some frames get skipped affecting some physics and timing...
Kreedz timer has unreliable architecture so I'm not gonna talk about it. My timer on the other hand is very accurate, with constant 100.0 fps it could provide exact hundreds of a second at all times. However even one frame skip affects its accuracy, thats the reason why I made just tenth of a second for the timer. But even now it can handle just fps drops around 95-100.
Anyway I would like to hear about your method
Yes, I've seen that your timer is much more accurate and furthermore - lighter (less entities). My method is not yet finished because I started it by adding tenths and hundredths to the original Kreedz timer just to see if it works properly. Here's a picture, hope you understand my rubbish explanation:
[IMG]http://img36.imageshack.us/img36/932/schematicg.th.png[/IMG]
EDIT: the speed actually doesn't matter because of the flag 'teleport to next'. To stop it, there is a multi_manager, named 'counter_off', which has newkeys to each of the trains at 0.
Okay, I'm all for making a 100% accurate timer but who the hell gives a crap about 10.43.14XX? I certainly don't, the decimal system almost sucks enough as it is, no need to add hundredths or thousandths decimals, since demos will be checked with demolyser to get the actual time anyway, it is quite pointless.
Sorry if you feel like I'm being synical about your job, but imo you really should focus on making only more accurate timer, which btw I believe is impossible since like spr1n said, if the hl engine lags, so does your timer.
Btw spr1n does your timer take into account what the hundreth digit is and round it off automatically. I'm not even actually sure if it's even taken into account when checking the times.
If you didn't understand me here's an example:
Bilbo Baggins does a run on kz_stoneblock with time 15.15.44(71234572368) is the wr then 15.15.44 or 15.15.45. I'm having my doubts the counter rounds off the hundreth digit but would be nice to know for sure.
13/08/2011 19:14(edited 13/08/2011 19:16)Originally posted by DragonClaw...My method is not yet finished because I started it by adding tenths and hundredths to the original Kreedz timer just to see if it works properly...
I see, well as I said kreedz timer pretty messed up, func_train is quite buggy thing in hl. I wouldn't go that way....
Originally posted by GargoyleOkay, I'm all for making a 100% accurate timer but who the hell gives a crap about 10.43.14XX? I certainly don't, the decimal system almost sucks enough as it is, no need to add hundredths or thousandths decimals, since demos will be checked with demolyser to get the actual time anyway, it is quite pointless.
just wanna say that we are talking about two digits decimal accuracy here (XX:XX.xx). Further numbers are result of lags (100.0 engine fps means 0.01 frame length), so those are far less important.
Originally posted by GargoyleBtw spr1n does your timer take into account what the hundreth digit is and round it off automatically. I'm not even actually sure if it's even taken into account when checking the times.
If you didn't understand me here's an example:
Bilbo Baggins does a run on kz_stoneblock with time 15.15.44(71234572368) is the wr then 15.15.44 or 15.15.45. I'm having my doubts the counter rounds off the hundreth digit but would be nice to know for sure.
I understand your question, but I got confused by your example =D. anyway there is no rounding nether for demo real times nor in my timer (last digits are dropped). So without any major lags its like that:
[real time] [ingame timer]
01:33.70=01:33.7
01:33.71=01:33.7
...
01:33.78=01:33.7
01:33.79=01:33.7
01:33.80=01:33.8
I see. Well, I wanted to make an accurate timecounter because I find it quite annoying the one you've got on your map to be wrong, even though a kz map without one would be ridiculous. So your way is the best. Thanks.
14/08/2011 12:15Its not the best actually. As you might know I have also done timer without decimals. Unlike the one with decimals it has 1 second cycle, not 0.1s. So theoretically it should handle even bigger lags. I havent tested it as much precise as decimal timer, but so far it had no timerbugs even with unstable fps with drops down to 30.
So reaching perfection would be adding a 0.1 second cycle to existing 1 second cycle (in timer without decimals), which is reset on every 1 second cycle start. That way even if minor lags affect 0.1 seconds cycle, then timer doesn't gain offset because 1 seconds cycle would keep it under control. But that would require much more entity work which is is quite unreasonable.
Maybe there are also other ways to improve timers, but as I said its not really necessary since timers are just visualization, and accurate real time is measured with more reliable methods (amxx and democheckers).
Please log in to post replies.