Host time precision

[ZehMatt]

What can't you do? Run a map for more than 6 hours without precision loss in the timestamp. This problem also exists in Garry's Mod and is probably something that should be avoided early on. I haven't actually tested this so this problem might not 'currently' exist, however when people use Time.Now for whatever purpose this can become a problem.

How would you like it to work? Being able to run a game instance for longer than 6 hours.

What have you tried? Nothing

Additional context In Garry's Mod this is only an issue for variables that store timestamps that are in the future, an alternative approach is to simply never do that but I don't know how much of the native code needs changing. Either way I thought I'm going to bring this up for discussion.

[garrynewman]

Let me know if you determine it's a problem

[FredyH]

This is still a problem. I tested this behaviour in sbox using host_timescale 10 and letting my server run for ~6 hours to get to the equivalent of roughly 3 days of uptime.

I wrote a very simple script that logs Time.Now every server.tick, here are the results: At the start it looks like this

2021/06/04 01:16:01.590 Generic Server: Current time: 20.000002 
2021/06/04 01:16:01.590 Generic Server: Current time: 20.016668 
2021/06/04 01:16:01.615 Generic Server: Current time: 20.033335 
2021/06/04 01:16:01.642 Generic Server: Current time: 20.050001 
2021/06/04 01:16:01.642 Generic Server: Current time: 20.066668 
2021/06/04 01:16:01.668 Generic Server: Current time: 20.083334 
2021/06/04 01:16:01.668 Generic Server: Current time: 20.1  

After the equivalent of ~3 days of uptime it looks like this

2021/06/04 01:01:59.116 Generic Server: Current time: 292520.47 
2021/06/04 01:01:59.139 Generic Server: Current time: 292520.47 
2021/06/04 01:01:59.139 Generic Server: Current time: 292520.47 
2021/06/04 01:01:59.164 Generic Server: Current time: 292520.5  
2021/06/04 01:01:59.189 Generic Server: Current time: 292520.56 
2021/06/04 01:01:59.189 Generic Server: Current time: 292520.56 
2021/06/04 01:01:59.213 Generic Server: Current time: 292520.56 
2021/06/04 01:01:59.237 Generic Server: Current time: 292520.6

At this stage the game is completely unplayable, since there isn't even enough precision to properly simulate things on the server. Clientside prediction does not work at all.

A quick video of what it looks like moving around on the server: https://streamable.com/uiup3u

It should also be noted that this starts being an issue after a way shorter time than 3 days, with the first choppyness probably being noticable at high framerates after only 16 hours or so.

[Leystryku]

I agree with @ZehMatt and @Fredy, this is a problem carried over from the original Source Engine. Chances are Time.Now internally uses gpGlobals->curtime which is most likely even in Source2 just a float. Changing it to a double should alleviate the issue.

[xaviergmail]

There was an okay amount of support for the same issue from Garry's Mod: https://github.com/Facepunch/garrysmod-issues/issues/2502

I support @ZehMatt's point of addressing this early on in the project (and perhaps even bringing the issue up to Valve themselves to have it fixed upstream would be even better..!) as this impacts any non-round-based games. This does not only apply to role-playing but plagues any game type which stays on the same map for extended periods of time (sandbox, open-world games etc)

[LeQuackers]

Depending on how physics sub-steps work in s&box, this could matter a lot actually; do they use the previous/current tick or the previous/current time for the calculations?

If they use previous/current time then that could cause an issue because the precision after 36 hours is only 1/64th of a second, so if you have, say, 4 physics sub-steps while running a 66 tick server, then each of those steps would have to fit in that restricted resolution, which would effectively be a single physics step per tick. At 9 hours Time.Now has a precision of 1/256th of a second, so you'd lose a few ticks every second, but it should still work server-side.

As for client-side, I haven't tested anything yet, but I'd guess high FPS would expedite the issue.