Live data from Hacker News

CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

github.com

41–50 of 73 posts

Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

#41
post #17

Wallhack is locked into the DNA of CS for some reason. The most common defense by far is mass denial. For the great majority of players that seems to be good enough.

Not just CS, I don't think people realize how prevalent cheating is in any multiplayer game. The issue is compounded by the fact that many high skill ceiling games are plagued by "micro cheats" being used by players that are already fairly decent at the game even without them, making it borderline impossible for casual players to tell if what just happened to them was a fair skill gap or someone cheating.

I don't play multiplayer games anymore for that reason. Too easy to go on an emotional tilt where you feel like you're suffering from paranoia and suspecting too many players of cheating. It's absolutely ruined competitive games for me.

Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

#42
post #3

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 arou…

my first thought was to have lots of hidden players running around that only you can see. The grenade thing kinda ruins it.

Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

#43
post #16
post #9

Earlier quoted context omitted.

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 an…

C. give everyone wall hack and aimbot.

Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

#44
post #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 th…

What is the reason for thinking "early, not milliseconds" would not mean "early enough for the peeked/victim too?

Ultimately the server must decide when to "pop" players, regardless of client interpolation which can only happen after the pop. So why would the server delay the pop for one player?

Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

#45
post #16
post #9

Earlier quoted context omitted.

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 an…

It isn't an unsolvable problem though, there's only jitter because the implementation isn't very good

Implementing a more conservative anti wallhack cheat where player positions start streaming in slightly earlier still significantly cuts down on the efficacy of wallhacking, while entirely avoiding the jitter problem. Characters in CSGO move at a fixed speed, so you can calculate exactly how many ticks in advance you need to start sending that data in, before they will become visible to another client around a corner - and add a margin

There's also no excuse for sending player positions through a smoke for example - the server should be performing visibility culling

With the two combined you could cut the utility of wallhacks by 80%, in a way that would be completely unnoticeable. The real reason that this has never happened is that valve's investment into anticheat has always been pretty minimal compared to what's necessary for it to be effective (VAC has generally been the least effective anticheat). They're a small company which largely develops steam as a platform, not VAC or anticheat solutions for games

Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

#46
post #11
post #7

Earlier quoted context omitted.

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 ac…

But the pop in system doesn't relate to this at all. Peekers advantage still exists with this system on or off in exactly the same way, and both players will see exactly what they would have seen previously without the culling system

Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

#48
post #10
post #7

Earlier quoted context omitted.

Why wouldn't you just send the positions to both clients in the same tick? Seems trivial to solve.

"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 linear "oh now you're at t=1, now you're at t=2" kind of timeline. And t…

Counter strike in fact uses ticks

Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

#49
post #48
post #10

Earlier quoted context omitted.

"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 linear "oh now you're at t=1, now you're at t=2" kind of timeline. And t…

Counter strike in fact uses ticks

A tick is the smallest amount of time the server does its "work" in. It does not mean, as the person I'm replying to was implying, that clients are 100% always lined up, because a game is played (locally) at much higher update rates.

So a server, of course, does send updates (player position, etc.) every "tick," but that doesn't matter. Even assuming zero dropped packets (suppose we're playing over TCP), it would feel like shit (stuttering, rubber-banding, pop-in, jittery physics, etc.) to play a game over a ~60ms latency that updates ~60 times a second vs other people that also are ~60ms from the server, so game engines do a lot of interpolation and servers are in charge of concensus. Hence, it's a bit of a misdirection to say: "can't you just send everyone the right player data every server update?" because servers obviously already do that (and that's not really the hard part, anyway).

Local interpolation and remote concensus is the hard part, and games handle this differently. In CS, for example, two players cannot kill each other (with guns) simultaneously. Valve's engine requires that someone always wins a gunfight (which sometimes can feel random). However, I would argue that feels way better than, e.g. in Halo, where you can headshot each other (and both players die), which feels dumb and frustrating.

So when building these servers, there are lot of tradeoffs to consider (a lot of which might change the feel of the game).

Re: CS2 Fog Of War: Server-sided anti-wallhack occlusion culling for CS2 servers

#50

I wonder if it could spawn "ghost players" in places no player could be to detect reaction

Honeypot & statistics are a much more interesting avenue of anti-cheat to me. The most egregious cheaters tend to get banned the most quickly with these techniques (e.g. a 200-1 K/D ratio = a lot of samples per unit time).

When it comes to cheating in video games, I subscribe more to the Dune philosophy than the LOTR philosophy. The ends (experience) definitely justify the means. Making sure that all cheaters are punished ~equally regardless of the effect of their infractions is fantastic in principle, but I'd rather if we could simply remove the ones that are obviously & openly ruining the experience.

False positives suck, but there is no reason to pander to the .01% performers if you are trying to keep a multiplayer game community alive. Esports has demonstrated this is a terrible approach. We had community servers that would ban people simply for being too good before all the matchmaking stuff started up. The anti-cheat was vibes based and arguably superior to anything going on today. It wasn't "fair", but it was generally a much better experience as a player.

Post reply on HN