Ok so, someone made a instakill hack and leaked it, for my game. I need a a way for the damage remote to know if the request is hacked or not.
I cannot fire a ray on the server, or have a serverside bullet because the bullets have bullet drop, and because the players look different on the clients than the server (footplanting and holding weapon etc).
I also cannot make the server check if the weapon has been fired in the past because the bullets are not instant-hit.
Putting a “key” on remoteevents is basically useless because hackers can fire the remotes anyway through my code.
it fires the event with the direction from the camera to the targets character, and a bodypart from the targets character,and the equipped guns name. the server then gives damage based on the bodypart hit
An easy way to solve it might be to send an event when the bullet is fired and another when the client thinks they hit something. In both cases, also transfer the fire/hit position. On the server, store tuples of (player, server’s time, firing position). Whenever a player says they’ve hit someone, compute another (player, server’s time, hit position) tuple, then scan through your list of previously fired bullets for that player, and check that it is feasible that one of them correlates to a bullet fired earlier. Or, add a unique ID to each bullet so you don’t need to do the scanning part and can just check the tuple you stored beforehand for that ID.
You’ll want to check these things:
Reject storing a firing position that isn’t close to where the player is at.
Reject “hits” that cannot have reasonably covered the distance between the time of firing and the time of hitting.
That’s something you can tune for and even if so, it wouldn’t be the end of the world, it just means a few bullets might not go through as hits, but they wouldn’t cause the player to be kicked or anything.
There’s no way around this that doesn’t involve either having to deal with exploiting or with lag in some way. You can’t have your pie and eat it. You can handle unexpected network delays better by finetuning parameters of these algorithms.
I wouldn’t do that as they would adjust the exploit to feed you fake time values. I would stick to server time and just try to make it decently lenient to account for any network delays. (So you wouldn’t check if it exactly covered the distance in that time, but you’d have like a +20% margin of error on both sides or so)
I think ill be able to fix the lag problem by using the clients deltatime?