Fixed the Payload and KOTH huds:

http://i.imgur.com/vIGyjir.jpg

http://i.imgur.com/jcHpHoj.jpg

Consistency coming whenever I start pugging again.

it happens with any stacked angled brushes, it's a precision issue so it's somewhat random
sometimes you land just right where you can downright stand on it
it can mostly be avoided with a fat clip, but that makes angled walls even more "fatter" than they should be

Neat! I was actually thinking of doing a minor overhaul to fix the incomplete stuff and bugs(https://github.com/wareya/warHUD-TF/issues/). For the record, are you making your changes on a recent version?

I actually use the default and don't run into that at all. In fact, whenever I set it to the minimum, that's when I start to get 0-damage blood marks.

It's only natural when you actually understand how source engine's interp implementation works:

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Entity_interpolation

Human readable version: When your client gets messages from the server about other players' positions, they're in the wrong place, but the server doesn't know by how much, so it can't compensate when you go to shoot them.

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

-------------
Since the variation is random, source uses the cl_interp period to partially correct the stored times when the client got the hitboxes from the server. When doing that, it treats lost messages like an empty slot, rather than like they never existed. The reason the engine can't do anything more intelligent than this is that the server can start running at a variable tickrate if it's performing badly. Say goodbye to your hitreg in this case no matter what.

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

If you had a graph of a player's Y position and you were doing this to it, you would get a graph like this:

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

The red is what the server thinks it sent, the green is exactly what the client got sent, and the blue is what the client is going to do interpolation on. As you can see, it matches the red line more often, even though it seems like it has an offset.

Then, it does linear interpolation between the information in the oldest and second-oldest message in the cl_interp period to figure out what to display. When doing this, it makes sure that messages on the same animation don't skip any frames.

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

Note that there's a chance that the part where it corrects the stored times might've been some crazy obscure mod or something when I went to look into it, because it just seems like something valve's programmers wouldn't have the foresight to do. In that case, the step is skipped, and the effect is that higher interps are literally identical to lower interps except that they're more accurate when you miss messages.

Also, extremely low interps make the engine sometimes think it's missing messages even when it's not, causing extrapolation, so at the very least you should use 1.2 or something if you want the hitboxes to not start going places the server never said they did.

You're thinking of cl_updaterate. Interp depends on updaterate though.

No, interp makes up for timing jitter and loss of messages from the server. The engine uses interp to put models closer to where they should be. If you have high ping or the server sucks or you're just dealing with things that are moving very fast, a higher interp can and will improve your hitreg.

The downsides to high interp are that projectiles and characters appear marginally (we're talking 1/10th of a second max) further in the past than they actually are. This is why almost everyone uses ~33 ms interp for hitscan weapons instead of going for the default or the minimum, it's a tradeoff.

NOOO. That is WRONG. Lag compensation counts interp, the hitbox as the server sees it compensates for what your interp is, increasing your interp does NOT move the model away from the hit registration hitbox on your screen; the whole entire point is that it can only make it closer.

use a small crosshair

I've had base resolution bottleneck my CPU in TF2 before. It wouldn't be unheard of.

very early 2011
mid 2010

I thought you could use aliases for this?

You just have to get used to switching between them.

I want a ducky mini (extremely similar to the Poker, but with a different fn layer and differently built all the way through) without the ridiculously large-bezeled case :(

fingertip grip master race

it's more common than people think, they just don't recognize it as "fingertip grip" because of shitty marketing from peripheral companies

I am the bone of my yoke
Plastic is my body and infrared is my blood
I have created over a thousand mice
Unknown to reg, nor known to aim
Have withstood pain to create many inputs
Yet, those hands will never hold anything
So as I pray, unlimited mouse works.

The higher the polling rate, the less bad stuff can happen, and bad stuff happens. Basically, it lowers latency, jitter, stutter, and tracking bandwidth issues, all at the same time, for most mice.

If you mouse is fucked up it might actually hurt some of those. Do your own testing.

I use 500hz because 1000hz breaks certain mouse-driven applications that I use, to no fault of my mouse's.

It's not a semantic point, you're being directly deceptive by describing things wrong. Please don't spread misinformation.

I don't get how you don't understand that.