This is so funny because rust has one of the worst cheating situations and majority of their players are windows users, and theres lots of games that have anticheat that allows linux and have notably less significant cheating problems like marvel rivals. in reality rust doesn’t take cheating very seriously because if they did they would have more server side software that detects illegitimate behaviour like tons of other games do successfully… even most popular Minecraft servers have better functioning anti cheat that is completely server side than rust has while getting kernel access to your pc. its pathetic and lazy development tbh and this entire post from them reads like such extreme cope…
I’ve said this before about wall hacks. The only reason they are possible is because the positions of all players are being sent to the client and then the client just doesn’t draw them to screen. It would be extremely easy to simply not send the data for players you shouldn’t be able to legitimately see.
And you are not the first person to have this idea.
Most games do that to some degree. The thing is they are working with a threshold, which means they send your client the information of a few “extra meters” - beyond your field of vision. If they didn’t, enemies would sudddnly pop into existence, instead of smoothly running around the corner. Especially in fast paced games there’s nothing more frustrating than losing to this.
But there’s more: non visual clues. If an enemy is outside your vision, but makes a noise, you cannot give that information to the client without revealing the enemies position. It’s simply not possible (again, not without risking giving completely wrong info by the time it reaches the client).
Same goes for non-player objects, which are the result of a player’s action somewhere else. If a player kicks a bucket across the map, the bucket flying through your screen makes it trivially easy to calculate the point of origin - and you know something happened there / player was there.
We’d be really really lucky if server side fog of war would be the kill-it-all solution to cheating.
Hmm very well said. Thank you for explaining that. Definitely a harder problem to solve than I thought at first.
I find a number of problems with the level of authoritativeness that you speak and some of the arguments you’ve made.
The core of your first argument lumped together is that a small amount of extra latency is the same thing as “impossible”. This is obviously not true as even with some relatively fast paced genres, what is acceptable varies wildly. Maybe such an argument could be used for Valorant, but not for Pubg or escape from Tarkov (games that are already known for netcode slow enough that this would not truly/notably harm the experiences of players if they were designed for this from the start).
This example is contrived, and just the type of thing where there are a number of options available.
One could simply not send the bucket, send it with a delay, the bucket could not exist (the majority of games), the buckets origin could be randomized just enough to be at the tested limit of player perception, the game could include a trace shadow by default.
For every example like this, there are options available which aren’t entrusting a black box to access all of your data with a pinky promise.
There is no kill-it-all solution, and this is a clever little re-framing of the argument by you where the new solution has to be perfect, when the status quo can just be mid.
I don’t understand how you lump my arguments into “extra latency”. Server side anti cheat doesn’t add latency (I mean technically it does, but that’s not the concern right now), but latency is very much the reason for the downsides I pointed out. The smaller the margins, the higher the chance one of the two players doesn’t see the other coming solmoothly around the corner, but suddenly materializing in full view.
Your examples illustrate that very well. It’s OK for PUPG or Tarkov (and even there only long distances), but a hard for Valorant.
And now, instead of the irrelevant bucket, make the same argument for a relevant object - like a grenade, or tracers. You cannot just get rid of everything or implement random delays or randomized origins.
It’s not reframing. The original argument I replied to claimed these hacks only exist because the server sends everything, and it would be extremely easy to fix this. Neither of which is true.
Followed by
Is wild to me.
Seems like you understand perfectly fine.
This is both you agreeing yet disagreeing with my argument and I don’t get the point exactly.
If its feasible reasonably, the point of your argument is diminished.
You’re fighting a strawman by pretending that my argument was ever to “just get rid of everything or implement random delays or randomized origins”.
My point applied in specific cases where relevant, and the dishonesty in your argument here is by acting like I am talking about not having a game. The bucket example was specifically about a bucket going towards a player from an unseen location with no line of sight.
For a situation like a grenade, the grenades direction becomes visible, somewhat randomized, from when the player should be able to see it. This presents no gameplay problems and solves the edge case of figuring out its trajectory for cheats, especially as a little bit of randomization results in a wildly inaccurate origin point.
As for the bullet, where are people shooting others without line of sight, where the bullets path would also simultaneously be visible? Its not a realistic scenario to bring up at all.
If we’re going to that extent, we might as well also then say that all client side anti cheat is worthless because you can use a secondary machine to read the ram of a primary machine or other such high effort cheating strategies.
Firstly, it absolutely is reframing, because they never claimed anything was a kill-it-all solution. They claimed one thing was a specific solution for a particular problem, which it is.
The only part that you actually have shown good reason to disagree with is the last claim, as with the second you’ve admitted that it in fact would be effective, but that there would be downsides potentially (as if there arent downsides with every option).
It’s tellingly ironic that for you it’s totally okay to make a broad statement, then when being called out cut it back to “where relevant”. And in the same sentence you make a strawman yourself, claiming that I’m acting like you are “talking about not having a game at all”. If you want your arguments understood “where relevant”, maybe show the same consideration.
As for the grenade and bullet examples I simply disagree. Given a certain observable trajectory it’s freakishly easy to get a good enough point of origin to get an unfair advantage with that information. As for an example about the bullets, I believe there’s enough FPS games with tracers out there. An extreme example would be Unreal Tournament Instagib matches. Where you see literally all tracers - directed at you or not.
Correct. Client side anti cheat can only make it so hard. Never impossible.
Yes, they said wall hacks would not exist if the server would only send what a user can actually see:
And that’s not true. Wall hacks would still exist, as necessary information can be used to determine an enemies position. To a certain extend.
And yes, put to an unreasonable extreme it would eliminate wall hacks entirely. Just nobody would want to play such a game.
Have a good day.
This is you restating your dishonesty. Acting as if you found something telling when you’re just reasserting the same bad faith lie isn’t telling anything.
Hyperbole is not a strawman. You in essence imply that if I don’t have the bucket, I can’t have basically all other critical game features because they all share something with the bucket (being server side solely in some situations).
How can you disagree with 2 different solutions with an answer that only responds to one of them?
For the grenades, a small change in the angle of impact massively changes the angle of launch. To the player having the grenade thrown at them from out of line of sight, this means they can’t use that information to snipe or prepare other than a very general direction, and its completely lost if there are any bounces or other randomizing elements in the grenades path.
To say this isn’t solved is to be irrationally demanding.
As for the bullet tracers, if someone is in line of sight, and shooting at you, the use of tracers is extremely limited/could be used regardless client side. I’m not sure why you feel this is a strong argument. Maybe you can elaborate but it seems like something more likely to obstruct than help if a target is visible.
If you are willing to go to that logical extreme, where the point of my comment was to say that decrying server side in place of as opposed to alongside client side system watching, is unexpected. It feels like you didn’t quite receive the message there, which is that every system is imperfect, but of them, technically speaking, server side is the least able to be compromised.
That to a certain extent is what I’ll focus on here, because to me its “in some exceptional cases, the thing that is largely eliminated can still exist” and to that, I would say that if we are being so strict for server side, we should be so strict about client side.
If we are so strict there, then we already know that client side fails too under these overly tight considerations, and I mean client side that magically works perfectly as intended.
This is as game audio is easy to use outside of a machine, and direct memory hacking exists as mentioned earlier.
The point is, sure, but as I covered with the point about grenades, the problem is pretty much solved, with some caveats as all things have.
This is where we disagree and it goes back to conversation above.
I don’t see any reason there could not be found an acceptable balance. For instance, even if you add some frames worth of prior information, giving that to everyone instead of allowing cheaters to have it is one possible solution, that even according to your feelings on what would make a game unplayable, would keep it playable. That is just 1 solution.
Sure you can, for starters audio is a lot less reliable to pinpoint location than video, so the server can randomize the position somewhat and still be accurate enough. Not to mention that sound bounces off walls, so it’s not exactly wrong to give the point of origin of a sound as a wall nearby the origin or destination, and an even more advanced system could use ray tracing to calculate sound path and give you a fully accurate sound point that doesn’t reveal the source exactly.
But again if you’re not sending the bucket position until it’s in FoV that doesn’t matter at all.
It’s not the end all, but it does take are of whole categories of hacks.
Still both can be calculated back to the source of origin. It may not be enough for a wall hack to reliably point out the enemies exact position, but definitely enough for a radar or proximity hack.
Edit: Your also completely ignoring the mandatory threshold where the server absolutely needs to send you enemy information already in order to avoid enemies popping into existence. The faster the game, the bigger that threshold.
And by all means, sound (in video games) is a pretty linear thing. You can only randomize so much, until players complain that it’s not reliable.
In the games were talking about these kind of additional info or heads-up are an unfair advantage in competitive play.
The solution sounds easy, but I do believe that if it was, we would see it in at least some current games.