Is it possible for a server to restrict connecting clients to a particular range of net_clientPrediction values?
Or perhaps to echo to the console when a client is outside of that range?
clientPrediction
A few server have restrictions on client prediction. A someone here’s bound to know how it’s done.
To answer my own question, it seems to be possible to (attempt to) restrict net_clientPrediction and net_clientMaxPrediction using punkbuster:
pb_sv_cvar net_clientPrediction IN -20 20
I don’t know about the OP, but some people are superstitious enough to believe that a low (even negative, which doesn’t make any sense) client prediction length somehow gives the clients some sort of unfair advantage, such as hits not getting registered or something. Don’t ask me how that could even be possible, because it shouldn’t be. Yet that doesn’t stop silly people from believing it.
From personal experience, using a negative CP (too lazy to type out fully) does infact make your more un-hittable. It shouldn’t make any sense and shouldn’t work but it just does. I went from using -20 CP, to 20 (i use all default net setting now) and noticed that i was taking more hits against the same players. I for one frown against people who abuse the setting to make yourself un-hittable as it gives you an unfair advantage and means you can aim less.
headdesk That’s not how client prediction works. The prediction length tells how many milliseconds the client will simulate the game state into the future, to reduce the visual effects of lag so that the motion of entities is perceived as smooth and user input appears responsive. The only thing it affects is the way you perceive the game. It shouldn’t have anything whatsoever to do with hit registration, what data the client sends to the server, or anything else, really. That would be completely stupid engine design. And to simulate a negative amount milliseconds would mean simulating backwards in time. Which makes absolutely no sense whatsoever. It would defeats the entire purpose of client-side prediction. I would guess that the game probably clamps the value to a minimum of 0 anyway.
This is the way it has been handled in all Quake/idTech games since Quake World. If you don’t believe me, look at the freely available source code of Quake II and Quake III (from the latter, the file cg_predict.c in particular). Here’s also a nice paper that describes in great detail the technique used in most games: http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf
This nonsense about players getting “unhittable” is like a cargo cult. I don’t know who came up with it, but people put that stuff in their configs and tell others that it does something amazing, e.g. becoming “unhittable” (which is much more likely caused by ordinary lag), and then people who are gullible enough will fool themselves into believing that it’s true. The only reason you’ve “noticed” some sort effect is because of confirmation bias. There’s no technical reason that I’m aware of that could cause you to become unhittable in this way. I’ve even tried it several times myself, and didn’t notice any difference whatsoever. Either it’s all in your imagination, or I’m not a strong enough believer in this sort of superstition.
My short post was meant to provoke I was kinda hoping OP would say why he wanted to limit it. jmp Jumped in (:D) with his reply, which is what I think also.
"I have to say this again because I have tried to play around with it before to see if it made any difference to me. Netclientprediction is something that runs on the client side to try and compensate for any delay in server updates. So, if I am tracking and shooting at X , and X is moving, my computer or client will try to deduce where X is going to move to based on x’s prior movement. This compensates for any ping differences ie. delay in getting the server updates as to where X actually is. However, if X has actually moved (based on what the server sees) to somewhere slightly different to what my client has predicted , then when I next get a server update that is what will count. So if I was shooting in the wrong direction based on MY CLIENT’S prediction , I will have missed X. If my client’s prediction is same as what really happened all the better for me.
So I set net_clientprediction at 0 , my computer makes no attempt to predict. If I set it at 20 it does so if there is no server update for 20 ms. If I set it at -20 then I have no idea what it can do with that but even if it does do something on my computer, once I receive a server update it makes no difference anyway. The server update overrules any prediction my client has made , regardless. Therefore, I cannot see how it can make any difference to anything regarding hitability, because the server overrules anyway. For sure, it can help you and your client to track better but I cannot logically work out how it can alter how you appear to anyone else or how hittable you are as only the server updates can count to someone else. The server does not predict.
If anybody can explain to me how it can make a player less hittable then I am all ears. Otherwise I think it is just placebo. Just because people use it doesn’t mean it actually does anything. As I have said before , using net limiters may well cause you to be “laggy” by keeping your good ping from the server (so you know whats happening) but slowing your ping TO the server (so people don’t know whats happening to you).
I will of course, stand corrected, once someone gives me a logical explanation as to how net_clientprediction can affect hittability. It is there to compensate higher ping players who do not get as frequent server updates as lower ping players. "
Above is a quote from this thread on Oh My™Strogg forums discussing netclientprediction.
I have also read (and quoted) that paper jmp has linked to. In my opinion, I don’t think it can make any difference. I am open to new insights however.
Thanks for your post, jmp.
I read that article some time ago and it gave me a much better understanding of how games like this work and why things on your screen get weird every now and then.
Dr. Funkenstein
Thanks for the link to the Valve paper, it was quite an interesting read.
I agree that, given the descrtiption of net_clientPrediction in the list of cvars, it shouldn’t be possible for changes in its value to directly affect a player’s ‘hitability’. Since you can see some network stats, including prediction times/frames, using net_showAsyncStats I decided to have a little play.
net_clientMaxPrediction seems pretty self explanatory. The client forces a maximum amount of time to predict while waiting for the next server update. If this prediction time is less than the packet round trip then the client lags until it receives the next frame. Provided MaxPrediction is set large enough to prevent any drops, net_clientPrediction values look like they are rounded to the nearest game tick, added to (or subtracted from) an estimate of (max) ping and displayed as ‘client prediction’. So altering net_clientPrediction by intervals of less than 33 looks like it’s a waste of time, but negative values do make sense.
For net_clientPrediction in [0,-32] the client prediction time is based only on the ping and is predicting over an interval 1 tick/frame less than the default settings. For net_cp < -32 the client prediction interval is less than the ping time but the client still appears to send most of the player inputs to the server. This leads to some moments where the player gets ‘pulled’ by the server update. Once the client is predicting 3 frames less than the default settings the player is pretty much paralysed.
So, have I learnt anything from this little jolly? No. Not much. It’s possible to set net_clientPrediction and net_clientMaxPrediction to some silly values. Also, these values do something, but it’s not obvious that it is anything beneficial to the player.
I have no idea how it works, but I do know that using a negative number does change some things, it may not have any effect on other people shooting you but if you set your CP to a negative value the lagometer seems to go crazy. Again, I can’t say what it does, but it would appear to have some effect on something since I could make the change and instantly see the lagometer change.
One of the things I suspect is that using a negative value changes it to some other value set by the game software. For all I know setting it to any negative value sets it to something huge, or maybe there is no limiting factor and the game doesn’t know how to interpret it generating some weird emergent behaviour.