Half-Life Timer By Zerotech Created 8 years ago2016-11-16 20:30:42 UTC by Zerotech

STATUS: Release Candidate 1

Link: http://www.mediafire.com/file/pqlsrikdhjnlaqd/hl_timer_zone_rc1.rar

Activation: Zone-Based
Time: 00:05:28

Please do report of any problems with the timer, I think I have now gotten a timer to work, also the reset feature is working as well.

I plan to implement this timer onto my bhop maps, and if it goes well this timer will no doubt will change the way how speedruns for Half-Life and it's mods will operate.

I like some feedback and if people enjoy this timer I hope the mods/devs will include this timer as part of the Tutorial or Development Source so people can use my timer with full appreciation.

Is it a map or a piece of code?

It's both a map and source code.

UPDATE: Release Candidate 2
Fixes: Reset function now works.

Link - http://www.mediafire.com/file/n14nlljku6spp5l/hl_timer_zone_rc2.rar

Youtube Video Link : https://www.youtube.com/watch?v=QEJmOjZV8xw

You can come and see for yourself how good the timer is.

Not bad. It could be nicer if it was a func_chrono entity that draws the timer on screen with the time counting backwards and triggering an entity as it reaches zero...

I've managed with an update to get the reset function to work, I also include the button function to confirm that it works.

Download Link: http://www.mediafire.com/file/ubid596lb6bsn8c/hl_timer-rc3-map.rar

I can tell you with the button activated timer it will work with just about any amxx kz plugin.

OK I think i have fixed up the timing issue as well as getting the reset feature to work. Also this update has logos to tell you where the start/stop and reset function is.

Release Candidate 4 - http://www.mediafire.com/file/1kzxogiz38i45od/hl_timer-rc4-zerotech.rar

I have tested out some amxmodx timer plugins unfortunately there seems to be a 1 second delay so whatever the amxx timer says the actual timer is 1 second faster which makes sense.

To get the amxmodx timer working, the timer has to start without delays to ensure that the display timer on the map will match with the amxmodx timer that does not have a delay in activating/deactivating the timer.

So overall its no longer a map problem with the inaccuracies with the map timer and the amxmodx timer that is something that the devs will have to fix in order to get the plugin timer to work.

All I need now is a working amxmodx timer and also a 3rd party demo viewer to compare the times to see if it is 100% accurate and working properly.

This is awesome to practice bunny hopping faster. I wonder if there's a way to map this without code.

Basically adding entities/triggers is in a way 3D-Coding.

To add it onto your maps, just copy the whole timer display as well as the entity in the middle of the timer and allocate 3 zones where you want to choose as the start/finish and reset and you are good to go.

Primarily this timer is built for the purpose of speedruns whether Half-Life or Counter-Strike or any other mods associated with Half-Life it's practically a universal timer made for that purpose.

Follow up video - https://www.youtube.com/watch?v=2y0kigcnbhw

I have now demonstrated that you can activate/deactivate the timer using zone or button triggers.

The source code is also now released on gamebanana's website

Link: http://gamebanana.com/maps/192990

OK I have decided to test out my timer by changing fps and I am surprised at the results.

Having a lower fps slows the timer down, while raising the fps above 100 runs the timer faster.

Hence which is why people had always recommend 100fps as the most suitable fps to run the game as the game runs well and have more of an accurate representation with the timer.

Is there a way to artifically limit the background environment to lock to a specific freamrate so that the timer does not go haywire and produce unpredictable results other than having 100fps as the guideline?

UPDATE: Release Candidate 5

Information

• Zone Based Activator
• .00 MS Display included with the MM:SS
• Reset Feature Included
• Clean Digital Display
• Low Entity Count

There are 241 Point Entities and 50 Texture Entities which is less than 300 therefore map making for speedruns is more enjoyable due to the low entity count and low memory usage with the triggers.

Release Candidate 5
Fixes

• Getting the 0,1,3,5,7 to work on the MS display works now along with 2,4,6,8,9 so all numbers when stopped will generate a random number from 0-9
• Coloured the Reset marker so you know exactly where the reset zone is and the start zones are
• Gap between trigger_multiples for start/reset zones have widened to ensure that the triggers do not overlap or override the start/reset sequence

Download Link: http://gamebanana.com/maps/192990

youtube video link : https://www.youtube.com/watch?v=qzs_mj6Idig

Release Candidate 5 in action.

It's basically this timer is like sports, whether skiing, running or driving is like a race to the finish line to see who gets there first.

Since the timer is zone-activated all it needs is a touch and go to start/stop the timer and whoever finishes the race first with the fastest time is deemed the winner.

Which is what the purpose of this timer is all about, for speedruns and racing to see who gets 1st position from a race.

However the timer is only designed for singleplayer speedruns but however others can compare speedruns from a single map to compare the times and whichever is faster is deemed the winner.

I have just found out one major issue with the timer. Since this is an entity timer which depends on FPS to tick properly.

The issue with my bhop maps is that they play other than the default 100fps which has caused an undesirable effect.

Meaning a higher fps count would make the timer cycle faster which results in a mismatch.

I have compared the timer with different fps and have noticed in huge deviations in terms of reliable times which means anyone who will change their fps to a higher value other than the default 100fps which is what valve recommends will result in the timer to tick faster meaning that their times appear to be much longer than a lower fps.

Players who have especially players who use the autobhop feature from amxmodx will no doubt will have a significant impact.

The players who use autobhop use an fps higher than 100 which in certain countries the standard is 125 others 131 and 150 in some countries.

The higher the fps is the faster the timer ticks which unfortunately will disadvantage the player who runs at a higher fps which results in a timer longer than it actually is.

The reverse is true, players that play at a lower than 100fps specifically 60fps or 30fps will have their timers run much slower meaning they get record to appear faster than the actual time itself.

However this has caused for me a backflip meaning if you want a reliable timer that will work you will unfortunately have to play at a specific framerate to get the benefit of it's accuracy.

That means a couple of things

• Players are forced to play at 100fps so if they want to make speedruns and want a reliable timer i have no doubt people will be forced to play at that framerate which is a problem. Players have a right to choose what framerates they play as long as everyone agrees to it and it has to be comparable at the framerates they play
• It discourages people from using a higher fps value other than 100 meaning if players use a higher framerate no doubt that their times will be worse
• Players who deliberately attempt to play other than 100fps by going lower will have the timer tick slower which will cause accuracy issues and performance slowdowns
• It discourages cheating, people who use 150fps for example will no doubt have a huge speed boost over a 100fps player but the consequence of that is the timer will tick faster which therefore makes their times actually worse than someone who plays at a legitimate framerate

If players want to play at a higher framerate than the default 100fps it will mean i have no doubt have to fiddle with the delays on the tick cycle to suit them.

Before i do that i just have tested my map out to find it takes approx 3.6 seconds from start to finish and i think i just got the timing right, all i need is an amxmodx plugin to confirm that.

Umm, did you test it on a dedicated server ?

I do believe that if you host a map on a listen server the framerate is capped to the client and can fluctuate thus producing varying results.
I advise you to get a Linux server and test it on that running at 1000fps (Windows has problems getting over 500fps) and see how everything runs.
Also try varying sys_ticrate and rates to see if that has any effect.

Amxx plugins do the timing by creating an entity and making it "think" (tick) every second (or any interval you want) then catching the event when it ticks and producing a callback to a function that increments the timer. Basically doing it the same way you are in your map through the entity system, though with way less entities. You can recompile the plugins to start the timer with your zone triggers rather than the button, i believe its 2 lines of code that register the fired event, look for timer_start and timer_stop entity names in the code.
I would love someone's with more low level engine experience input on this topic to clarify what would produce the difference.

I'm also not sure how much gsrc is decoupled from fps and tickrate, in source the tickrate measures events accurately assuming there is more fps on the server to give it enough "resolution" to produce a tick at the exact time every time and not miss by 10ms or so. However this inaccuracy is nowhere near as large as what you are getting, thus it suggests that you might have some errors somewhere.

The good thing you have mentioned about the ticrate is that its fixed on the server.

It is probably a better idea to have an amxmodx plugin instead to run the timer on the trigger_multiples for the timer but also I have found out too amxmodx has it's limitations, its ticrate delays are 30ms and not 10ms as you have stated which would have made the timer perfect but instead results in which would desync timers otherwise.

Even the author of amxmodx has admitted this problem which they are trying to fix. It's not just amxmodx but also sourcemod has this problem as well.

Source : http://www.bailopan.net/blog/?p=27

I've only tested the maps on a listen server which causes this effect, im not sure if it has the same effect or not on a dedicated server but I will let you know the results soon.

The timers in source engine is indeed accurate and you can do more with it on a single entity than the goldsource but however they both run identical, the only difference is that goldsrc requires more entities for it to work where source engine uses significantly less triggers which results in the source engine to run the timer efficiently and more effectively but both run from their respective engines 100%.

Even valve has gotten a timer to work on Half-Life so I know for a fact that the goldsrc engine is capable of getting a timer to work 100% perfect.

The reason I chose a zone-based activator via trigger_multiple than a func_button are for 3 reasons

• Efficency
• Accuracy
• Convenience to the players

Also I know that entities in general are not treated the same, some entities like func_train for example uses more game memory than infodecal as an example.

It's a good idea to experiment with the right entities to ensure that the timer not only runs 100% but also efficiently so that there is virtually no lag, I probably can somehow reduce the count of the triggers that can do this but so far all i know from the game engine itself that the timer is indeed working perfectly.

All it needs is suitable testing, I have compared it with a stopwatch over my phone and the game itself and it does indeed work, the game shows 3.62 seconds on the start/stop on my map and my phone i have compared it with shows about 3.67 - 3.68 so i know that its simular but i can never get a timer from a stopwatch to synchronize with the game timer perfectly so there is always some form on desynching with the accuracy of me using the stopwatch and getting the timer to work exactly at the same time.

Amxmodx would have been a good 3rd party tool to use to compare but unfortunately I have stated earlier it has timing issues which results in desync times with the maps and also it doesnt allow ms times to appear either which is a shame really.

Release Candidate 5b
Youtube Video: https://www.youtube.com/watch?v=qzs_mj6Idig

Information

• Zone Based Activator
• .00 MS Display included with the MM:SS
• Reset Feature Included
• Clean Digital Display
• Low Entity Count

There are 240 Point Entities and 50 Texture Entities which is less than 300 therefore map making for speedruns is more enjoyable due to the low entity count and low memory usage with the triggers.

Release Candidate 5b
Fixes

• Getting the 0,1,3,5,7 to work on the MS display works now along with 2,4,6,8,9 so all numbers when stopped will generate a random number from 0-9
• Coloured the Reset marker so you know exactly where the reset zone is and the start zones are
• Gap between trigger_multiples for start/reset zones have widened to ensure that the triggers do not overlap or override the start/reset sequence

Changelog (23/11/2016)

• Cleaned up a few unwanted entities
• Renamed a few variable triggers (the timer is no longer compatible with button activated timers from kreedz)
• Included a custom amxmodx timer with both the source code and a working plugin. However there is an issue with amxmodx with the delays starting the timer.
• See this link for the problem - http://www.bailopan.net/blog/?p=27
• All it needs from the devs from amxmodx is to change the value of the timer delay which you will require the source code of amxmodx and alter it to run the timer 100% accurate.

Issues

• If you play the map running other than 100fps the timer will desync and will cause the timer to tick faster/slower if any fps changes are done manually during playing the map.

It is recommended that the timer should be played at 100fps for the best results and to ensure 100% accuracy.

A workaround is on it's way to resolve timing issues in regards to speedruns for maps that are NOT designed for 100fps gameplay which is an issue that I am attempting to resolve.

Download Link: http://gamebanana.com/maps/192990

I know in the Half-Life game you can acutally change the ticrates for the listenserver or the client, by adding in a parameter at game launch.

Is is -ticrate 100 or -tickrate 100?

-sys_ticrate is the command line argument you use for that. Note that in addition to the server and client's framerate this also affects file downloads if you're not using a fast download server.

Thanks i just like to see with my timer i put a delay in the tick cycle as 0.001 to ensure that the timer does sync in with the game's tickrate.

All i know is that by default Half-Life's tickrate is NOT 100 but I think it is 64.

Iv'e never seen a gsrc server run at 64 or any multiple of 2 tickrate.
Eveyrone sets sys_ticrate to something like 10000.

In regards to tickrates, it works more or less like a clock.

From the Half-Life engine according to it's capabilities it works just like a clock.

We all agree as long as you follow the metric measurement that 1 tick is basically 1 frame generated as an output so having 100 ticks or cycles means 100fps will be generated per second, this works well with clocks so that the timer will always be synchronized and would work perfectly but here is a problem with that.

Today's monitors are locked at a specific refresh rate measured in Hertz which in computing terms is a form of timer or a clock that can be cycled to generate the fps output.

Ever wondered why people say in today's gaming is 60fps is the magical number for gaming? it's to do with monitor's refresh rate which is 60Hz.

That is fine with gaming in general, but it poses a problem if you include a timer.

All monitors run at 60Hz but the problem is that the refresh rate works exactly like a timer, if we try to get a timer to work perfectly the 60Hz refresh rate will NOT work as to opposed to 50Hz is what the european television standards recommends to all countries across the world.

If we all agree 100 milliseconds equals to 1 second that means the monitor has to cycle exactly 100 ticks in order for the screen to work properly meaning a monitor at 50Hz will always display a timer correctly, unfortunately the timer will never be displayed accurately in today's monitors because the refresh rate is locked at 60Hz.

The monitors work with fps by having a multiplier and a divider but it never adds or subtracts, so there is a debate going on with videos running at 25fps as to opposed to 30fps.

This has brought up a heated debate in the past and still is today being the television standard specifically PAL vs NTSC and it's not hard to understand why PAL is a better choice in terms of viewing experience but now all monitors have adopted the NTSC standard meaning PAL videos will no doubt run too fast on an NTSC monitor.

For gaming having a higher fps will mean a faster gaming experience but lower fps is a smoother choice but at 60Hz it means the timer will never be 100% accurate, the best it can go is 99.99% but never exactly 100%.

You ever wondered why scientists and researchers across the world apart from USA ever used monitors or television screens designed to run at exactly 50Hz.

If computer manufacturers today allows us customers to allow screens to run at 50Hz as well as 60Hz that would be perfect and timers will work fine, unfortunately we all have been accustomed to the US standard of fps and this affects timers and clocks in general as to why it can never be 100% accurate, it's what we actually see on screen that makes the difference.

Only if you have V-sync on and even then its questionable. Yes older games are more fps locked, Quake2 for example if you adjust your fps you will be able to traverse terrain that would otherwise be impossible to move through, i know this because i had binds for 3-4 different fps values to do so. Gsrc is in that gray area where the fps matters, but not as much. Push yourself over 400 you will see what i mean.

Then developers started separating these values apart, making the fps and tickrate independent of each other, to prevent "fps cheating". Games should be able to run at any fps you want and not influence the game logic in any way, because framerates vary wildly where as tickrates are constant producing the same result regardless of whether or not the display can show it right now or the next frame. This has become easier when games started using threads.

As for the Hertz, its actually pretty simple, American power grid runs on 60hz any old CRT TV screen will flicker at slighter difference from the grid frequency (25,50,100 etc...), the EU runs on 50hz so multiples of 30 Hz would flicker and cause a bad experience for users. Hence why there are weird rates such as 29,97fps to reduce the chance of flickering and provide a perceived 30fps. That's why different systems were developed. This is mostly historical stuff why this happened.

And to correct you there are 1000 ms in 1 second.

I have brought back this discussion over how to improve the overall quality of the timer, also to find a way to reduce entity counts, I have come across something.

Someone from sven co-ops site has found something about multi_managers that you can turn on/off the triggertargets inside a multimanager by putting a # and a value of 0-2 after you have set a delay which can be 0.

I am curious to know if anyone has gotten a hash wildcard to function inside the value field, i know you can have that inside multi_managers by using the same trigger names for it to work.

Link: https://sites.google.com/site/svenmanor/entguide/multi_manager

Is this a feature also built-in the half-life engine can i ask?

I am curious to know.

As soon as I tried to fiddle with the values of the multi_manager the multi_manager misbehaves.

https://s30.postimg.org/xdazr4r6p/mm_help.jpg

It's turning all of the triggers on/off when it should be specific triggers I wanted to turn on and off, is there a way to fix that?

I was wondering in order to reduce the entity count, is there a way to turn off triggers without the use of trigger relays using multimanagers, im focusing on func_wall_toggle that can be turned on/off without the use of trigger_relay.