3 ms·

You should read this: https://technology.riotgames.com/news/demolishing-wallhacks-valorants-fog-war https://technology.riotgames.com/news/demolishing-wallhacks-

• Sohcahtoa82 5y ago
  This is a different issue than what I was talking about. Client-side hacks that control player input or give information to the player that they shouldn't have (ie, being able to see through walls) is hard to deal with. I'll give you that. But what is EASY to deal with is the client doing things they shouldn't be able to, like shoot through bullet-proof walls. And I'm not talking about cases of running behind cover but dying anyways because lag compensation meant that you saw yourself behind the wall, but the other player didn't because what they see is 100 ms behind what you see. I'm talking about cases where you were never exposed from cover to begin with, and the client is allowed to decide if a hit is done or not. In another comment, I linked several examples of players in PUBG scoring hits that were straight-up not possible due to lack of line-of-sight. Here's a good example: https://youtu.be/2Gn2Sixr5Wk https://youtu.be/2Gn2Sixr5Wk The type of hack being used in this video is 100% preventable via server-side checks.
  • Gunax 5y ago
    Yes, that should be preventable. The reason we end up trusating the client to a degree is that we want a client-side hit to be registered as a hit. Even if you were to simulate the client on the server, i am not sure this is preventable in general. Sure, with a huge hill that cannot move, its impossible. But what if instead of a hill, the player is shooting through a truck that moves? Well, as the server you know you sent the vehicles location to the client at v1, v2, v3... And you know the player was at p1 when he shot. But you dont know at what time the truck crossed between the player and his victim because that depends on when the client received it. You dont even know IF he received it because you sent it by UDP. So maybe the client dropped the v2 packet. And then remember that the client can rewind history. Basically he can report he did something 100ms ago and the server has no way to distinguish that from a cheat or from lag. From a practical sense, i think devs are faced with a tricky situation: hacks are always possible. Even if you have perfect simulation, it doesn't prevent aim bots because those are theoretically possible. On top of that, you have to trust the client to some degree because of lag compensation. And running physics simulations server side might not be practical. So I think it's easy as a dev to sort of give up and try to solve it some other way. Maybe you just hope that anyone doing something this egregious will be banned manually. The second reason is that you dont want to instantly ban players because it lets the cheaters know exactly the mechanics that caught them. This is why there is always a delay before the real ban happens. Of ourse the side effect is that obliviously cheating players have to be tolerated for a bit before the ban hammer comes down.