wareya, could you explain what you meant about other scouts with high jitter causing extrapolation on your client? Are you implying that the server does no interpolation on its part when the laggy scouts fail to send data to the server regularly?

Minor point, but trust me on this, it's not 59.94 either. It can be anywhere between 59 and a little above 60, depending on the pixel clock and timing parameters.

1. Sure, why not? It doesn't really matter

2. That sv defines the maximum lerp clients can use. 2 * 15ms = 30ms max lerp with that setting, regardless of how it's set (cl_interp vs cl_interp_ratio)

3. Units, bro. Units. 2 seconds * 66 ticks/s gives 132 ticks, which means nothing in this context. The second one is the one I'm talking about.

I could set it to INT_MAX to make you feel better :)

I do, because I don't have a few hundred at the moment to throw around for a new monitor.

And don't broscience me :)
How can you even tell if there's any difference between a sub-frame to interpolate and one whole frame? Assuming that the game is vsynced, just for argument's sake.

This clamps what the client sets. It'll mean that the client can set whatever high number they want, but lerp will be upper-bounded to 2 * cl_updaterate

smlib isn't needed? I'll remove that, pronto. Thanks for the report turtsmcgurts.

Thanks for chiming in, everyone and wareya especially.

Since this just defines the max rate, what's the harm of overkill? The server will clamp it, won't it?

Oh, and this is something the wiki did NOT cover: choke. Choke occurs when the server cannot send data quickly enough to clients, right? I suppose that may imply the server can't receive data quickly enough from clients, either. Even in a choke situation, shouldn't your client be sending as many updates as the server can receive and consume? Or is consistency rate-wise more important?

Okay, okay, I copy-pasted that one :)

Just to be clear, we're talking about the other players' connections, right? You're implying the server doesn't interpolate or extrapolate the other players' positions, right?

Good catch, I'll remove that.

Well, like I said in the OP, I wanted people like you to vet over my cfg file and teach me anything I haven't learned right.

As for interp and jitter... makes sense. If a packet comes 7.5ms too late, then there's 7.5ms of extrapolation to be done once the window runs out. With that said, if you know your jitter will never exceed JITTER, then:
ideal lerp = 1/cl_updaterate + JITTER.

Like you said before, high jitter from enemy scouts leads to extrapolation happening for those guys. Can you explain the mechanics of that?

Okay, then let me revise my advice:
sv_mincmdrate 66
sv_minupdaterate 66
sv_client_max_interp_ratio 2

The thing about the high interp that gives me an advantage, I noticed pubbing as a heavy, is when I get the jump on them. I get a nice fat advantage as they run away behind cover.

So anyway, what else should I read to understand Source networking as well as you do?

It worked in my testing, mostly, but the devs specifically told me listen servers are not supported.

I think the ideal way to get it working cilent-side and VAC friendly is to ask Valve to sign the plugin on the condition it'll only work for servers that have a tag like aimassist. Of course, they'll audit the source to make sure that's true, I just wonder who I'm supposed to contact and how would I sell this...

Seems like his plugin has more features than mine. I think his is client-side. How do client-side plugins work? Do they only load if they're signed when you launch TF2 in secure (default) mode?

My plugin is not an aimbot, though, unlike his. That would defeat the point of training.

None. It's only good for local servers atm. They're not too hard to set up and they weigh in at around 5.3GB.

Right, all you have to do is gain access to your favorite server, upload and load the plugin, and let's not forget to edit it so no one else on the server can see the crosshairs but you... wait I already showed that can't be done.

I'm being rused, aren't I?

Huh? It absolutely is! It's made for practice and training.

From the looks of it, you're compiling from a listen server. Though it should work... it's not supported. It compiles just fine on my stock copy of Sourcemod 1.7.x on Windows. You are also installing sourcemod to the "custom" directory, also not supported. Believe me, I want those two things to be supported as much as you do.

Anyway, neither of those SHOULD be the reason you're not compiling.

HAHA, I lied. You need SMLIB to compile, too: https://www.sourcemodplugins.org/smlib/

What he said, yeah. I kind of try to imagine the invisible crosshair when I fight people anywhere else.

EDIT: (I'm making wild hand gestures as I type this) Let's see you try to focus on the crosshair as it's dancing around like mad across your screen, the dude you're shooting at may as well be standing still.

No comment

A jerk would just tell you "Read the source."
Read the source.
...and you'll see that I calculate the target differently based on what weapon the player yields. Different projectile weapons have different velocities.

Yeah, compensating for circular air strafes is on the to-do list. I'm just too busy with other projects to do it myself (not to mention it might be a waste of time considering what I said in OP), but you're free to submit a pull request when you write it :)

Like I explained in the OP, you can't discriminate which clients (players) the cursor will show up for, at least not with Sourcemod's stock API AFAIK. I haven't looked into it a ton, maybe you can do something with a custom extension or something, I don't know.