Hibernation mode

[Exmirai]

Caelum's request:
https://jkhub.org/topic/7420-will-pay-for-some-openjk-code-edits/

[ensiform]

Please don't store the cvar old value in a std::string

Plus you didn't include !

Cvar_SetValue does exist so you can save values. Might be better to not make extra globals and put them in a server structure. It's still very hackish to actually change the sv_fps value though. It may trigger issues with the client snaps limiting to server fps.

I would hold off on merging this right now because there's a patch for com_dedicated_sleep that may also be useful.

[ensiform]

Just add a float of the old value instead of the string???

[Caelish]

I can't comment on code quality, but since I asked @EpicLoyd to code this, I figured I'd give a little bit of background.

What this does is reduce sv_fps to 1 when a server doesn't have any humans online for sv_hibernatetime seconds, then revert it to the previous value when a human connects. It saves a lot of CPU for servers which run a lot of bots, or when a lot of different servers are hosted on a single machine, as is the case with my hosting. I've been running it in production without any issues for several days on 30ish instances of openjkded.i386.

Here is the impact it had on one of my servers:

(disregard the CPU spikes - those are a daily backup cron job)

Afaik, client snaps will not be limited unless sv_snapsmax is set, and as said, I haven't received any reports of issues about this whatsoever. By default, sv_hibernatetime is 0, so the server does not hibernate at all unless the server owner sets it to.

[ensiform]

I also think the chrono lib can be avoided since there is already timer functions using milliseconds in the engine.

@Caelish the code quality is important for here though too so we should make sure it's up to par before merging.

[Caelish]

@ensiform I completely agree. Wasn't trying to imply otherwise, sorry if it came across like that. I do realise the importance of good code, I just don't know any C (or C-ish languages) and thus can't say anything sensible about code quality here. =P

[AlexCS1337]

Is this still wip?

[ensiform]

Caelum might use it but we don't. Too WIP and not very code style friendly.

[AlexCS1337]

Ah

[ensiform]

I'd like to close this and have hibernation mode just be a long shot request issue instead.

[bartrpe]

This looks pretty dead and seems like nobody was against closing it? Doesn't really seem like it fits the idea of OpenJK not including specific new features either way, I guess.