But according to that article it’s still trusting the client. It’s just validating that the action was within the realm of possibilities, not that it wasn’t faked.
From the article (highlighting from me):
Here’s how it works:
When you shoot, client sends this event to the server with full information: the exact timestamp of your shot, and the exact aim of the weapon.
The article continues to state:
The enemy may be the only one not entirely happy. If they were standing still when he got shot, it’s their fault, right? If they were moving… wow, you’re a really awesome sniper.
But what if they were in an open position, got behind a wall, and then got shot, a fraction of a second later, when they thought they were safe?
Well, that can happen. That’s the tradeoff you make. Because you shoot at him in the past, they may still be shot up to a few milliseconds after they took cover.
What’s stated above already happens in Apex, telling us that they already do everything this article is talking about. This article mentions nothing new and doesn’t solve the problem of clients sending fake data that is within the realm of possibilities - e.g. a headshot when you were actually off by a bit.
Because it doesn’t have to.
But according to that article it’s still trusting the client. It’s just validating that the action was within the realm of possibilities, not that it wasn’t faked.
From the article (highlighting from me):
The article continues to state:
But what if they were in an open position, got behind a wall, and then got shot, a fraction of a second later, when they thought they were safe?
What’s stated above already happens in Apex, telling us that they already do everything this article is talking about. This article mentions nothing new and doesn’t solve the problem of clients sending fake data that is within the realm of possibilities - e.g. a headshot when you were actually off by a bit.
The question was about client trust, which the server doesn’t. If the shot wasn’t possible, it’s not valid and did not happen.