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

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.