This has been done before in both 1.6 as well as Source. I helped with some of these implementations back in the late-2000s when I was playing professionally and I even tried to kickstart an anti-cheat hardware solution about a decade ago[1].. spent way too much time working on some of these problems. The main issue with occlusion was slightly increased latency, visual jitter because of interpolation (especially around corners), and a few other more technical problems[2]. It's good enough for public servers, but not tenable in serious competition.
Cheating has always been a problem in FPSs, and it likely won't go away. That's why premier competitions have always been on LAN.
[2] Hard to fully obfuscate audio sources, hard to obfuscate hitboxes since you still need them for collision checking (e.g. if a grenade bounces off an enemy player behind a wall), and this is on top of the engine itself sometimes requiring actual entities, so you're stuck with these dummy entities in memory, and so on.
Because what do you think matters more in an online game:
A. Smooth and consistent client experience, where bullets hit what you aim at (client-side prediction) where aimbots and wallhacks work.
B. Jittery/laggy client experience, where aimbots still work, but wallhacks are disabled?
You can only choose one option.
Generally, everyone agrees "A" is the best option and cheaters will be dealt with at game time. It's annoying, but that's the cost of online video games.
The many tradeoffs involved are not trivial, this can only feasibly work well on LAN.
This is the reason why Valorant is the least playable among all competitive shooters if your internet is anything lesser than Google campus fiber, ironically in spite of having even-slower-than-CS movement physics on its side to mask the problem.
Riot conveniently cherry picks the best case scenario and handwaves the actual technical tradeoffs in their smug "we solved peeker's advantage!" engineering blog posts that are really just barely-disguised monorail songs.
> Does it cause pop-in when peeking?
The goal is early reveal, not exact last-millisecond reveal.
CS2FOW predicts using movement and ping, reveals enemies slightly before exact visibility, and keeps revealed enemies visible briefly. This intentionally leaks a small near-corner window to avoid late pop-in.
This fails to address the main point of the "pop-in" issue relevant to fog of war systems, which is that it is the victim of the peek that gets the worst pop-in effect, the peeker much less so. The aggressive peeker gets the benefit of the early-prediction from the server since they're the initiator of the movement, whereas the victim only begins to receive the information after the peeker has already gotten two network roundtrips worth of early prediction.
Peeker's advantage is not directly related to fog of war. The peeker is moving so before the movement is even sent to the server, the client's camera began moving. As such, the peeker will have at least a tick, usually more before that new position is available to the opponent.
"Fixing" this would make movement sluggish: any movement would need to be validated by the server. Meaning delay between pressing keys and actual movement.
"Same tick" is a misnomer for a few reasons. First of all, games use UDP, which is basically a "fire and forget" protocol (which means packets get dropped routinely). Second of all, realtime games use some interpolation/prediction to make up for latency (and aforementioned dropped packets).
So it's sort of a "relativistic" temporal system, not a standard "oh now you're at t=1, now you're at t=2" kind of timeline.
Interesting, could it be mitigated by the server doing its own prediction and defogging the peeker early? Or is lag prediction in CS2 not entirely client-sided.
It's more that momentum-based defogging means that the peeker has control over how to manipulate the server's prediction, whereas the victim who is already disadvantaged by network latency now gets an additional penalty of the movement initiation being not telegraphed.
To solve this, the fog of war would need to use purely positional near-edge tolerances, which defeats the entire purpose of fog of war to begin with, which is the pre-aiming reaction time advantage of tracking the peeker through walls in addition to having a farther lever point from the cover than the peeker.
I wonder how often wall hacks are actually used in high-level competitive play by cheaters vs ESP. ESP seems like the better route to avoid manual review flagging suspicious activity. Audible cues (which this currently does not mitigate, and I'm not sure it can) are things that can genuinely separate players by skill and you'd think someone running such a cheat just has very good hearing.
>CS2FOW uses static baked map geometry. Dynamic occluders such as doors, breakables, props, smokes, particles, and projectiles are intentionally out of scope for now.
Market window on Mirage just became more powerful on these servers :)
This has been done before in both 1.6 as well as Source. I helped with some of these implementations back in the late-2000s when I was playing professionally and I even tried to kickstart an anti-cheat hardware solution about a decade ago[1].. spent way too much time working on some of these problems. The main issue with occlusion was slightly increased latency, visual jitter because of interpolation (especially around corners), and a few other more technical problems[2]. It's good enough for public servers, but not tenable in serious competition.
Cheating has always been a problem in FPSs, and it likely won't go away. That's why premier competitions have always been on LAN.
[1] https://www.pcgamer.com/introducing-gameref-the-anti-cheat-h...
[2] Hard to fully obfuscate audio sources, hard to obfuscate hitboxes since you still need them for collision checking (e.g. if a grenade bounces off an enemy player behind a wall), and this is on top of the engine itself sometimes requiring actual entities, so you're stuck with these dummy entities in memory, and so on.
Why on earth don't the producers of the game implement this? It sounds trivial to do?
Because what do you think matters more in an online game:
A. Smooth and consistent client experience, where bullets hit what you aim at (client-side prediction) where aimbots and wallhacks work.
B. Jittery/laggy client experience, where aimbots still work, but wallhacks are disabled?
You can only choose one option.
Generally, everyone agrees "A" is the best option and cheaters will be dealt with at game time. It's annoying, but that's the cost of online video games.
The many tradeoffs involved are not trivial, this can only feasibly work well on LAN.
This is the reason why Valorant is the least playable among all competitive shooters if your internet is anything lesser than Google campus fiber, ironically in spite of having even-slower-than-CS movement physics on its side to mask the problem.
Riot conveniently cherry picks the best case scenario and handwaves the actual technical tradeoffs in their smug "we solved peeker's advantage!" engineering blog posts that are really just barely-disguised monorail songs.
Why wouldn't you just send the positions to both clients in the same tick? Seems trivial to solve.
Peeker's advantage is not directly related to fog of war. The peeker is moving so before the movement is even sent to the server, the client's camera began moving. As such, the peeker will have at least a tick, usually more before that new position is available to the opponent.
"Fixing" this would make movement sluggish: any movement would need to be validated by the server. Meaning delay between pressing keys and actual movement.
"Same tick" is a misnomer for a few reasons. First of all, games use UDP, which is basically a "fire and forget" protocol (which means packets get dropped routinely). Second of all, realtime games use some interpolation/prediction to make up for latency (and aforementioned dropped packets).
So it's sort of a "relativistic" temporal system, not a standard "oh now you're at t=1, now you're at t=2" kind of timeline.
Interesting, could it be mitigated by the server doing its own prediction and defogging the peeker early? Or is lag prediction in CS2 not entirely client-sided.
It's more that momentum-based defogging means that the peeker has control over how to manipulate the server's prediction, whereas the victim who is already disadvantaged by network latency now gets an additional penalty of the movement initiation being not telegraphed.
To solve this, the fog of war would need to use purely positional near-edge tolerances, which defeats the entire purpose of fog of war to begin with, which is the pre-aiming reaction time advantage of tracking the peeker through walls in addition to having a farther lever point from the cover than the peeker.
I wonder how often wall hacks are actually used in high-level competitive play by cheaters vs ESP. ESP seems like the better route to avoid manual review flagging suspicious activity. Audible cues (which this currently does not mitigate, and I'm not sure it can) are things that can genuinely separate players by skill and you'd think someone running such a cheat just has very good hearing.
>CS2FOW uses static baked map geometry. Dynamic occluders such as doors, breakables, props, smokes, particles, and projectiles are intentionally out of scope for now.
Market window on Mirage just became more powerful on these servers :)
Very cool project nonetheless.
This is good. However, it still sends info about the players ~200ms ahead which still makes you lose.