Chris just added this to his FPS configs today;

"//cl_interp 0 // We let cl_interp_ratio do the limiting, this just sets it to the minimum available."

Does this mean using an interp such as 0.0152 or 0.033 is now inferior?

No, it's still entirely based on your preference. 0 adds no compensation.

Unless their was something in the actual Steam update that changed how cl_interp works.

setting cl_interp 0 means that if you join a server, your interp will be set at the lowest possible setting. I've seen 0.0149 before but normally 0.0152 is the lowest.

*edit* The lowest setting that the server allows.

Deathanchor wrote:

No, it's still entirely based on your preference. 0 adds no compensation.

Unless their was something in the actual Steam update that changed how cl_interp works.

cl_interp 0 means that the interpolation period will be (cl_interp_ratio/cl_updaterate) seconds long

with this setting, cl_interp_ratio 1 will allow the client to see the most accurate version of the game world that the server has sent as it is rendered by the client

the only reason you wouldn't want cl_interp 0 and cl_interp_ratio 1 is if you are experiencing packet loss or your cl_updaterate is too high for the server to handle

esea locks all these interp commands down, so it doesn't really matter

so put this in your tf2 config and you'll be fine

cl_cmdrate "66"
cl_updaterate "66"
cl_interp "0"
cl_interp_ratio "1"
rate "60000"

this obviously needed an alt.

set your rate to something ridiculously high so it goes to the servers max rate, most advantageous for you

hello i would just like to point out that interp ratio 1 is not "more accurate" than interp ratio 2

if you play hitscan interp ratio 2 is generally a better choice, the main reason for using interp ratio 1 is for projectile classes because your projectiles are not interpolated on the client which gives you that rocket "delay" when you shoot

ukm wrote:

hello i would just like to point out that interp ratio 1 is not "more accurate" than interp ratio 2

if you play hitscan interp ratio 2 is generally a better choice, the main reason for using interp ratio 1 is for projectile classes because your projectiles are not interpolated on the client which gives you that rocket "delay" when you shoot

I thought interp ratio 2 wasn't allowed on most servers or something?

dont think so, i've used 33ms lerp for ages and rarely seen it clamped

ukm wrote:

hello i would just like to point out that interp ratio 1 is not "more accurate" than interp ratio 2

that said, cl_interp_ratio 2 is fine and no one would notice a difference in hitscan shot registration. I would personally use 2 online and 1 on lan if i could. I'm not sure why esea chooses to lock client interpolation settings at all except on lan

#12 they just mimicked their css rate settings, everyone is forced to use the same things so people aren't shooting people from around corners

meb wrote:

ukm wrote:

hello i would just like to point out that interp ratio 1 is not "more accurate" than interp ratio 2

given that, at rendering time, a client using cl_interp_ratio 1 would be interpolating using only the last retrieved server frame instead of the last two, i believe it is 'more accurate' or in sync with the server's version of the game world

That's not how interpolation works...

Interpolation is used because your client renders frames at a rate that doesn't necessarily match the server's tick rate, which means it has to "guess" where entities are.

The client also renders on a delay equivalent to your lerp. So with a lerp of 33ms, if the server is currently rendering a tick at t=33ms your client is actually rendering a frame at 0ms - when you play a goldsrc/source game you are technically playing slightly in the past with respect to the server.

So for example the server will render two gamestates at t=0ms and t=15.2ms, but your client might generate a frame at t=10ms because your framerate doesnt match the server's tick rate. Interpolation means that the client takes the two known positions at 0ms and 15.2ms and "guesses" where the entity was at 10ms. You -need- at least 2 game updates buffered in order to do this interpolation

If you're playing at interp_ratio_1 it means that you will be playing exactly 2 gamestates behind the server (at 66 updaterate lerp would 15.2ms, so you'll get the second gamestate exactly as it's needed). If any updates get delayed or dropped due to latency/choke/packetloss though then you'll only have 1 update which means the client can't do interpolation. It then has to extrapolate. So in the previous example it would only be able to look at position/velocity at t=0ms and then assume that the entity doesn't change direction. If the entity actually switched directions at t=2ms then obviously the position your client renders will be wrong. This can lead to bad reg or "jitter" of player entities as the position gets corrected later on.

Increasing your lerp means that your client is playing further in the past but the server already compensates for that delay (when you send a +attack command it will rewind back to the time attached to your command and check for hitreg at that time).

Now the client also does prediction of local user commands which is why your own movement and actions can be smooth. If you pressed left and your client waited for that command to go to the server and the server to update your position and then send it back to you, then obviously there would be weird input delay. So instead the client just predicts the location where the server will put you (which is generally very accurate since your client obviously knows what you're pressing, it only will be off if your commands don't make it to the server due to packetloss).

BUT the client for some reason that i don't fully understand doesn't predict projectile locations, just your player location. So when you fire a rocket it -does- wait for the +attack command to hit the server and the server to update the rocket position and send it back to your client. So when you have a high lerp (i.e. you're playing way behind the server) then the rocket takes a long time to appear on your screen. This is why a lower interp makes projectiles feel much smoother and is generally preferred by soldiers/demos.

so just use meb rates with intrp ratio 2 for scout?

ukm wrote:

So for example the server will render two gamestates at t=0ms and t=15.2ms, but your client might generate a frame at t=10ms because your framerate doesnt match the server's tick rate. Interpolation means that the client takes the two known positions at 0ms and 15.2ms and "guesses" where the entity was at 10ms. You -need- at least 2 game updates buffered in order to do this interpolation

noob wrote:

so just use meb rates with intrp ratio 2 for scout?

cl_interp 0
cl_interp_ratio 1
cl_updaterate 66

nerds

meb wrote:

ukm wrote:

So for example the server will render two gamestates at t=0ms and t=15.2ms, but your client might generate a frame at t=10ms because your framerate doesnt match the server's tick rate. Interpolation means that the client takes the two known positions at 0ms and 15.2ms and "guesses" where the entity was at 10ms. You -need- at least 2 game updates buffered in order to do this interpolation

Remember, however, that interpolation is always looking forward. Using your example, the data retrieved at 0ms is irrelevant if render time is 10ms and you have already received a newer server frame in the future.

uh, no

interpolation means taking two points of data and inferring a 3rd point between them

if the render time is 10ms the engine uses the two updates on either "side" of 10ms, in the example the 0ms and 15.2ms ticks

MUST BE A BUSY DAY AT WORK PETE

nigga you know i've always got 1 monitor basically dedicated to slackalackin while im waiting on shit

i have 1 hand dedicated to my wang at work

Holy shit, where is Lange or Techdude when we need them?

ukm wrote:

uh, no

interpolation means taking two points of data and inferring a 3rd point between them

if the render time is 10ms the engine uses the two updates on either "side" of 10ms, in the example the 0ms and 15.2ms ticks

Think of interpolation as a continuous process that occurs every time a frame is generated. At 10ms in your example, 0ms data is irrelevant to the engine, since it has already interpolated player positions from then to 10ms

My entire post is a plain-english version of that wiki, you've misinterpreted it.

In that diagram snapshot 340 and 342 are used to interpolate positions for the frame generated at the "Current Rendering Time" arrow

The "Interpolation time" span shown is the lerp (100ms in this diagram) - it's simply the time between the actual current time and the time the engine is rendering frames at. Has nothing to do with which updates are used to interpolate entity positions.

Read the paragraph under the diagram, specifically "This would be 10.22 in our example and all entities and their animations are interpolated using the correct fraction between snapshot 340 and 342."

Cannon wrote:

Holy shit, where is Lange or Techdude when we need them?

The reports of my technical expertise are greatly exaggerated.

Ukm's posts seem quite sound, I'd listen to him.

Think of it as a buffer to smooth the variance in your ping.

Higher interp means there is more of a buffer and the game can smoothly render for a bad connection.

Lower interp means there is less of a buffer. This causes movement stutters on bad connections. It also decreases the latency that interpolation adds to your ping, making projectiles shoot sooner.

cl_interp 0 is a fine setting because it automatically calculates your interp buffer.

From another view interpolation is how long your computer holds packets before the information held in them is shown on screen.

where is bloodsire, ask him about the best interp. also moby dick

DOES NOT COMPUTER

TechDude wrote:

cl_interp 0 is a fine setting because it automatically calculates your interp buffer.

yea but it calculates based on interp ratio

and the whole discussion is on whether to use 1 or 2

and 2 makes more sense for hitscan