Wareya, I found for myself that at this interp I can hit A LOT more sniper shots, to the point where I feel like the hitbox is actually bigger. Ive been using this interp for months now and its amazing, what would happen to hitboxes at this interp?

If means that you're seeing the game at a 60hz interpretation of tf2's 66.66...hz frames, where it just skips a couple every second instead of smoothly interpolating between them. That's if it even works right in the first place. The hitboxes are the same, I'm pretty sure.

@wareya
First:
3ms ping jitter not normal as in too low or too high? Your settings can't deal with more than 3ms jitter either so you should be using at least ratio 2 anyway.
About that "extremely local": That's Europe. If I had to play a match on a Dallas server I'd get 200 ping. 20ms ping is indeed a good case, but my worst case for a match server is 40. And if someone from the east coast has to play a match on a server in Dallas then that's by no means a near perfect connection.

Second:
Yellow lerp means that the server frametime dropped below your interp. If there's no sample to interpolate from wouldn't that mean that one packet was dropped? I've just tested it and slight ping spikes do result in a single extrapolation with no packets dropped. I'm not sure what happens if the previous snapshot was dropped, doesn't TF2 interpolate between next available older snapshot and the current one?

Third:
TF2 runs at 66.67 tickrate, not 66, which equals 15ms or 1/66.67ths of a second between messages. IF you use 66 rates a server will send you all snapshots, which is one every 15ms, not one every 15.2ms. That means that any ping jitter <0.2ms won't cause extrapolation.
It's a minor sideeffect.

Fourth:
1/5th of an inch if you are standing right in front of that scout. Spread doesn't really have an effect on that range, if it's a meatshot, it's meatshot, those 12% of the scouts width that his hitbox might be off is not magically making the shot do 0 damage.
About jumping scouts and hitboxes: The hitbox of a scout's limbs while jumping is completely mismatched. Even on a local server it won't be in the same place as the model. The chest is the only place where you can guarantee damage.

I'm on 120Hz LB.

@EDIT: Could you post a link? How did you test it? I'd like to see if I can reproduce it, because I haven't testet it myself yet.

#32
Why would low/almost no/no interp force TF2 to skip some packets? If this is something totally obvious please tell, I can't figure it out.

You seem to be fairly intelligent too and apparently you also know what you're talking about, unlike other people that just spread bullshit. Yes, I'm looking at stabbystabby and his cl_updaterate 100, his precious 10ms interp and his glorious -64bit launch option.

Uh what? That was uncalled for. Civility is a sort of intelligence, you know.

My interp is .015, and my updaterate is 66.6667...and the launch option is there because why not.

I have a question but i don't want to read all the walls of text: What do interp colors indicate?
I'm using interp 0 and interp ratio 1 or 2 for projectile and hitscan respectively. When i'm at ratio 2 my interp is white, when im at 1 it flashes from orange to yellow. Should i change anything?

Setsul's correct:
"Yellow lerp means that the server frametime dropped below your interp."

That's going to cause stuttering/warpy movement of players and projectiles; if that throws you off, bump up your interp.

Nah, you spread some pretty bad bs in the SPUF, especially those configs.

-64bit doesn't exist in the source engine.
Apart from that there is no 64bit version of TF2 and there never was.
The source engine launches in 64bit if possible, there's only -32bit to prevent that, no way to force it.

dear wareya,

  i love you

No, I don't. Find a quote or be specific if you're going to bother to insult me. Right now you're just being rude and inaccurate.

As far as my config goes, by all means, point out a fault and I'll fix it. Never posted my config on spuf, by the way.

Yeah you said that and i'm thankfull. Still waiting for the setsul reply which is going to make me 10x better headshot ninja.

http://forums.steampowered.com/forums/showthread.php?t=2765833

cl_updaterate 100
cl_cmdrate 100
rate 60000 // tweak using net_graph to the point at which you get <10 choke. Higher rate value than needed just raises your ping.
cl_interp_ratio 1 // how often per tick interpolation is updated. We want that to be every tick, which would be "1"
cl_interp .015
cl_smooth // 1 (default enabled) or 0 
cl_smoothtime // match to interp (.015) or set to 0 if cl_smooth is disabled

cl_updaterate 100 and cl_cmdrate 100 are useless. TF2 limits it to 66.67 anyway and servers can't send more snapshots than their tickrate and the tickrate is fixed to 66.67.
The explanation of cl_interp_ratio 1 is just plain wrong. Interpolation isn't "updated". It's not "once per tick" it means "interpolation length is 1*(1/cl_updaterate)" which is
a) not about ticks, it's about clientside snapshot recieval rate
b) not a "x per" measurement it's a "x times" measurement which is the complete opposite for any value apart from 1.

cl_smooth we had that already
cl_smoothtime this is like the magical rule "you need to use the same interp as your ping". There's no logic behind it.

http://www.reddit.com/r/tf2/comments/1rj6b3/stabby_stabbys_everything_packall_the_tf2_tweaks/
Let's look at the forst launch option.
-16bbp

Now let's look at the Valve Dev Wiki.

-16bpp - Forces 16-bit color mode (bit depth).
Note:Not allowed.

Do I have to continue?

EDIT for #40:
White means everything's normal.
Orange is normal for ratio 1. It means your interp is less than 2 ticks (aka ratio 2) and is sort of a warning that stuff will happen if you loose one packet.
Yellow means that the server framerate drops below your interp time. Most of the time these are really small drops so you shouldn't be too worried.
If you are getting warps or just want to be sure just use ratio 2.
You could also check for extrapolation when you are using ratio 1 (net_graph 4, watch for red vertical lines rising above the white line on top of the blue stripe at the very bottom) if there aren't any vertical red lines at the bottom (see the picture on page 1) you're good.

Now this is super confusing. I'm still getting vertical red lines in interp ratio 2. I think i shouldn't? I have no idea. I get them in ratio 3-5 too. I'm sorry for bothering like that just im so dumb when it comes to stuff like this.

Could you take a screenshot? One with ratio 1, one with ratio 2.

cl_interp_ratio 2
http://puu.sh/5yOfK.jpg
cl_interp_ratio 1
http://puu.sh/5yOen.jpg
sorry didn't crop this is kinda rushed

Can't see anything apart from a bit of choke.
Have you tried a different server?

What's the deal with Choke? Mine goes from 0 to 40, not sure what that means...

Choke means that the server has to hold packets back because the bandwidth cap was met. That means either your or the server's "rate" setting is too low.

Set rate 600000 and try again, if it's still showing it's the server.

Happens on every server

It's extraordinarily low, obviously. Your settings can't deal with any jitter whatsoever.

And you should not me recommending people to configure their game that they'll have what you call a "near perfect connection". That's just foolish. Really. Shit happens.

No... That does not happen. You get 66 snapshots, not 66.666~. You're probably being mislead by the inaccuracy of net_graph:

https://dl.dropboxusercontent.com/u/1811521/dfgwerg.png

On a listen server, source seems to be hardcoded to send the game's internal tickrate in input messages. That's the 67.7 down there. Regardless what I set my cmdrate to, which happens to be 10 in this example. Therefore we can assume much more reasonably than whatever you said that net_graph is giving inaccurate readings.
These are the values that I was *maintaining*, not flukes. The active cmdrate never dropped below .6 and the updaterate never exceeded 67.0. If what you're saying is true, then I should definitely be seeing something more like the bottom on the top, no? Why aren't I? Because, the active updaterate is actually lower than the active cmdrate. The active cmdrate can be assumed to be the game's internal tickrate almost exactly *much* more easily than the obscura you're proposing, and if the inaccuracy of (I cut myself off here because I was rambling)

Hold on a moment. You said 2.4 hammer units away, right? Let me do my own calculation with the other things that I assumed in my response; let's assume a scout is falling at an angle then jumps in the opposite direction.

You can easily get a 900 hu/s difference, there, rather than 800. Also, you need to assume a 30ms difference, because you need to *do* the extrapolation (over ~15 ms) where the scout kept going instead of jumping because you didn't get the message yet; and then undo it and do the interpolation (another 15ms) because you got that message and the one after it in a single display frame. That's 0.03s*900hu/s=27hu. That's a lot of space.

And we're just talking about the location of the body of the scout, not his limbs, but I admit this is a worst case scenario (50% chance with extremely aggressive interp settings!) and the most deviation you're going to see when fighting a scout normally with them strafing around is something that I would assume to be in the ballpark of 8hu with every inconsistency put together (since interp isn't perfect and only solves the brunt of the problem). If you want to do the math with the lower accelerations or correct me earlier be my guest.

Fair enough, since I know the soldier's legs are entirely clientside, in this case. I'm still suspicious because I can shoot legs easily with high interp (50ms+). But I'm still mad because I can't shoot the soldier legs. In what cases do limbs stop being synchronized?

Because TF2 runs at 66+ FPS and the monitor's running at 60FPS. It's not skipping packets, it's skipping animation states. Rather, without interp, there's no way to show every animation state on a 60hz monitor without slowing the game down.

Yeah but if 3ms jitter is so extraordinarily low that it's almost never going to happen then your settings can't deal with it either. In that case I'd just use ratio 2.

I can't figure out what you are trying to tell me with the next sentence. What I said was projectiles->ratio 1, hitscan->ratio 2, but ratio 1 might work for hitscan too if your connection is near perfect.

I'm trusting the VDW on the tickrate.
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

The rest after that: No, just no. First of all the scout will get rendered in the correct position in the next frame (assuming smoothing is off) unless the next packet hasn't arrived until then too. Second the interpolation doesn't add 15ms delay just because one packet was late, unless your spiked by 15ms but that's a whole different story. I should probably draw a picture again.

Limb animation and hitbox states simply do not match, depending on the state the hitbox is off even when standing still. Apparently Valve didn't bother syncing them.

Now I know what you meant, the packets are indeed sort of skipped in the display frames but they are still used for the rendered frames in between. Nonetheless every single frame has to sue extrapolation to get the animation state which is horribly inaccurate and jittery.

I have no time / I'm busy so I'll make this reply short.

Tickrate is the internal rate at which the game runs. It doesn't mean anything to the netrates, aside from the ceiling. You are conflating contextually irrelevant information. If you don't believe what I was saying in the first place, just go onto a simple map on a listen server with net_graph on and mess with your updaterate. It will display a slightly higher active rate than you actually set the rate to (~101% factor).

Smoothing does not apply to animations. The only thing smoothing applies to is input prediction. The only thing input prediction applies to is your own character's state in the world.

Yes. That is in fact what interpolation necessarily does. Need me to draw you a picture?

https://dl.dropboxusercontent.com/u/1811521/tryjtyhtght.png

That's about two updates (give or take depending on discrete time interference) of distance between the extrapolated point and the interpolated point. It's effectively up to luck how much it has to extrapolate by, but it's 0-15ms worth of error on top of the jump's instant (8-15ms if you have a 120hz monitor, so it's actually worse). It's a worse error because of the way people aim as you need to correct for acceleration, which is why I said 30ms worth of movement. EDIT: That is to say that the jump itself adds 15ms of misdirection to aiming and the extrapolation is 8-15 on top of that.

EDIT:

If minimum interp only applies roughly every other frame because of jitter (which it does, unless you're lucky) then 3ms at least makes it apply more than every other frame. It's still an incredibly harsh setting but 3ms of worse timeto make extrapolation happen significantly less often is a perfectly fine tradeoff.

So instead of the wiki being right and net_graph having ok-ish accuracy, both are wrong?

Scratch that smoothing stuff, I was mentally still in the other thread.

No. Interpolation doesn't smooth extrapolation errors. Interpolation was implemented so you don't have to use extrapolation at all. Unless the tickrate and your refresh rate are perfectly in sync, and they aren't because TF2's tickrate is fixed to 1/66.67=15ms and 99.99% of all monitors are going to run at either 60, 75 or 120Hz, there will always be frames that get rendered significantly after the last snapshot but before the next snapshot arrives. How do you get the object positions at that time? You can't so you'd have to extrapolate. The Source Engine however delays the client time instead so there are [cl_interp_ratio] snapshots of the future (seen from the client) available that you can use to get the current position by interpolating between the last snapshot and the next.

Yes, that seems to be the case. The game engine would not work correctly if more than the internal tickrate were sent in input commands (that's speedhacking).

That's right, but it corrects them practically speaking because extrapolation state is entirely ignored for interp. Proper response to your notion in that sentence at the bottom of the post.

That false dilemma is literally the reason that interpolation causes a delay on animations: so that it always has a snapshot on either side of the point which it's interpolating to render.

Minor correction: It delays interpolated objects specifically. It doesn't delay events, eg deaths, caps, and "this guy shot his weapon".

My crappy ms paint diagram is consistent with the rules of interpolation. Interpolation doesn't even work without a delay, from a theoretical perspective. The green line is the track that the client wants to and is trying to make. The blue line isn't an animation slide, it's an error measurement.

Imagine that it makes a triangle with the extrapolation line and the relevant interpolation line (which it does). The shorter the extrapolation line and interpolation line are (in consistent ratio to eachother) the lesser the error is, but the average error (half length) is still 15ms movement worth of error (in this nearly inverted inertia case). And, since you got to the errored point (wherever it is on that extrapolation line) and rendered it, you need to add 15ms-ish for the time before rendering the next frame, which is when the error becomes noticable. So you have 30ms error (average).

It's extremely autistmal how I'm trying to describe it but I hope I've at least made myself understandable.

I read all posts but aren't you both agreeing to use interp ratio 2 for hitscan? are you talking about setting the interp now?

Thanks for being specific and providing some substantive information.

That said, I think you're dodging the point of my initial post: 1) You insulted me out of the blue, and that's not necessary, 2) You made counterfactual statements.

What you suggested is that I am unintelligent and spreading deletarious information. That's untrue and immature, and I don't appreciate it. I made that (very old) post by request, and never claimed to be an authority--I did my best to oblige and I linked my source. Since then I've continued to read and adjust with what I learn. The settings in my config are absolutely fine--however, after the cl_smooth thread I will be adjusting that value to "0". You, too, are incorrect in some of what you are saying, but nobody's calling you stupid.

You're doing a good job of being informative, but please just try to be more of an adult and avoid name-calling and lazy mistruths. Apologies for derailing, please resume.

???

http://teamfortress.tv/forum/thread/11088/2#post-58

I'm not sure what the disconnect is, but I don't see what's wrong with that quote. Did it not come off as tongue in cheek?

Anyway, I really didn't mean to derail. This is a great thread otherwise. Sorry.

#53
Let's break down your conclusion in simple steps.

1. net_graph doesn't show the correct cmdrate on listen servers
2. Therefore both updaterate, cmdrate and tickrate of dedicated servers have to be 66 and not 66.67.

That doesn't make any sense to me.

Like you said the extrapolation state gets ignored. Here's an even crappier ms paint picture to show you what I mean.
Black = position in snapshot
Green = position in rendered frame
Red = position where it would be rendered if snapshot 3 wasn't 7-10ms late

http://i.imgur.com/pcqD9Kz.png

Now pick frames in an intervall of 16.67ms (60Hz) or 8.33ms (120Hz). That's what you are actually going to see.
I picked 3 60Hz examples:

http://i.imgur.com/pOVFk2t.png

http://i.imgur.com/ybJHaUq.png

http://i.imgur.com/IJIpg9u.png

The effect on number 1 isn't that bad, number 2 is affected the worst and number 3 isn't affected at all by the extrapolation but is actually worse than number 1 and it could've shown these frames without extrapolation!

I have a 120hz monitor and my settings are this, are they correct? I mostly play soldier, should I change them for when I scout?

// Net settings
cl_cmdrate 66
cl_interp 0.0182
cl_interp_ratio 1.2
cl_lagcompensation 1
cl_pred_optimize 2
cl_smooth 0
cl_smoothtime 0.01
cl_updaterate 66
rate 100000

I will be mostly on servers with similar connection as the one shown in the net_graph. What numbers are important, what should I look at and are mine looking okay?

http://i.imgur.com/fq5Dr2R.png

// Net settings
cl_cmdrate 66
cl_interp 0.0182
cl_interp_ratio 1.2
cl_lagcompensation 1
cl_pred_optimize 2
cl_smooth 0
cl_smoothtime 0.01
cl_updaterate 66
rate 100000

im not one of those wizards up there, but im pretty sure setsul said interp 0 and interp ratio 1 or 2, i use 1 for projectiles and sniper and 2 for everything else. Tho im not sure