The wait is in there because there were issues with timers running over eachother (0.0 into a 0.0 into a 0.0... etc). At least this is my memory of the issue when I proposed the same thing many years ago.

The wait is in there because there were issues with timers running over eachother (0.0 into a 0.0 into a 0.0... etc). At least this is my memory of the issue when I proposed the same thing many years ago.

If this is the case, it should be as simple as setting the think time to the tick interval?

Please consider keeping things like this in the same issue if they're directly related to one another. I'm closing this in favour of #2009 where the discussion should continue around this if desired.

The wait is in there because there were issues with timers running over eachother (0.0 into a 0.0 into a 0.0... etc). At least this is my memory of the issue when I proposed the same thing many years ago.

Do you know of an easy way to make a test case for this? I'm not sure what you mean, do you mean multiple timers running at 0.0? One single timer running at 0.0 executing infinitely? Or wha? I think regardless these could be easily solved by just explicitly limiting timers to <tickinterval> which is probably what users expect anyway

E.g. something like

...
        // RunFrame();

	if (g_fUniversalTime >= g_fTimerThink)
	{
		RunFrame();
		g_fTimerThink = CalcNextThink(g_fTimerThink, gpGlobals->interval_per_tick);
	}
...

The wait is in there because there were issues with timers running over eachother (0.0 into a 0.0 into a 0.0... etc). At least this is my memory of the issue when I proposed the same thing many years ago.

Do you know of an easy way to make a test case for this? I'm not sure what you mean, do you mean multiple timers running at 0.0? One single timer running at 0.0 executing infinitely? Or wha? I think regardless these could be easily solved by just explicitly limiting timers to which is probably what users expect anyway

CreateTimer, in that callback, create another timer, and keep doing that. It may have been from when time was a float as opposed to a double, but do they run properly?

dammit, accidentally force pushed over that work

Documenting some discussion that happened on Discord:

What worries me here is that previous reliance on timer behavior definitely will cause breakage. Adding a timer flag, something along the lines of TIMER_FLAG_TICK_PRECISE, will expand functionality here for higher precision timers without breaking bcompat behavior-wise.

Requested KyleS to take a look, effort here was to maintain "dont pay for what you don't use"

Essentially we just calculate ToExec in different ways depending on the list the timer is in