Hacker News Reader

Comment by jsheard | Hacker News Reader

A related article on refining their netcode to minimise the usefulness of wallhacks:

https://technology.riotgames.com/news/demolishing-wallhacks-...

Not many first person games have that "fog of war", it turns out to be quite hard to implement well.

Didn't most first person games have this automatically because of using the Quake engine due to their PVS system? It was used to reduce drawing overhead but also beneficial in not sending more data than needed and preserve bandwidth serversided.

AFAIK no they didn't, Valves engines are from the Quake lineage and still use PVS but they only added serverside fog-of-war to Counter Strike relatively recently in ~2015. As the Valorant article goes into, it's a harder problem than it appears because you need to allow the client some wiggle room to know an enemy in coming around a corner before the player sees them so that lag compensation and shadows work correctly (Valorant sidesteps the shadow issue by simply not having players cast shadows). Plus PVS is quite coarse so if you want precise culling you need a more computationally expensive solution.

This video compares Valves own fog-of-war implementation to the implementation used by FACEIT, a third party competitive matchmaking service, which shows there's a pretty wide range of trade-offs to be made. Valve went for conservative and fast, while FACEIT went for aggressive and (presumably) slow:

https://www.youtube.com/watch?v=8w1ICIBO3D4

Valves implementation is better than nothing, it at least stops cheaters from knowing which direction the other team is going at the start of a round, but beyond that it doesn't stop them from knowing exactly where most enemies are standing around corners because the serverside visibility checks are so coarse.

I remember installing a metamod plugin to my cs 1.5 Server that added server side fog of war iirc. But i could be mixing things up.

SMAC certainly predates Valve’s official implementation, wouldn’t be surprising if something else also did it.

Probably CSGuard/HLGuard. It had a popular wallhack-block feature that was using a lot of CPU.

Oh great video. Thanks for sharing. Surely the tick rate has to be lower on FACEIT as a consequence? Maybe this is why everyone in matchmaking would talk about it.

at this time valve official servers were 64 tick and FACEIT 128 tick.

This has been replaced by 'subtick' which I don't know enough about to comment.

2015 was 9 years ago

9 years ago is relatively recent when talking about the design of the Quake engine and its descendents, which was established 28 years ago.

I’m pretty sure the first wall hack I heard of was on the Quake engine so that must be something they fixed later on?

It's a matter of how aggressive is the fog of war and removal of irrelevant entities. Sometimes it's high, sometimes it's low. Too high, and people glitch into existence on high-latency connections. Too low, and you know exactly where people are far behind where you need to.

Many custom servers in games like CS enable a more aggressive version, in cases where you geographically will be close, so you can rule out high latency connections and have more aggressive fog of war.

I believe in the Quake case they made all the walls transparent so you could see everyone coming. Which means they weren’t doing much fog of war at the time.

Regarding the Quake engine and its evolutions (Q3, Call of duty, RTC Wolfenstein), the most common trick was to modify the rendering mode of all player entities so that they are drawn above everything else.

The engine has a flag that is mainly used to draw the player's weapon (which is rendered above the rest). Using this flag for players was the "engine compliant" way of making a wall hack.

You could also replace player model with a big spiky thing. The spikes would poke through walls.

Or in team fortress, replace the sniper's red aimpoint dot with a big model. They become easier to avoid.

Of course not great from large distance / players behind multiple walls but I think the server wouldn't send you the info of those guys anyway.

I'm not sure if the fog of war anti-hack applies to League of Legends: Wild Rift (mobile version of LoL) since there are map hacks where you can see enemy positions going around:

https://www.youtube.com/watch?v=pGKZCQoqEOk

https://www.youtube.com/watch?v=V600M8NqpzM

That's weird, top-down games usually have a clearly defined fog-of-war so it's relatively simple for the server to withhold information that clients don't need to know. Maybe they cheaped out by using peer-to-peer netcode in that version, so there isn't an authoritative dedicated server?

IIRC Counter-Strike had it back in ~2002.

I don't think it did officially, there were definitely server plugins that did it back in the day but AFAICT it wasn't official until this 2015 update:

https://old.reddit.com/r/GlobalOffensive/comments/37ebes/maj...

> Added trace-based visibility checks to prevent networking invisible enemy players.

If you're remembering playing with the r_drawothermodels console command to get a faux-wallhack effect, that was still subject to the engines clientside occlusion culling so it didn't show everything the client (and real cheats) were actually aware of.

I'm referring to CS 1.2 or so, back in ~2002.

The thing I remember was that my friend's graphics card had a global transparency setting built in (AKA a wall-hack mode lol). You could see other players come into view as soon as the came into an area that was rendered. Then a CS patch came out and the players weren't visible until very shortly before they would become visible had we not had the uhh... transparency mode on haha.

Yeah that's the same deal as r_drawothermodels, crudely forcing the GPU to render objects that are behind other objects would give you a partial wallhack, but that wouldn't disable the engines occlusion culling so once it determined that an object was definitely no longer visible it would skip drawing it altogether, and you would stop seeing it through walls. "True" wallhacks were able to override the clients occlusion culling and reveal everything, so to defend against that the occlusion culling needs to happen on the server, which came much later.

Oh interesting. Thanks! We must have assumed it was client-side and gave up.

*server-side

Their rather simple maps also help.

Reply on news.ycombinator.com