Currently, I have guns that raycast on the client. I would like to have raycasts on the server to prevent people from bringing others to themselves clientsidedly and killing them. This method did not work out for me however as 7/10 times the raycast misses and the user does not get damaged. Can anyone help me out with this?
Thanks, uppkr.
Send the origin of the ray, the hit position and the part that got hit. Check that the origin isn’t too far from the player and that the part in question isn’t too far from the hit.
An exploiter can control what to send to the server and they may choose to send values which would comply being “Not too far” but that would hardly change anything.
Latency also comes in play, if you have a very high ping, the server would get the values after a prolonged delay and it could result in inaccuracy and false positives.
Let the client handle the visuals and detection and let the server verify.
Let the server handle the detections and visuals
For this reason, hit detection and visuals should always be done on client and the server should only act as a verifier of whether it is valid or not. There however are some other reliable ways to cope with this.
You can also look for other reliable methods such as FastCast which is an open source module for handling projectiles and hit detection
He asked for sanity checks, not an anti-cheat.
As you said in your first point, it hardly changes anything. The worst they could do is shoot from behind a corner, but that can be countered by casting a 2nd ray and checking for static objects on the server.
The lag part actually works in your favor as it ends acting as a cheap anti-lag-switch.
FastCast isn’t required here as its main purpose is to simplify bullet drop, which this post doesn’t have.
In addition to what @nooneisback said, you should raycast from the origin to the hit point as well to ensure that the path is clear.
Sanity checks are meant to tackle cheats and I never gave him an anti cheat.
Also I don’t get which lag part are you talking about.
The sole purpose of this post is problems with client sided hit detection and if you read how fastcast works it tackles this very well
Fast cast is suitable for moving projectiles and bullet drop, if he is making a simple ranged weapon, basic raycasting is ok.
Another advantage I would like to add for hit detection client side is that the server is essentially free of load and only has to deal with reverse constructing rays to verify the shots and damaging. If every player sends a remote event to the server for every bullet no matter if it hit or not, it will severely affect the server performance and it will underperform
Events coming in too late should be dropped anyways. A 1 second threshold is a reasonable value. This means that you lag argument is invalid. Lag switches forcefully prolong your ping and having the system detect it as a too big of a distance works in your favor.
I know how FastCast works and had a very similar system set up in multiple abandoned projects 5 years ago. It is nice, but it only solves the problem of hit detection and validation with curved trajectories, which is not the case here.
What is being affected here is user experience, especially when you are moving all the time in a Fast Paced FPS. Rays being casted 1 or 2 seconds later is a major flaw in this case. Theres a huge difference experience wise if you shoot someone and they dont take damage even with a 100 ms ping if you are running all over the map and shooting someone and getting damaged later after verification (since the measurements and detection has already been done)
I don’t see what you are replying to right now.
Any event that comes over 1 second later should be ignored.
but how would you even know if its 1 second late on the server may I ask
Would you be calculating ping?
Yes, that is one of many ways to do that.
What would you consider “too far” from the part? 500 studs?
Depends on the part’s velocity.
--get the distance between the hitpos and the part, then subtract its diagonal to avoid false positives with large parts
local (dist = hitpos - part.Position).Magnitude - part.Size.Magnitude/2
--set up the threshold
local thres = part.Velocity.Magnitude*2+2
if dist>thres then
--invalidate shot
end
If you consume time in checking the ping, which will be a request to the client and back. Thats just adding up the latency
Many games send 50+ requests a frame. Your empty invoke won’t do anything.
it adds up to the latency, even if you dont do anything, a call is being made and the server has to actually get the ping making the round call before it can actually continue with the damage. The load is not what im talking about
Not if you properly schedule your code. Invokes yield your current thread, but not others, meaning you can just run a thread that loops invokes the entire time and yields while waiting for response. That’s actually how I handle input from my server sided characters I’m working on.
[SERVER]
local indexPlayerExists = {}
--events fire on a separate thread
servicePlayers.PlayerAdded:Connect(function(plyr)
indexPlayerExists[plyr] = true
while indexPlayerExists[plyr] do
local inputdata = remfuncInput:InvokeClient(plyr)
--handle input
end
end)
[CLIENT]
remfuncInput.OnClientInvoke = function()
local olddata = inputdata
inputdata = {}
return olddata
end
Your points are valid but I don’t think there would be any use of FastCast here.