How does a timer work?
15/04/2017 21:37Hi, I was thinking about it for a while. Can someone explain me in detail how a timer works? It is a really interesting topic for me. I know there is an old thread with a short explanation but it doesn't have any details so I made this thread. Thanks in advance.
16/04/2017 01:17@spr1n we need u m8
18/04/2017 20:55(edited 18/04/2017 22:33)Don't have a lot of time, so there will be limited details and general concepts. I would rather answer some specific questions, so don't hesitate to ask.
My timer uses cycles (entities, mostly trigger_relay, that trigger each other in loops) to track all the events. Start button triggers the main cycle that starts countdown cycle and checks timer status (running, stopped, reset etc.). Countdown cycle begins with the smallest time frame on the clock, in case of my timer its 0.1s, then every 10th or 6th activation of a cycle (via game_counter) next cycle is triggered to change next digit: 10 of 0.1s trigger a second, 10 of 1s trigger 10s, then 6 of 10s etc.. Every activation of a cycle turns on one digit (env_sprite or func_wall_toggle) and turns off the rest, there are a lot of entities responsible for that process. This is how the clock is running, however there is also complex reset system and failsafes, like map start and round start preparation of the timer entities, locking start button from reactivation etc.
I revised other timers and came to conclusion I have to rely completely on trigger_relays and game_counters for important time keeping process, which resulted in about ~0.005s timer accuracy, but still fps dependent like everything in the goldsource engine, so fps drops can still cause inaccurate time compared to a real tome. For example Kreedz timer relies a lot on func_train and some other entities that are not reliable and are causing timer bugs, this fact enforced the recording rule of a maximum 60 minutes map uptime, to avoid significant timer offsets that can reach more than a few seconds on average length maps, even with perfectly stable fps.
18/04/2017 23:37How exactly does the stop button end the "chain" of events?
19/04/2017 12:55Stop button terminates the main cycle loop using multisource in "master" key of one trigger_relay iirc (that trigger each other and all the next cycles of the timer). Multisource entity allows binary variable and either allows entity (that has master key) to work or does not, depending on that binary value. That process also uses env_global entities to change variable values and changetargets to keep the order for reset etc.
Kreedz timer uses just several changetarget entities to break the loops, but that resulted in some bugs (reset on the first map round) and more entities.
21/04/2017 23:39What are the main differences in performance between your timer (that uses sprites) and keo's timer (that uses wall_toggles i believe)?
22/04/2017 10:08I was not aware Keo made a timer, can you please show it to me?
However I have made several version of my timer a while ago, including both timer with sprites and func_wall_toggle https://xtreme-jumps.eu/e107_plugins/forum/forum_viewtopic.php?225302
Both timers are widely used by mappers. The difference is only in digit entities. func_wall_toggle allows easy and conventional customization of the timer (texture switch, rotation, scale, transparency etc.), sprites on other hand have fixed axis/size/texture and will not rotate/scale with the whole prefab (until changes made in preferences). func_wall_toggle also uses a lot more precache resources, but that can be avoided with vluzacn zhlt tools with a few steps (instructions in the link above).
Both versions use exact same "engine" of the timer and have the exact same visual appearance before customization.
22/04/2017 17:30Oops, he gave me a timer named keo_timer.rmf so I thought he built it, in reality it is your timer sorry. Dunno what to ask anymore, so if I remember something I will ask again.
28/05/2017 20:15Why and how does timebug happen? How does high fps affect it? Can it happen with your timer and why?
30/05/2017 23:24(edited 30/05/2017 23:32)Timer bug in its original meaning is associated just wth the Kreedz Timer, its an event when real time and in-game time start to differ drastically (more than 2 seconds), it is very likely to appear after 60min uptime (but may not appear at all, or rarely may appear earlier). This caused XJ to adopt the rule of maximum 60min uptime for all records, before real time started to be the etalon measurement and made this issue obsolete.
How exactly this happens I don't know for sure and probably nobody will. My educated guess is there's some poor game code in the engine that mishandles events related to specific entities Kreedz Timer uses (func_train is definitely one of them), maybe the dynamic nature of the entities cause those additional accumulative delays and timer bug as result. My timer relies only on trigger_relay and game_counter when it comes to timekeeping, and those two seem to sync with frames perfectly and never show any signs of offsets.
HL and cs1.6 engine (goldsource) is fps based, so events and physics are heavily dependent on frame rate and its fluctuations , meaning timers are also not 100% representative of a real time. While my timer isn't affected by "timer bug" it will only show correct time with constant 100fps, which is very rare for most players... due to hardware, system load or just unoptimized maps. Difference is usually insignificant though, but enough to make hundreds of a second (0.01) to be a bad idea for a timer as it never will be correct in reality.
Goldsource is very simple engine, but full of bugs and flaws. It was made to BARELY work. It is modification of quake engine with added bare minimum features to make Half-Life possible, Counter-Strike is just a mod that added bare minimum features on top to make netcode and group play possible. This engine is not diverse and not mapper friendly, but does make a good base for good mods like sven-coop f.e. where some features are remade completely so they work properly.
23/06/2017 23:57How does the start button start the timer? What is the sequence of the process? Like button > trigger 1 > another entity >...
27/06/2017 21:08Commenting again to keep the thread in the top5 latest so spr1n can see it.
28/06/2017 01:40I don't have his timer, but shouldn't it be fairly simple to look at the entities and find that information yourself? It could be a good learning experience to try and understand that since you seem interested in how it works.
28/06/2017 14:19For me it is just too hard to understand by just looking at it, without a proper explanation of the process nothing makes sense.
29/06/2017 10:54spr1n how long time did it take you to make your timer?
29/06/2017 20:05Originally posted by Gorbachev_xFor me it is just too hard to understand by just looking at it, without a proper explanation of the process nothing makes sense.
func_button triggers mutli_manager.
vice versa multi_manager triggers other entities.twhl has a good entity good for proper description.
29/06/2017 23:20Originally posted by Gorbachev_xHow does the start button start the timer? What is the sequence of the process? Like button > trigger 1 > another entity >...
I already answered that
Originally posted by spr1nMy timer uses cycles (entities, mostly trigger_relay, that trigger each other in loops) to track all the events. Start button triggers the main cycle that starts countdown cycle and checks timer status (running, stopped, reset etc.). Countdown cycle begins with the smallest time frame on the clock, in case of my timer its 0.1s, then every 10th or 6th activation of a cycle (via game_counter) next cycle is triggered to change next digit: 10 of 0.1s trigger a second, 10 of 1s trigger 10s, then 6 of 10s etc.. Every activation of a cycle turns on one digit (env_sprite or func_wall_toggle) and turns off the rest, there are a lot of entities responsible for that process. This is how the clock is running, however there is also complex reset system and failsafes, like map start and round start preparation of the timer entities, locking start button from reactivation etc.
There are almost 200 entities so it is obviously dumbed down explanation already. If you don't understand something then you have to be more specific in asking questions or use twhl entity wiki as dEMolite suggested. I'm not gonna explain which entities do what, nor gonna explain every single entity in specific tasks of the timer. I already explained the concept and it should give you an idea how to build a prototype which could do some similar simple time keeping events, the timer itself however has a lot more to it and I don't have time for such detailed analysis.
29/06/2017 23:22(edited 29/06/2017 23:24)Originally posted by Softbitterspr1n how long time did it take you to make your timer?
The main work that contributed to >95% of the progress was done in about 2 weeks close to release date. However from concept builds to beta tests it took almost a year to finalize, project was idling for a while and abandoned several times because I didn't like some "ugly" goldsource entity work for simple things.
30/06/2017 00:10(edited 30/06/2017 00:16)Old answer so I totally forgot it (really bad memory), btw I not asking anything to build a prototype, I was just curious about some deeper details.
03/07/2017 19:39Originally posted by spr1nI would rather answer some specific questions, so don't hesitate to ask
Originally posted by spr1nI'm not gonna explain which entities do what, nor gonna explain every single entity in specific tasks of the timer.
Weird, sorry.
Please log in to post replies.