So...I've done a lot of reading on cl_smooth/cl_smoothtime and fps_max, and I have to say, I'm still stumped.
#1: the most controversial: fps_max
The case for fps_max 0:
The higher your FPS is, the less input lag there will be, the more up-to-date the frames displayed on your monitor will be (whatever its refresh rate), and the more up-to-date and consistent your reports to the server will be. Keep in mind that most setups' minimum FPS will be dramatically lower than their average FPS--capping at the minimum for no fluctuation would mean a much lower framerate all the time.
The case for fps_max [minimum FPS]:
The Valve Developer Wiki says that consistent FPS is preferable to variable FPS for hit registration--they don't say why. This bothers me...how exactly does framerate variability affect hit registration?
Annnd #2: cl_smooth and cl_smoothtime
Here's what cl_smooth is:
After 100 milliseconds, the client will receive the server snapshot that contains the changes based on the user command he predicted earlier. Then the client compares the server position with his predicted position. If they are different, a prediction error has occurred. This indicates that the client didn't have the correct information about other entities and the environment when it processed the user command. Then the client has to correct its own position, since the server has final authority over client-side prediction. If cl_showerror 1 is turned on, clients can see when prediction errors happen. Prediction error correction can be quite noticeable and may cause the client's view to jump erratically. By gradually correcting this error over a short amount of time (cl_smoothtime), errors can be smoothly corrected. Prediction error smoothing can be turned off with cl_smooth 0.
Predicting an object's behavior only works if the clients knows the same rules and state of the object as the server. That's usually not the case since the server knows more internal information about objects than the clients do. Clients see only a small part of the world and just get enough information to render objects. Therefore, prediction works only for your own player, and the weapons controlled by you. Proper prediction of other players or interactive objects is not possible on the client at this point.
Here's what Chris has to say about cl_smooth:
http://etf2l.org/forum/customise/topic-10435/page-57/#post-238353
If you’re not getting prediction errors, cl_smooth does absolutely nothing. Nil. Nada.
It’s inadvisable to have it on because it will make your aiming inaccurate for the smoothing period, and besides it would be unnoticeable (any perceived non-negligible difference will be placebo) at vales less than 0.05.
Alright, so it's only relevant when there are prediction errors...which is constant, if you monitor that with cl_showerror, and if I understand correctly, without any smoothing there will be hitches...which would throw my aim off.
How will smoothing make my aiming inaccurate, exactly?
Would leaving cl_smooth on but setting cl_smoothtime to something like .05 be a good compromise?
Thanks in advance to anyone that lends helpful discussion.
So...I've done a lot of reading on cl_smooth/cl_smoothtime and fps_max, and I have to say, I'm still stumped.
[u]#1:[/u] the most controversial: [b]fps_max[/b]
The case for [i]fps_max 0[/i]:
The higher your FPS is, the less input lag there will be, the more up-to-date the frames displayed on your monitor will be (whatever its refresh rate), and the more up-to-date and consistent your reports to the server will be. Keep in mind that most setups' minimum FPS will be dramatically lower than their average FPS--capping at the minimum for no fluctuation would mean a much lower framerate all the time.
The case for [i]fps_max [minimum FPS][/i]:
The Valve Developer Wiki says that consistent FPS is preferable to variable FPS for hit registration--they don't say why. This bothers me...how exactly does framerate variability affect hit registration?
Annnd [u]#2[/u]: [b]cl_smooth[/b] and [b]cl_smoothtime[/b]
Here's what cl_smooth is:
[quote]After 100 milliseconds, the client will receive the server snapshot that contains the changes based on the user command he predicted earlier. Then the client compares the server position with his predicted position. If they are different, a prediction error has occurred. This indicates that the client didn't have the correct information about other entities and the environment when it processed the user command. Then the client has to correct its own position, since the server has final authority over client-side prediction. If cl_showerror 1 is turned on, clients can see when prediction errors happen. Prediction error correction can be quite noticeable and may cause the client's view to jump erratically. By gradually correcting this error over a short amount of time (cl_smoothtime), errors can be smoothly corrected. Prediction error smoothing can be turned off with cl_smooth 0.
Predicting an object's behavior only works if the clients knows the same rules and state of the object as the server. That's usually not the case since the server knows more internal information about objects than the clients do. Clients see only a small part of the world and just get enough information to render objects. Therefore, prediction works only for your own player, and the weapons controlled by you. Proper prediction of other players or interactive objects is not possible on the client at this point.[/quote]
Here's what Chris has to say about cl_smooth:
[quote]http://etf2l.org/forum/customise/topic-10435/page-57/#post-238353
If you’re not getting prediction errors, cl_smooth does absolutely nothing. Nil. Nada.
It’s inadvisable to have it on because it will make your aiming inaccurate for the smoothing period, and besides it would be unnoticeable (any perceived non-negligible difference will be placebo) at vales less than 0.05.[/quote]
Alright, so it's only relevant when there are prediction errors...which is constant, if you monitor that with cl_showerror, and if I understand correctly, without any smoothing there will be hitches...which would throw my aim off.
How will smoothing make my aiming inaccurate, exactly?
Would leaving cl_smooth on but setting cl_smoothtime to something like .05 be a good compromise?
Thanks in advance to anyone that lends helpful discussion.
almost all of the info on source netcode is completely speculative as to what is "good". a dev's description of how something works vs how it plays in practice can be completely different (devs tend to suck real bad at video games)
there was a command in the q3 engine called cl_smoothclients (xerp in cpma) that existed the entire time quake was out, and was "discovered" in ~2007 that it basically increases your lg by 5+%, meaning the random people who had it on by accident were playing at a big advantage for years. It was serverlocked when ql came out.
the dif between quake and tf2 is that the accuracy statistics are everywhere, so it's very easy to have an objective measurement about how cvars affect your performance. if some accuracy tool existed for tf2 any of these kind of questions could be answered much quicker. although the only good trial weapon really is scout pistol.
almost all of the info on source netcode is completely speculative as to what is "good". a dev's description of how something works vs how it plays in practice can be completely different (devs tend to suck real bad at video games)
there was a command in the q3 engine called cl_smoothclients (xerp in cpma) that existed the entire time quake was out, and was "discovered" in ~2007 that it basically increases your lg by 5+%, meaning the random people who had it on by accident were playing at a big advantage for years. It was serverlocked when ql came out.
the dif between quake and tf2 is that the accuracy statistics are everywhere, so it's very easy to have an objective measurement about how cvars affect your performance. if some accuracy tool existed for tf2 any of these kind of questions could be answered much quicker. although the only good trial weapon really is scout pistol.
Thanks for the reply.
I think I'm going to go with fps_max 0 and cl_smooth 0.
Thanks for the reply.
I think I'm going to go with fps_max 0 and cl_smooth 0.
I would still do an fps cap, if your computer renders above 900 fps, then Source breaks. I have mine set to 500.
I would still do an fps cap, if your computer renders above 900 fps, then Source breaks. I have mine set to 500.
i cap my FPS in source games as well. i use 264.
it's weird because if you have too much FPS the game feels faster? and also if it fluctuates too much it might screw with you in terms of consistency so capping it is a safe bet.
i cap my FPS in source games as well. i use 264.
it's weird because if you have too much FPS the game feels faster? and also if it fluctuates too much it might screw with you in terms of consistency so capping it is a safe bet.
hookyI would still do an fps cap, if your computer renders above 900 fps, then Source breaks. I have mine set to 500.
Hm, yeah, I see no downside to such a high cap. Might as well.
How does the Source engine "break"?
[quote=hooky]I would still do an fps cap, if your computer renders above 900 fps, then Source breaks. I have mine set to 500.[/quote]
Hm, yeah, I see no downside to such a high cap. Might as well.
How does the Source engine "break"?
stabbyhookyI would still do an fps cap, if your computer renders above 900 fps, then Source breaks. I have mine set to 500.
Hm, yeah, I see no downside to such a high cap. Might as well.
How does the Source engine "break"?
I don't know in what different ways it can break, but if you play a map on localhost the game just speeds up, as if you're messing with host_timescale.
[quote=stabby][quote=hooky]I would still do an fps cap, if your computer renders above 900 fps, then Source breaks. I have mine set to 500.[/quote]
Hm, yeah, I see no downside to such a high cap. Might as well.
How does the Source engine "break"?[/quote]
I don't know in what different ways it can break, but if you play a map on localhost the game just speeds up, as if you're messing with host_timescale.
skeej i don't know if that's just a localhost thing or just a high fps thing. cause when i play surf maps and get 1000+ FPS i get a similar effect and i don't think it has to do with localhost but more with the fact that there's less going on and you have that high fps messing with your game
skeej i don't know if that's just a localhost thing or just a high fps thing. cause when i play surf maps and get 1000+ FPS i get a similar effect and i don't think it has to do with localhost but more with the fact that there's less going on and you have that high fps messing with your game
About smoothing:
If there was a prediction error, the object (aka player) whose movement and therefore position was mispredicted is now at a different position on the client side than on the server side.
With smoothing off the playermodel will be shown at the correct position on the next frame that is rendered after the new snapshot arrived resulting in a "warp" instead of a smooth movement.
With smothing on the playermodel's movement will be smoothed over a few frames/snapshots so that the model is at the correct position (the one on the server/snapshot) after the time set cl_smoothtime. This means that the model won't warp but it won't be at the correct position and the hitreg will be a bit off until the smooth is complete.
Black is the position on the server, red is smoothed, green is not smoothed
http://i.imgur.com/qeR5FiW.png
The client predicted the player to still be going in a straight line, which turned out to be wrong. Now if you have smooth enabled and hit him, you don't actually hit him, because he's at a different position on the server. Without smoothing he'll warp when the prediction error gets corrected but after that a hit is a hit again.
About fps_max:
In theory you get the best hitreg when frames and snapshots are in sync. If you want to avoid screen tearing to the theoretically best fps cap for 66 rates and 60Hz or 120Hz is 600 (exactly 9 frames per snapshot, 10 or 5 per monitor refresh) and. Since it is almost impossible to get a high and stable framerate in TF2 I'd rather cap for the monitor (120, 240 or something like that) than for the hitreg because screen tearing is far worse imho, but that's just me.
About smoothing:
If there was a prediction error, the object (aka player) whose movement and therefore position was mispredicted is now at a different position on the client side than on the server side.
With smoothing off the playermodel will be shown at the correct position on the next frame that is rendered after the new snapshot arrived resulting in a "warp" instead of a smooth movement.
With smothing on the playermodel's movement will be smoothed over a few frames/snapshots so that the model is at the correct position (the one on the server/snapshot) after the time set cl_smoothtime. This means that the model won't warp but it won't be at the correct position and the hitreg will be a bit off until the smooth is complete.
Black is the position on the server, red is smoothed, green is not smoothed
[IMG]http://i.imgur.com/qeR5FiW.png[/IMG]
The client predicted the player to still be going in a straight line, which [i]turned[/i] out to be wrong. Now if you have smooth enabled and hit him, you don't actually hit him, because he's at a different position on the server. Without smoothing he'll warp when the prediction error gets corrected but after that a hit is a hit again.
About fps_max:
In theory you get the best hitreg when frames and snapshots are in sync. If you want to avoid screen tearing to the theoretically best fps cap for 66 rates and 60Hz or 120Hz is 600 (exactly 9 frames per snapshot, 10 or 5 per monitor refresh) and. Since it is almost impossible to get a high and stable framerate in TF2 I'd rather cap for the monitor (120, 240 or something like that) than for the hitreg because screen tearing is far worse imho, but that's just me.
setsul you are a genius apparently
setsul you are a genius apparently
A good example of when smoothing comes into play is when you rocketjump or get airblasted. If it's disabled, and you have a high enough ping, you'll notice yourself teleport into the knockback. Smoothing makes it less of a teleportation.
A good example of when smoothing comes into play is when you rocketjump or get airblasted. If it's disabled, and you have a high enough ping, you'll notice yourself teleport into the knockback. Smoothing makes it less of a teleportation.
im dumb
should i have it on or off
im dumb
should i have it on or off
Also cl_smooth only applies to yourself. Not other players. THIS IS A NEW POST BECAUSE IT'S PRETTY IMPORTANT INFORMATION IF PEOPLE ARE GONNA BE TALKING ABOUT IT AND STUFF
Also cl_smooth only applies to yourself. Not other players. THIS IS A NEW POST BECAUSE IT'S PRETTY IMPORTANT INFORMATION IF PEOPLE ARE GONNA BE TALKING ABOUT IT AND STUFF