Note: “snapping” used in this post is when players quickly teleport from pos1 to pos2 repeatedly and rapidly, without legitimately walking in a smooth pattern.
What do you want to achieve?
I want to know whether detecting if a character is constantly “Snapping” positions rapidly is comparatively a better method of anti-exploit than validating the distance covered by a character.
I haven’t seen other posts discussing the issue with players “snapping.”
Many posts I’ve seen related to walkspeed or fly-hack anti-cheats use the “allowance magnitude” trick, such as this official one, where it checks to see if you’re moving at a way higher magnitude than allowed per interval. However, this poses another vulnerability.
Scenario 1:
Say an exploiter learns that it got kicked because of teleporting too much. Now, he learns to not move out of his “allowance magnitude” or expected distance for the image below. As a result, he “snaps” to multiple positions within the “allowance magnitude” and within the time interval, so that (for example) he could have more chance of dodging bullets. The server would only see points 0 and 6, since the wait interval haven’t reset.
(original image can be found in the official tutorial above)
This is an issue that can bypass many anti-exploits on the Dev Forum related to the “allowance magnitude” trick, so I concluded that while it takes up less computation, it’s not capable enough to stop “snapping” exploiters.
Any ideas how to solve? Currently, my solution is to monitor character’s position.changed event on the server (very broad idea).
Seems like an easy issue to solve. Here are the steps:
Keep track the current character speed and current position on every heartbeat.
Upon every new heartbeat update, get the next position and do this calculation:
local timeRequiredToReach = (nextPosition - currentPosition).Magnitude / velocity
-- The formula is based on distance = speed * time
Then use the new heartbeat delta time value and compare it with timeRequiredToReach. If the delta time is less than timeRequiredToReach, then mark this player as suspicious. Do take into account of network latency and the “noisy” values due to numerical computation. Also you can check if the player’s speed is too much for your liking as well, so you can stop teleportation cheating due to initial high speed.
Something like that. Though, we’re using the current speed to determine the maximum distance that the player could travel instead of hard-coding the maximum distance because the amount of distance travelled changes affected by many factors like gravity and friction.
You can’t really change delta time from the heartbeat. So it’s not really correct to say “should be lower”, or rather “didn’t have enough time to reach the desired location, but somehow that player managed to reached there”.
Also, don’t use humanoid walk speed. Instead, get the humanoid root part velocity or assembly linear velocity.
