http://www.teamfortress.tv/search/?q=cl_interp

There are already so many threads about this, you litereally just had to search it

if they did get it below 15.2ms it's likely placebo. methods of doing that have been found in the past

watching barycenter I see

.

Does requesting more packets (even if they're not available) cause the game to update more often? Even if you're getting 67 packets a second, if you're updating 128 times a second will you have less packet latency?

I don't know if <15.2 lerp is actually a placebo or not, but I've been using 0.0 lerp for quite a while and many players appeared to be very jittery because of it. As soon as I switched it back to 15.2 everything was smooth again.
But yeah, if you want to test it yourself you should set "cl_updaterate" value to 66+ (up to 100000).

It's not possible as the game only refreshes 66.66 ticks per second, so even if it does send you more packets (which it shouldn't, it's unlikely valve would have coded it to waste their upload like that), they won't actually benefit you anyway, they'd just most likely be interpolation that your client could do anyway.

If your game is refreshing more often, even there isn't more information, it should still reduce the amount of dead time where a new packet has been delivered by hasn't been loaded yet right? Sort of how >refresh rate FPS makes the game smoother.

#9
No, the server only runs at 66 tickrate and sv_maxupdaterate will be set to 66 as well.
So it can't and it won't send packets sooner or more often.

It's not like >refresh rate fps, it'd be more like changing fps_max from the refresh rate (e.g. 120) to something higher (e.g. 300) while having VSync enabled. It's still capped to the same number and nothing has changed.

Is that because packets are sent at even intervals? If that's the case, what's the point of a cmdrate >66? I think chris said set it higher if possible

also setting vsync above refresh rate will cap it to a multiple of your refresh rate, not the refresh rate itself

wew

As always, low interp doesn't even mean better. You want it to be high enough that cruddy servers (the ones you practice on) don't feel worse than good servers (e.g. LAN). High interp trades some latency away in return for higher consistency. You only need to lower interp enough that consistency is about to, but hasn't yet, started deteriorating.

For most people this is between 1 and 2.2 server frames. Some people have particularly bad connections and need to measure the needed interp window in terms of milliseconds rather than frames (e.g. 50ms interp). TF2 servers default to network at 66 ticks instead of 66.66 for some reason, as a cap, though. I'm not sure what they do with the extra two ticks per three seconds.

Interp is a delay window. Even if you could get an interp below 1, it would only cause the engine to constantly be extrapolating things, which means that your hitreg on anything that isn't literally moving in a fixed direction at a fixed velocity would suffer. And I don't even know how extrapolation works against animations. Probably wrongly. Then again a lot of animations aren't synced correctly as-is.

im really confused about this. i was watching barycenter's twitch stream and saw he had a 7.8ms lerp. I figured out how to do the same and since changing my settings i noticed that my shots have registered more than not and im now doing more damage than i usually have done in the past. i didnt even expect anything to happen and saw the results immediately. Even the game feels more fluid now. How could this be placebo? Even when i asked him, he said it was just placebo as well but I am not so sure anymore. Even thougj it is capping the tick rates at 66, i feel as though it is still modifying something else.

prevail, 7.8 is the same as 15.2 lerp, which is the minimum. If you had your lerp higher than 15.2 before then there would actually be a difference. Otherwise it is just placebo.

Online not sure but offline 0 lerp is definitely not placebo, there is a small noticeable difference doing jump maps with 0 lerp and a bunch of ppl in the jump community tend to agree.
Online ppl say 15.2 is minimum but if i use the rates at 67 my net_graph shows me the lerp 14.9 with yellow colour (not stable) while if i use 15.2 lerp on the same scenario the lerp shows up as orange (stable), weird since its supposed to be placebo.
To be honest i think valve should lock the lerp value to be 15.2 the supposed minimum and stop ppl from using these random ass values that may or may not affect your settings.

x

i can feel the difference between 0 lerp and 15.2 lerp. even on valve servers

You're a pyro main, I'm not sure if you feel anything.

Interpolation exists for a reason and you shouldn't try to disable it completely.
Anything below 15ms, which is the tickrate, can by definition not have any packet to interpolate with.

why do you so hardly believe in theory when it comes to this. in theory you should not be able to go under 15, however this game is full of bugs and broken mechanics. just test it out yourself and you can see that client side will have cl_interp value set to 0 on 0 lerp settings. cl_interp wont be set to 0 on 15 lerp settings. tickrate cant go above 66, however tickrates higher than 66 still affect cl_interp value, since cl_interp is determinated by interp_ratio/updaterate or cl_interp itself, whichever is higher.

also sick burn bro. really made u look smart.

sick burn bro, really made u look smart

as a pyro main just make your interp 250ms and use phlog. you can thank me later.

No one ever said you can't set cl_interp to 0?
Can't do it != shouldn't do it.
You shouldn't cut off your arm but that doesn't mean you can't. It is just strongly advised against.

Tickrate is server side. You can't affect it.
You can set cl_updaterate to 10000000 which affects interp, but that still doesn't mean the server will start sending you you the 10000000 per second you need for interpolation to work. You just broke interpolation.

Why the fuck do you think cl_interp_ratio was introduced and supposed to replace cl_interp? They never bothered to implemented the last two steps.
1. remove cl_interp.
2. use the actual updaterate to calculate interp, not cl_updaterate.

That would prevent idiots from doing stupid shit they have no idea about if the server tells them they're not allowed to.