This may not apply to CS:GO in general but there are thousands of different latency-compensation systems in different netcode in the last twenty years in thousands of networked games that has been released in my lifetime since the early 1990s (NetDOOM).
Most people don’t understand what good latency compensation is for.
Allow me to explain a good metaphor.
A very good “LagComp” engine is always like a very good ultra-tiny Netflix buffer. (A tiny one — like 10 or 20 milliseconds).
Too little lag buffer = erratic latency = hitreg problems
Too much lag buffer = too much latency = awful
Just right lag buffer = consistent latency = less hitreg problem.
That’s why a lot of people like good lag compensation algorithms that behaves like an excellent Netflix buffer or YouTube buffer (except at the 20 millisecond league srather than the 5 second leagues). It keeps the game flowing smoothly rather than lag-jerkily.
We love the superior lag compensation engines when 10 different players have 10 different Internet connections with their different problems. Adding intentional latency is like a shock-absorber for erratic latency and fixes problems.
Not all games, unfortunately, have good lag compensation engines. But it really helps when player A,B,C have vastly different Internet connections of vastly different jitter.
But if all players are all on FTTH and are on a low-latency connection, then lag compensation can be avoided. However, lag compensation can help. I have noticed FTTH users have hitreg problems trying to kill players on DSL connections sometimes when lag compensation is turned off because some games have weird hitreg algorithms. When these FTTH players and DSL connection add intentional latency to “get to the same level” as the DSL connection, to shock-absorb all the erratic packet jitter, into proper internal packetpacing in the netcode, the hitreg problems go away.
The problem occurs because FTTH user A (10ms lag) just began to shoot a DSL player B (50ms lag). But by the time the button is press, FTTH user A (10ms lag) is still same lag, but the DSL user changed lag (60ms lag) because their connection is more erratic latency.
Now 10ms sudden change in lag differential — means 10 pixel mis-offset at 1000 pixels/sec gun slew rate.
The player may have moved 10 pixels further to the left or right, versus the hitbox.
Boom. Hitreg issue, even though you are on a perfect FTTH.
Because 10ms lag-change between you and your enemy is 1% of a second, and 1% of 1000 pixels/sec gun slew rate is 10 pixels offset. Miss instead of hit, if you’re doing rapid snipering (ala AimTrainer style). Barf.
So we turn on *good* lag compensation. Boom. Problem solved.
It’s beautiful when lag compensation works *correctly*. But There’s a lot of bad lag compensation code out there. So lag compensation MAY or MAY NOT be an issue, depending on the game.
Remember, perfect FTTH users *can* have hitreg issues ONLY BECAUSE the other player is on a crappy Internet connection — it’s weird sometimes. That’s often one of the problems that *GOOD* lag compensation code aims to fix.
There’s another factor. The game server too. Now, if the game server load average changes a lot, everybody might suddenly have weirdness. A good lagcomp engine also automatically compensates for server load variances too, to shock-absorb all the lag-differentials (differences between ALL machines including the server itself)
The playing field unfairly unexpectedly tilts because other people don’t have the same Internet as you do.
You can play server roulette and hope you land on a server where everyone has stable Internet connections. As long as you’re stable too, the hitreg often stays beautiful. But as soon as a mix of crappy-variable-latency users join, it’s hitreg weirdness even for the FTTH users. At least in some of the game engines — not all of them. There’s thousands of different netcode engines tying to make weird compromises, all with different (good/crappy) lag compensation stuff. Even CS:GO ten years ago versus five years ago, have different lagcomp feels.
Obviously, this may not be CS:GO since they keep their lagcomp algorithms a secret (to prevent people from figuring out how to cheat/hack/workaround it). It’s an (imperfect) attempt to level the playing field.
But, bottom line, lagcomp is good for fixing FTTH hitreg issues when the OTHER PLAYER is on a lag-jittery connection. There are actually sometimes (in some games) good reason to intentionally to add a very tiny bit of intentional netcode latency to prevent the random hitreg problems from the other player’s packet jitter.
Consistent Latency vs Latency Jitter Lottery (bad hitreg):
You prefer a consistent 20ms latency (0ms jitter) rather than a randomized 5ms-20ms latency (15ms latency randomness = 15 pixels of random pixel offset in hitbox at 1000 pixels/sec gun turn/slew rate, or 60 pixels error at 4000 pixels/sec gun turn/slew rate). Lagcomp can turn a 5-20ms jitter into a 20ms rocksolid. It’s kind of a consistent-latency-emulator upgrade for your variable-latency situation.
It applies regardless if it’s you with the jitter, or if it is the OTHER player with the jitter — it’s why some FTTH users has to occasionally add intentional netcode latency (latency compensation) because of the fault of all the other players’ jittery Internet connections screwing around with your hitbox registration.
When the server reconciles (aka synchronizes) the wildly varying time differentials (caused by packet jitter being different for you and for the other player) — laws of physics dictates guaranteed hitbox registration problems when latency compensation does not exist — it’s unavoidable. The only way to solve this is the netcode’s method of latency compensation.
Disabling latency compensation may improve your performance on perfect servers with perfect connections for everyone. That’s why it feels good on LAN games.. But in some countries, you’re playing a zoo of different latencies and latency jitter. In this case, latency compensation (self adding intentional netcode latency for yourself) becomes mandatory to improve your competitive play.
When esports arenas shut down during the pandemic, everyone had to deal with the latency zoo of the open Internet.
It’s maddening because you upgraded to a perfect FTTH connection, but the other player has a bad Internet connection — and is causing you to fail to frag them, because you shot them and the hitreg didn’t count.
It’s maddening because you don’t know which servers will perform better with latency compensation, and without latency compensation.
And it REALLY screws around with your muscle memory. Your memory of 0ms LAN latency back from your LAN game days, or your memory of open-internet game latency — many people quit gaming because of all the lag weirdnesses and hitreg weirdnesses.
It’s the luck of the lottery — do you KNOW that the other players have zero latency jitter like your very own FTTH connection?
Correct use of lag compensation is how skilled players can perform very well despite having 100ms latency:
- Player A: FTTH, 10ms lag, without lag-compensation, 1ms wire jitter
- Player B; Nearby DSL 50ms lag, 20ms wire jitter
- Player C: Faraway DSL 100ms lag, 30ms wire jitter
Some game servers automatically calibrate server lag to the worst player or average player that has connected. If the in-game latency compensation buffer of lag is 70ms, then Player B can get 0ms in-game jitter despite having 20ms wire jitter, and Player B will usually be able to out-play Player A and Player C, if all A/B/C has exactly same skill. But if server lag compensation buffer expands to 130ms or more, Player C can even sometimes gain a chance to compete equally with A/B/C because everyone is getting 130ms “intentional server latency” — but if the lag compensation buffer shrinks to under 50ms, Player A often has the edge. It’s quite patently weird and sometimes unfair how the playing field tilts. Now, if the algorithm is different, the result may be different. But latency compensation is an (mperfect) attempt to level the playing field.
For simplistic lag compensation algorithms — just pretend good latency compensation is just simply a tiny Netflix buffer to de-jitter the game packets. Then you get the rough idea. But they do all kinds of weirdnesses that don’t scale as linearly.
Battle(non)sense covers a lot of things (same things but in different terminology) as do other YouTubers.
Now that being said, buggy lagcomp can create desync feelings. But one needs to understand why lagcomp exists and how to muck around it, if you need to use it to your own advantage.
Unfortunately, not all lag compensation algorithms in all game engines are that good. CS:GO is both good and bad. Hard to know when it's good / when it's bad. But a smart, educated esports player understand *why* lag compensation exists. You actually literally flunk math class if you do not understand why latency compensation exists. That is why.
