Add timer variant that uses SysTime instead of CurTime

[TiberiumFusion]

All asynchronous control options in gmod (timer, util.Timer, and coroutine.wait()) use CurTime(). There are no options for managing asynchronous tasks using SysTime().

This means that if a server has 0 players and sv_hibernate_think is set to 0, all asynchronous tasks will freeze until a player joins. Furthermore, this means that addons that incorporate delay into their loading process will be frozen until a player joins. This can cause issues, since servers typically have 0 players while they are booting up.

Even if the server uses sv_hibernate_think 1, all options for asynchronous tasks are still subject to the server's timescale.

Real example of this being a problem: I just added a request for an "on http ready" event. As a workaround, I am using HTTP() to try to create requests, detect if they fail, then try again after a delay. This is part of an addon loading process, and so it occurs when the server has 0 players, and thus will be frozen until a player joins or until sv_hibernate_think is set to 1. This means the addon can only fully load AFTER the first player joins, which could be a problem (the addon needs to load BEFORE any players connect).

[viral32111]

Can't you just do RunConsoleCommand( "sv_hibernate_think", "1" ) at the start of your script, then RunConsoleCommand( "sv_hibernate_think", "0" ) once it's finished?

[TiberiumFusion]

@viral32111 That does not provide a means to create asynchronous tasks with SysTime(). Using sv_hibernate_think 1 is merely a dirty workaround and is still subject to server timescale.

[viral32111]

I know, I was just providing a hacky workaround to this:

This means that if a server has 0 players and sv_hibernate_think is set to 0, all asynchronous tasks will freeze until a player joins.

This is part of an addon loading process, and so it occurs when the server has 0 players, and thus will be frozen until a player joins or until sv_hibernate_think is set to 1. This means the addon can only fully load AFTER the first player joins, which could be a problem (the addon needs to load BEFORE any players connect).

Enabling sv_hibernate_think then disabling it later will allow those tasks to do whatever they need to do when the server initalises, instead of when the first player joins.

[viral32111]

Also what can you possibly be using timers for when the server is loading, why exactly do you have to delay your addon's code from loading? I've posted another workaround to that HTTP issue, I've been using it for years and it's never failed me. I'm sure there are plenty of other developers who also use this workaround.

[TiberiumFusion]

@viral32111 A particular addon of mine simply requires asynchronous task management to provide the best user experience. Certain procedures are best run when the server is booting, or when there are 0 players connected. And many types of procedures absolutely depend on real time and not an irregular, invented/ingame time.

This request is not about using duct tape and spit to work around gmod's limitations. It is about adding a very much baseline feature that is ubiquitous to every platform with an asynchronous task model. If I had a requirement to use the CurTime() based options (aka the only options), I would.

[thegrb93]

CurTime and SysTime are close enough that it shouldn't matter unless you are screwing with the time scale (why would anyone do that?). Leave sv_hibernate_think 1, my server idles empty at ~0% cpu with it so there's no reason not to.

[TiberiumFusion]

@thegrb93 CurTime is not the same as SysTime and that can be a problem in certain circumstances.

• CurTime does not advance until the gamemode starts. In other words, all timers are implicitly frozen during the entire boot process. If it takes 60 seconds for a server to boot, then a 5 second timer started at +0 seconds will actually fire at +65 seconds.
• Not all server owners use sv_hibernate_think 1. Some may have it disabled for good reason (other addon requirements). If my addon forcibly enables hibernate just to get a CurTime-based timer to work, it may very likely confuse or break other addons.
• CurTime starts at 0. SysTime is actual real time. Some delayed tasks may be sensitive to this.

Again, the point of this request is to petition for an asynchronous task model that uses real time, and not the delayed/irregular/not-realtime CurTime. Perhaps I am wrong, but I added this request on the assumption that it would be quite trivial to implement and result in a payoff of worthwhile value. Someone even added the Complexity: Low tag, which supports this idea.

If, for whatever reason, Facepunch somehow sees no value in a normal asynchronous task model, please just close the issue.