Yes, I do. The tickrate for input on a listen server absolutely, positively, MUST be equal to the game's internal tickrate. THIS ENGINE DOES NOT WORK WNY OTHER WAY. How fucking hard is it to understand something so fundamental. If this is not the case then the game is fundamentally broken. This is literally a fundamental aspect of source engine. This is as fundamental as the fact that the directx renderer uses directx and the opengl renderer uses opengl. This is as fundamental as the fact that interpolation uses discrete messages. This is as fundamental as the fact that rockets use line collision instead of hull collision. If this aspect of the engine does not work in this way then several things are going to break in snowballing fashion.

The fact that rockets are lines is what lets rockets do consistent damage on directs, because the engine can accurately "map" them onto whatever they hit. That's why grenades don't have consistent damage on directs.
The fact that interpolation is a function of discrete messages allows player movement to be run at a static rate, which allows input prediction to be possible. Without discrete messages at a static rate, input prediction would be prohibitively expensive on the CPU even with optimization.
The fact that the input rate on a local listen server is equal to the game's tickrate (AND NOT HIGHER LIKE NETGRAPH SUGGESTS) allows the listen server to bypass a lot of the network stack. If it were any higher then the game's physics would break as the player's character would literally be doing the same thing as speedhacking. And that is not the case. The game engine can not accurately simulate input at rates above its tick rate. Therefore, net_graph is necessarily wrong.

Here are some other ingame counters that are wrong/inaccurate:
- cl_showfps 1 (measurement is inaccurate by roughly a millisecond per frame, causing the framerate to look like it's rapidly changing between two values when it's at a stable integer)
- ping on the scoreboard (it's reaalllly broken. uses an old calculation from goldsrc which doesn't work properly anymore)
- some HUD elements (like health) show information that's outdated by a frame

What maps are you playing?

No. That's not what I was saying at all. I was specifically saying that when you set the updaterate to 66, that it is *not* sending the tickrate of the game, like you originally claimed in order to make cl_interp_ratio 1 span more than a single update window. I was specifically saying that reading off net_graph's active rates to know what rate the game is actually using is a bad idea because it's inaccurate, and I decided to figure that out because it's the only reasonable source of that claim you made that I could think of.

net_graph's active rates are off by (roughly, actually a little more) 1%. net_graph shows 66/s settings as 66.7/s. net_graph shows ~66.6 settings as ~67.5.

When you play a on your own listen server, the game uses its internal tickrate for the input rate, regardless of your client and server settings. net_graph shows ~67.5/s for the active input rate when on your own listen server. If the game sent more than its internal tickrate of input messages, it would break, because it would be doing the exact same thing as speedhacking, literally. Therefore, the only reasonable conclusion to draw is that net_graph is inaccurate about active rates by ~1%, and that when you set your updaterate to 66, the server does not in fact send slightly more messages than that in order to make up for low interp.

Because I know that, I can say that the extrapolation spike meter is also inaccurate, because true random jitter absolutely positively must cause extrapolation on roughly 50% of frames due to how interp works. The extent of this extrapolation is dependent on refresh rate phase vs update phase. That's what your ms paint diagrams are showing to me. I already agreed to that.

However, the practical randomness of this all when you're using a monitor below ~66hz is part of how awful it is. The higher the refresh rate you get beyond that, the further along that extrapolation necessarily must be shown on it. This isn't an excuse however for dealing with extrapolation at low refresh rates because it's still a problem that happens and can at least be effectively mitigated trivially by raising your interp slightly to something like ratio 1.2 instead of 1.0 (so that gradual and constant increases in ping don't necessarily cause extrapolation on every frame).

koth_bunkalow_b3 is out after several months of hiatus (honestly I was learning hammer)
changelog:
- added a lot of detail around the outside of the map
(if anyone loses frames please tell cuz I can't tell if it affects performance, maintaining 250fps here)
- changed some textures and stuff inside the map so that some angles are more obvious about where you are
- removed my custom stuff!!! that means I shouldn't have had to pack anything, but if you see any checkerboards let me know!!!
download: https://dl.dropboxusercontent.com/u/1811521/koth_bunkalow_b3.7z

https://dl.dropboxusercontent.com/u/1811521/egdfgsreg.jpg

https://dl.dropboxusercontent.com/u/1811521/awedffgawefd.jpg
https://dl.dropboxusercontent.com/u/1811521/dsgdfgefd.jpg
https://dl.dropboxusercontent.com/u/1811521/gfhdrtdfgrefdg.jpg
https://dl.dropboxusercontent.com/u/1811521/tyjhrfg4t.jpg
https://dl.dropboxusercontent.com/u/1811521/asdgfergf.jpg

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 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.

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

Hint brushes and areaportalwindows fix everything!

personal taste

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.

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.

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.

That's my understanding. The most harsh interp in that list can cause animation microstuttering because of extrapolation.

Yes.

@Deep: It's because lerp is calculated on the client side and it checks for extrapolation with that. This actually causes lag compensation errors in some source engine games because the actual animation interp goes way lower than the server thinks it is. You want to remove them zeroes.

// Harshest timing oriented interp settings -- uncomment only the one appropriate for you
//alias net_harsh "cl_interp 0.0152; cl_interp_ratio 1" // for updaterate 66
//alias net_harsh "cl_interp 0.025 ; cl_interp_ratio 1" // for updaterate 40
// You should use this for projectiles, the flamethrower, and feigning. Whenever you don't need hitreg at all. Or if you like all the classical competitive standards, and never had any problem with them.
// On LAN, this setting is king. I think. Someone smart give me feedback after trying it and the below "harsh2" one.

// Alternative "harsh" , recommended if you experience rockets teleporting through strafing scouts or use a 120hz monitor
//alias net_harsh2 "cl_interp 0.0182; cl_interp_ratio 1.2" // for updaterate 66
//alias net_harsh2 "cl_interp 0.03  ; cl_interp_ratio 1.2" // for updaterate 40
// Use this instead of the above if you experience rockets "warping" through strafing scouts, microstuttering animations, or other unpleasant jitter when using the above (particular with a >66hz monitor)

// Normal settings
//alias net_normal "cl_interp 0.033; cl_interp_ratio 2" // for updaterate 66
//alias net_normal "cl_interp 0.05 ; cl_interp_ratio 2" // for updaterate 40
// Use this in most cases, or if you don't know what else to pick.

// "Soft" settings (hitreg oriented)
//alias net_soft "cl_interp 0.05 ; cl_interp_ratio 2" // for updaterate 66
//alias net_soft "cl_interp 0.055; cl_interp_ratio 2" // for updaterate 40
// This is the safest (relative to the default) "comp" setting. If you're experiencing trouble, use this. If you still have trouble, go back to defaults.
// Use this on things that "can not" miss or are especially susceptible to "shitreg" for you, meaning sniper rifles and (for me) scout weapons.

// Default interp settings
//alias net_default "cl_interp 0.1; cl_interp_ratio 2"

// Etc settings -- take care //
cl_lagcompensation 1 // DO NOT EVER CHANGE THIS NO MATTER WHAT ANYONE EVER SAYS EVER
cl_pred_optimize 2   // DO NOT EVER CHANGE THIS
cl_smooth 0          // Reset these to defaults if you don't like how the game acts when you rocketjump or get knocked around
cl_smoothtime 0.01   // Reset these to defaults if you don't like how the game acts when you rocketjump or get knocked around

// Default smooth settings, in case you need them
//cl_smooth 1
//cl_smoothtime 0.1

@ Setsul:
First,
you... are playing on an extremely local server. With nothing going on. 3ms jitter is not normal. I mean, I could go join a server I get low jitter with right now, but you don't always get to choose, like if you play a match on a server in dallas or something and you live on the east coast, you really gotta set yourself up for a typical case instead of a good one.

Second,
I just ran some tests, and that bar doesn't seem to accurately display micro-extrapolation. What I mean is that it seems like it starts spiking when it doesn't have a sample to interpolate *from*, rather than *to*, so if framerate and msgrate are out of sync it wouldn't show the problem. This seems like a bug, but a very reasonable one anyway. The only reason I'm saying this is because I was getting yellow-flashing lerp (means that extrapolation absolutely Happened that frame) but I wasn't getting spikes. Very strange. Please correct me if I'm wrong.

Third,
I really don't understand what you mean with the 66 vs 66.666.... stuff. That shouldn't affect this. You're only getting 66 commands per second, not 66.666.... and interpolating as if you're getting 66. There are 1/66ths of a second between messages, before jitter and choke. If you add jitter onto that rate, you're going to get adjecant pairs of messages with more than 1/66th second time between them, which (with ratio 1) will cause extrapolation when the interp state passes the former message.

Fourth,
1/5th of an inch is actually a really big deal when you're talking about TF2's stupid missized hitboxes. You're also severely underestimating how severe the acceleration is on some things in TF2 (like double jumps where it's instant). I've experienced myself when I'd get a jitter spike and a scout would start stuttering while they're double jumping around, and the only way I can hit them is aiming straight at the center of their chest. Forget every single one of their limbs, they're insane and totally incorrect at that point. Unless I increase my interp just a little and then my gamestate is in line with the server while these weird things are happening significantly more often.

I recently moved from 60hz to a 75hz monitor and (because my config was a messed up older version of itself thanks to data loss) I was getting microstuttering on things with fast animations like legs, this thread reminded me that I needed to fix my config and oh my god I didn't know I was actually this good at TF2 and I didn't know it could animate so smoothly either.

EDIT: On the extrapolation note, I finally remembered what things made me think it was disabled in TF2. The valve developer wiki lists it as totally disabled for some reason. Also, it didn't seem to work on rockets when I tested it, which I did, a while ago. You seem fairly intelligent, so if you know anything about how rockets work that I don't I'd be glad to hear it.

On a side note much more in line with what OP was asking: Yes, interp affects hitreg. As a general rule of thumb, the higher it is, the better your hitreg will be, but the worse other aspects of the game will be, like timing.

It's a driver thing.