Open TiberiumFusion opened 4 years ago
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?
@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.
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.
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.
@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.
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.
@thegrb93 CurTime is not the same as SysTime and that can be a problem in certain circumstances.
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.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.
All asynchronous control options in gmod (
timer
,util.Timer
, andcoroutine.wait()
) useCurTime()
. There are no options for managing asynchronous tasks usingSysTime()
.This means that if a server has 0 players and
sv_hibernate_think
is set to0
, 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 untilsv_hibernate_think
is set to1
. 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).