Server time vs. Host Time in NQ?

[Baker]

Quake has so many different "times".

1. Realtime ... only should be used for cursor blink and such. Except network messages. Supposedly degrades after a very extended period of time like days (is this true?) due to floating point precision loss.

2. Host_time ... the virtual time which can be paused and such. Time only advances if a frame is run. Demo playback always uses this. Host time might even be able to go backwards and a I bet it does with engines supporting demo rewind. (JoeQuake, etc.)

3. Server time??

I do not know the difference between host_time and server_time and it looks like both the host and server use each.

And how does the host_time differ from the server time?

[mh]

Host time has actually got more in common with realtime. realtime constantly advances even when disconnected or when the server is paused and so does host_time. The key difference is that host_time is subject to 72 FPS filtering whereas realtime is not. So if you want to do any time-based stuff before the Host_FilterTime check you'd use realtime, if you want to do any after you can use either.

host_time is a bit odd in that it's only used for the spinning Q in the menus and for the VCR stuff. The Q can be switched to realtime with no impact whatsoever, and I don't think anybody cares too much about the NQ VCR stuff.

realtime is a bit odd in that Con_NotifyBox can also change it's value. Con_NotifyBox is however completely unused in the released source - at least for Win/GL. I guess it's old DOS Quake legacy stuff.

The difference between host_time and sv.time is that host_time can advance even when disconnected or the server is paused. sv.time obviously doesn't advance when the server is paused and is reset to 1.0f each time a new map starts.

cl.time is updated by svc_time messages (via a slightly roundabout way), either read from demos or from a server. It doesn't advance when the server is paused (and you can't pause a server that's not running locally so it always advances when connected over a network or in demos).

Think that's roundabout it. Head hurting yet?

[Mexicouger]

I just noticed Bakers post count is 2010

Anyways, what about Sys_DoubleTime();? How is that put in context

[Spike]

Sys_DoubleTime() returns the new realtime value. You can call it to get the current time, rather than just the time at the start of the frame.

[Baker]

I didn't know if there was a true difference of when or where host time incremented versus server time (or exceptions or what not). Next time I get the chance, I'm going to try to unwind how demo rewind uses yet another time variable.

Just looking to get a handle on all of these timers and any nuances.

I still don't like how a lot of calculations uses host_time and some use sv.time ... if they are essentially the same for the purposes of, say, physics and QuakeC, shouldn't all those parts of the source use one or the other?

Well, I'll continue to looking at the code for my own understanding and try to discern if a good reason for such a distinction exists.

[mh]

Well they're not really the same because host_time still advances even when the server is paused, whereas sv.time doesn't. sv.time is reset to 1 when a new server (i.e. map) starts, host_time isn't.

There is, IMO, no reason whatsoever to prefer host_time over realtime in any function that gets called after Host_FilterTime. They should both have the same value at that stage in execution. The only difference is that host_time advances in increments of (1 / host_maxfps.value) whereas realtime advances continuously.

The bigger problem is functions that use realtime instead of cl.time (like sky or water animations), or functions that use (cl.time - cl.oldtime) as a "frametime" (which may not be correct if the function didn't get called the previous frame - it should monitor it's own "oldtime" instead), or even functions which use host_frametime (they completely ignore the fact that timedemos might be running at a faster rate).

Each function that uses any kind of a "frametime" should have it's own timer, with it's own "oldtime", and base it's frametime on the difference between it's master time (which should be realtime, sv.time or cl.time) and it's oldtime. That way everything stays nice and consistent and running at the correct rate.

[Spike]

The bigger problem is functions that use realtime instead of cl.time (like sky or water animations), or functions that use (cl.time - cl.oldtime) as a "frametime" (which may not be correct if the function didn't get called the previous frame - it should monitor it's own "oldtime" instead), or even functions which use host_frametime (they completely ignore the fact that timedemos might be running at a faster rate).

cl.time is dependant upon network latency. If you are on a connection with periodic lag spikes (low spikes of 0.1 secs or so), your sky will suddenly judder between the high and low network latencies. Even worse is when you're on a conjested/buffered network and get your packets in bursts. Better to base it off a local timer and optionally implement pausing and demo speeds clientside, at least for unimportant things like sky and water.
Having said that, the same is true for interpolation - and that becomes much more messy, although to a certain extent, its less noticable with interpolation as its generally less linear in the first place.

Remember, realtime is a double, and has limited precision with long up times. sv.time is a float which is reset at the start of each map in order to preserve timing precision. But realtime is not. Client times are less important as you're not likely to leave a client running for more than 2 days (Public servers should generally change map after a few days to avoid physics bugs).

[mh]

In NQ both cl.time and sv.time are also doubles. In fact all times are doubles and they only get "mixed down" to float for transmission across the network.

cl.time advances by host_frametime before even reading any server messages, and then may be clamped to between the times the last two messages arrived at.

[Baker]

cl.time is dependant upon network latency. If you are on a connection with periodic lag spikes (low spikes of 0.1 secs or so), your sky will suddenly judder between the high and low network latencies. Even worse is when you're on a conjested/buffered network and get your packets in bursts. Better to base it off a local timer and optionally implement pausing and demo speeds clientside, at least for unimportant things like sky and water.

The plot thickens.

I typically change things like the sky time to use client time [demo rewind is one reason], but haven't thought to test them online and typically do the testing single player (which isn't going to expose these issues.)

Hence, why I started this thread. To get input on infos I am not thinking about.

Some of these complications were not things I was thinking about.

+1 testing plan