this post was submitted on 31 Oct 2024
408 points (99.8% liked)

Linux Gaming

15295 readers
8 users here now

Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.

This page can be subscribed to via RSS.

Original /r/linux_gaming pengwing by uoou.

Resources

WWW:

Discord:

IRC:

Matrix:

Telegram:

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 4 points 2 weeks ago (1 children)

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):

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.

[–] [email protected] 1 points 2 weeks ago

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.