What does cl_noprediction do?

[Ivan]

What does this do? I don't see it documented on the wiki. I've heard there are more things that aren't properly documented on the zandronum wiki so, any takers? I think it'd be good to fill the gaps.

[madbringer]

If Zand's netcode is anything like Quake 3's, it would be responsible for client-side movement input prediction. IE, if set to 1, your client will wait for server packets to update the spatial locations of players instead of trying to predict them on it's own, compensating for packet loss due to high ping. I have no idea if that's the exact way this cvar works in this port, though.

[Torr Samaho]

Yes, that's essentially what cl_noprediction does. Except for debugging purposes, there should never be a reason to set this to 1. Perhaps I should just remove it from release builds to avoid confusion.

[madbringer]

(...) Perhaps I should just remove it from release builds to avoid confusion.

Probably for the best. I might be wrong on this, but I do believe that Q3 devs disabled this cvar in a patch at one point, just so people wouldn't toggle it by accident (or so malicious hosts couldn't toggle it remotely in clients by abusing autodownload or PunkBuster).

[Leonard]

there should never be a reason to set this to 1.

This helps a lot when the server experiences packet loss due to network issues.
I set it on so I actually know where I'm going instead of jittering all over the place.

[Torr Samaho]

I just checked, cl_noprediction has absolutely no effect in Zandronum, it's a leftover from ZDoom's net code. The CVAR I meant is cl_predict_players. "cl_predict_players 0" turns off the prediction and if you try this, you should immediately notice that there should be no reason to turn this off.

[Leonard]

I'm aware, I only posted in fear you would remove said CVar because it does have a valid use.
If the server experiences packet loss due to some sort of network issue and my movement commands aren't received then my client starts teleporting which is very disorienting.
I would rather trade the prediction with a low ping for no uncontrollable jitters.
I'm aware of what the CVar does and if you're afraid of people misusing it you could simply make it not archive (if that's not already the case).

[Torr Samaho]

If the server experiences packet loss due to some sort of network issue and my movement commands aren't received then my client starts teleporting which is very disorienting.
I would rather trade the prediction with a low ping for no uncontrollable jitters.

Interesting. Did you ever encounter a situation where turning off the prediction improved the situation and the game was still enjoyable?

[madbringer]

Whatever the cvar's name, from my experience with how Q3 handles the purpose of it, like Torr said, there should never be any reason to toggle it outside of debugging. It might be useful for LAN games to eliminate prediction errors, server packets would arrive before there was any need for compensation, but it couldn't possibly have any effect while the server is experiencing latency trouble aside from magnifying said trouble. Packet routing is not magic, it's physics and math.

[Leonard]

but it couldn't possibly have any effect while the server is experiencing latency trouble aside from magnifying said trouble. Packet routing is not magic, it's physics and math.

I'm very obviously not talking about latency issues..

and the game was still enjoyable?

Admittedly I only had to use it on very crappy servers but randomly freezing was definitely better than randomly teleporting.

[madbringer]

but it couldn't possibly have any effect while the server is experiencing latency trouble aside from magnifying said trouble. Packet routing is not magic, it's physics and math.

I'm very obviously not talking about latency issues..

You are, whether you know it or not. You said it helped you to "know where you're going instead of jittering all over the place." It does not affect that at all. To be precise, it would make other players warp around with sufficient latency, it wouldn't affect any of your own input, anything your own client sends to the server. It's a client-side variable that changes how your client handles the information it receives from the server (or chooses to ONLY listen to that information and ignores the prediction mechanism), not the other way around.

[Leonard]

To be precise, it would make other players warp around with sufficient latency, it wouldn't affect any of your own input

No, that's not how prediction works in zandronum.
Are you sure we are talking about the same thing here?
We're talking about client prediction which is different from unlagged.

if set to 1, your client will wait for server packets to update the spatial locations of players instead of trying to predict them on it's own, compensating for packet loss due to high ping.

It's the complete opposite, only the client's own position is predicted and nothing else.

[Ru5tK1ng]

Clearly the problem is one guy is speaking Zandronum and the other is yapping Q3A. Obviously two different things.

[madbringer]

To be precise, it would make other players warp around with sufficient latency, it wouldn't affect any of your own input

No, that's not how prediction works in zandronum.
Are you sure we are talking about the same thing here?
We're talking about client prediction which is different from unlagged.

if set to 1, your client will wait for server packets to update the spatial locations of players instead of trying to predict them on it's own, compensating for packet loss due to high ping.

It's the complete opposite, only the client's own position is predicted and nothing else.

If that's the way it works here then fair enough and my bad, but a client predicting itself to... itself? Why would your client try to predict your own movement input? That doesn't make a lot of sense to me. Could you elaborate on the mechanics?

Clearly the problem is one guy is speaking Zandronum and the other is yapping Q3A. Obviously two different things.

That very well may be the case, but I don't think Zand's and Q3's netcodes are so drastically different. I think what this is, is, either I'm misunderstanding what this cvar does or Leonard is wildly confused about what client-side prediction is.

[Konda]

I've experienced both problems at different times: sometimes, usually when someone on my network is downloading something big, i can move normally on the server but everyone else teleports around from my view. From the other players' views, I'm the one who teleports around.

But I've also had cases when I myself would teleport around too, but this is on very rare occasions, usually while grandvoid is having a stroke or when some faggot tries to "stress test" a non-grandvoid aow server by spamming caches in one spot for 20 minutes.

And on even rarer occasions, when my own isp is having a stroke, I'd be the only one to teleport around while everyone else moves normally from my view, sometimes I even stay frozen in place with "connection interrupted" while everyone else moves normally.

So maybe some network rocket scientist can explain these 3 scenarios using fnacy terms like "unlagged" and "prediction"?

[Lollipop]

The scenario where you are stuck in place but everyone moves normally around you also includes that any message you try to say in the chat doesn't arrive, right? A clear sign that you have right around 0 upload to the server, but the server's traffic to you gets through without problems, allowing you to see the movement of the other players.

Everything lags usually means a problem for the server to keep up. Or your client.

As you have mentioned, when you yourself is downloading something big you have problems with the other players' movement. This is because as you are downloading you are requesting packets that are sent to you which take up bandwidth, probably sent with TCP, but inevitably causes some zan server->client packets to be lost in your router as the aggregate of your network traffics converge to 100% usage. When you don't receive packets reliably the update rate for the individual player position gets updated less reliably, with a lower frequency, causing the jittery user experience.

The solution to all of these jitter problems? Better Internet. If that doesn't help, also upgrade server or client hardware, whichever is the bottleneck.
Theoretical improvement of UDP datagram usage would also be helpful, but that is an engine thing. I could blabber a bunch about this a bunch but I don't think that is quite necessary.

EDIT: In hindsight I didn't use those two terms, but they aren't exactly necessary to explain the described scenarios.