CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
1–10 of 73 posts
Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
#2>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.
Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
#3Cheating 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—the server does not do all physics for all clients), 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.
Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
#4 > 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.Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
#5> 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 th…
Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
#6Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
#7> 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 th…
Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
#8Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
#9This 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 arou…
Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers
#10> 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 th…
Why wouldn't you just send the positions to both clients in the same tick? Seems trivial to solve.
So it's sort of a "relativistic" temporal system, not a linear "oh now you're at t=1, now you're at t=2" kind of timeline. And there's all kinds of complicated ways you create concensus between multiple clients, between server and clients, etc. (A lot of this remains an active research area.)