Spread seed calculation and an Overwatch system

Make the spread seed calculation to be server-sided. Reason is, currently cheat providers can manipulate the bullets to have no recoil, no spread and even worse, make the bullets a homing missile (called perfect silent aim, or pSilent for short).
This would make most aimbots ineffective, because not only do they have to compensate for the recoil, but also predict with the travel time and the trajectory.

An Overwatch system where it saves the highlights of the players, such as saving 5 minutes before and after the action happens, so that it saves as much space as possible. However, it’s important that the demos accurately shows the players’ view angles on the ticks they shot with their weapon, else it’s going to look like they’re aimbotting because the interpolation won’t accurately represent what actually happened.

Perfect Silent Aim is a form of aimbot where it shoots at the target without your aim being close to it. However, Valve added this convar, which records how the crosshair is actually moving, so for the cheater, it’s going to look like a normal silent aim, but for the spectator doing an Overwatch review will see the crosshair shaking and going all crazy, which is what’s actually happening, but the silent aim tries to hide that, which isn’t possible anymore in CS:GO.

With the spread seed calculation being server-sided and a reliable Overwatch-equivelant system, then majority of cheaters will get caught.

Source:

Online games should always be server sided client side of the server should always be verified while online to make sure the client side files aren’t edited based on file memory size too small or too large.

rust think that if they leave things like client side codes that control the environment of the server wont effect them its the reason why you see people jump hacking or aim bot.

How about both?

[editline]10th March 2016[/editline]

W1zard your on salt lake 1 right?

As great as server-sided is, it’s not something that’s feasible for everything, especially for FPS games. Aimbots, triggerbots and ESP are here to stay, unfortunately. It’s going to get even worse when hypervisors and neural network becomes mainstream.

However, for the time being, these two counter-measurements will go a long way to combat cheaters.

Well of course. I didn’t suggest otherwise.

I quit Rust until the next exp system rolls in.

If the path of the projectile is controlled client-side then this is indeed a problem. Ideally the only control the client should have of anything is “is the mouse pressed”, “where is the player looking” and “what keys is the player holding”. Everything else should be taken care of serverside. Of course the reality is never as simple, especially when clientside prediction gets thrown into the mix.

I’ve not seen this overwatch thing before, is it basically the game recording matches and letting lots of people rewatch them from a particular player’s perspective, letting them try and tell if that player is cheating or not? Sounds like a fascinating system, though recording all of Rust’s gunfights would likely be far too expensive in terms of server performance.

Overwatch doesn’t really work as a concept on a 4km² map in “rounds” that last three days between server reboots (or whatever schedule the admin sets). Rust isn’t really a round-based game.

Server-side validation is a “later” thing on account of the fact that once you commit to that every patch is double the work for any updates to the weapon physics: the client and the now-paranoid server. Failure to keep both in sync will result in false positives as clients “legally” do things within their limits that servers haven’t been briefed on as being newly-acceptable things.

While I don’t disagree that building netcode to use a fully server-authoritative architecture is alot of work, decent code design means that implementing new features doesn’t need to be done twice as the same code can be shared between client and server.

The Overwatch system is on a relay server connected to the other servers. It could be connected only to vanilla servers, so that it doesn’t record on battlefield/deathmatch servers and such.

It’s instead “action-based,” as in, it only saves the recordings of player contacts.

No, that’s not how it works. You’re partly correct in that it’s a later thing, however, the clients does not have the right to do any funny stuff within a certain moment. The seed is generated server-side to a random number, so for a client to be able to manipulate the spread, they would have to brute force it every single time the server restarts. It’s just not feasible.

Typically it’s desirable for the client to be able to calculate spread in the same way as the server so that when the player fires, the projectile travels in the same direction as on the server (since you don’t want to hang around and wait for a server response when the player shoots or gunfights will feel laggy and horrible).

In other words, everything will feel the same for you, because what you see is client-sided, but what’s actually happening is server-sided. However, as confusing as that might seem, it’s actually completely fine, because you can’t predict the spread, since it’s random anyway.

It’s the pattern you have to predict, which you do from the visual feedback you get, such as screen shake and such.

Ah I see, thanks for the clarification. I was mostly going off the Source Engine protocol which does share the RNG state with the client, or at least allows the client to predict the spread - but this makes more sense for competitive games like CS:S & CS:GO where it does matter that the client sees accurate shots.

Funny you say that, because this is actually taken from CS:GO. I know, right; I had the same thought when the update came out. However, surprisingly enough it doesn’t affect gameplay in any way, because there isn’t actually any need to know exactly where the bullet landed.
Reason is, you have a muscle memory of the pattern, while also having visual feedback, such as screen shake, viewmodel and tracers, for where in the pattern you are, and that’s really all you need to know to control your spray perfectly.

Now, the biggest difference with CS:GO and Rust in terms of gunplay is that CS:GO has hitscans, while Rust has projectiles. However, this doesn’t really change anything, because it’s the same in practice. There’s no need to know exactly where the bullet is landing to lead a target properly, because it’s the hit you learn from, as well as where it lands approximately is more than enough to learn how to adjust correctly.

Don’t know how viable it is in an open world game, but how Valve deals with speed hacking is that they throttle how many packets can be sent to the server, so if a cheater tries to manipulate velocity, they’ll experience packet loss and/or FPS drops.

Not sure if that combats gravity hacks, but I’m pretty sure that can be cheat-protected, the same way it is in Goldsource and Source engine.

Another thing, if players are outside the drawing distance, then the client should not receive theirs’ player position anymore. A very simplified version of SourceMod’s Anti-Wallhack.