Hello! I know that there probably isn’t a way to Set the network owner ship of a raycast but i’m going to ask anyways since i couldn’t find a proper answer.
I have an attacking script that shoots a raycast out of the attacker’s humanoidrootpart that damages any player infront of it and it works great As long as you aren’t laggy which is why i’m asking about this.
When a player does happen to be even a little laggy and they attempt to damage a player in front of them on their screen that player doesn’t actually get damaged because they are technically out of raycast’s range on the server despite the attacker being very close on their client making it feel unfair to the attacker which should be prioritized. Now my script is already a little to complicated for me to just morph it into a local script so i was wondering if you can set the network owner of the raycast to the attacker? Any help is apreciated. Thanks!
The best approach, as far as I am aware, is to draw the raycast on the client first; if it hits, pass it to the server and then do sanity checks to make sure they aren’t exploiting this. You can draw another raycast on the server, which will always be subject to some delay even if it’s a fraction of a second, and compare the two to verify if the player is doing things otherwise impossible.
FPS anti-cheat is a serious pain because players want responsive gameplay which generally is a challenge for protecting players from exploiters. Responsive gameplay comes from running as much on the client as you can while minimizing the damage hackers can do with such vulnerabilities.
How can you do sanity checks? I’ve had this exact same issue.
Well, the more sanity checks you do the more you risk “no-regs” and the like. Say you check on the server if the player’s ray intersects with a wall; they may have actually hit the player on the client, but on the server, with its very short delay, the enemy actually made it around a corner at the last second. This means that the server will see the bullet hit a wall, but the client saw a clean shot and perhaps even showed a hit marker.
The less secure, the more reliable shots will be for your genuine players; but the more prone to exploits it will be from those who maliciously take advantage of your code. Keep in mind that exploiters can access everything on the client; they can browse your scripts and client-side explorer to examine how it works. They will undoubtedly try numerous times to misuse it. The less they understand what is happening on the server side, the better.
Edit: this is why no regs is generally a problem in every shooter game, sanity checks prevent the shot from registering on the server even though it hit on the client.
I understand what you mean, but like how would you actually do this? Like when you receive that the bullet had touched them and you send that result to the server, does that side do the raycast? Would determining the difference between where the ray hit and the distance between the nearest player?
To start, you verify that all of the expected data is true. Then, you check additional things; such as whether the player is shooting from an impossible angle (such as flying through the sky, or from underneath the map).
Basic sanity checks:
- cooldown of weapon; is player firing faster than possible?
- starting point of ray; is player firing from their barrel (or wherever is the intended behavior)?
- hit detection; did player actually hit an enemy? Was it close enough on the server that the client was probably right about the hit?
- ammo; does the gun actually have bullets in the magazine?
Extra sanity checks:
- accuracy; is the gun snapping to targets with a faster response time than humanly possible? Is the accuracy of the shot 100% direct center mass of target (e.g. direct head shots to the center of the head)?
- is the player touching the ground? In many games, players can shoot while falling off of a building or low platform, but if a player is flying for more than a few seconds; in most cases they are exploiting (check their position regularly and verify that they are indeed returning to the ground as usual). Movement sanity checks can be a pain because there is latency between the clients movement and the servers checks. You don’t want players getting falsely flagged. Auto kicks and bans for this are not recommended, but it’s still good to have loose checks for those who are blatantly doing it.
This is not a comprehensive list of sanity checks, but these are good basics to start. The important thing to understand is that the server should not trust ANY information the client provides. It should not trust that the player is shooting according to the weapons cooldown, or that they are passing positions that are accurate (starting and ending positions of rays). It should not trust that the player could actually see the opponent. Any information that a hacker can pass through a remote must have sanity checks or exploiters will most certainly slip through.
To be clear, it is virtually impossible to prevent all exploits. The goal is to make it a painful process for exploiters to uncover, and you can add auto-ban features for anything that is impossible for a normal player to do (e.g. a normal player cannot manually change what a remote sends; therefore if the server is receiving altered remotes there is often ways to figure that out). A prime example of this is a shop script. If you sell a weapon in game, and a hacker sends a remote to buy the weapon without having the funds or the level requirement (given that you are not sending remotes for this in the first place), then you can be certain they’ve attempted to exploit.
I see, I appreciate your in-depth explanation and effort to educate. I’m a bit confused on the rays part. Why would send a raycast if the whole point of a gun is to fire a bullet with velocity?
The problem with thinking this way is that what about the target player?
Players aren’t going to like playing a game where the laggy players have a priority advantage.
Imagine playing and you run up to the corner of a wall with no other players visible. Then suddenly you’re dead because the laggy player had you in their sights 2 seconds ago but you couldn’t see that they’d already walked around the corner on their client but that hadn’t been replicated to the server and back to you.
Raycasts are often used for hit detection with weapons because Touched events and other methods are often unreliable for fast moving parts. If a bullet is traveling at hundreds or thousands of studs per second, it may be skipping past several studs, if not dozens or hundreds of studs, per frame.
Generally, the bullet itself is rendered on the client; and sent to the other player’s clients to render separately for each. If it is rendered on the server, you may see the bullet lagging if your internet is unstable or low speed. For games with delayed projectiles or bullet drop, multiple rays can be drawn from end to end to simulate the path of the bullet and detect hits. The raycast itself is usually invisible, and only exists momentarily. Everything else you see is just for effect; to immensity the experience.
Ohh, I understand. I feel bad for hijacking this topic but how long are the rays usually when daisy chaining eachother?
Feel free to DM me if you’d like to discuss it further. I haven’t personally tried that yet myself, but I plan to when I add bullet drop to my current FPS/TPS system. I suspect it’s largely up to the developer’s preference, but is likely dependent on the speed of the projectile and the rate of drop. Less speed and more arc means more rays to simulate it.
Alright, thank you a lot for the help. I’ll DM you soon as I need help with a simple tool I was making
Well you see there is only one attacker, a player chosen to be a monster. While the rest must survive. That’s why i want to give the monster (using the raycast) a better advantage of being able to actually hit players that seem to be very close on their screen and of course i’ll add some kind of saftey measure to avoid hits from the other side of the map or what not to not be registered.