I made an anti-speedhack/teleport script. Will it function as I intend it to?

Help and Feedback Code Review
#1 
--Movement Validator
local LastPositions = {}
local MVLastRun = 0
local MVStep = .1
local PlayerWalkspeed = 16
game:GetService("RunService").Heartbeat:Connect(function(dt)
	if MVLastRun < MVStep then MVLastRun = MVLastRun + dt return end
	MVLastRun = 0
	for _, plr in pairs(Players:GetPlayers()) do
		local char = plr.Character
		local hrp = char and plr.Character:FindFirstChild("HumanoidRootPart")
		if char and hrp then
			if LastPositions[plr] then
				local deltaXZPlane = Vector3.new(hrp.Position.X, 0, hrp.Position.Z) 
					- Vector3.new(LastPositions[plr].X, 0, LastPositions[plr].Z)
--this line below im a little worried about
				if math.abs(deltaXZPlane.Magnitude) > (PlayerWalkspeed * MVStep + 1.5) then 
					print("SPEEDHACK DETECTED"..math.abs(deltaXZPlane.Magnitude))
					hrp.CFrame = CFrame.new(LastPositions[plr])
				end
			end
			LastPositions[plr] = hrp.Position
		end
	end
end)

Basically if a player moves too much in the XZ plane then they should be teleported back to where they started.

I’m concerned this script isn’t implemented properly because in the line I marked, without the + 1.5 studs the server detects that I’m speedhacking in Play Solo mode even though my character’s walkspeed is 16.

4 Likes
#2

That’s a very complex and good looking script! Have you tried it? If so, good job!

1 Like
#3

Yes i did try it, thats why I had to add +1.5 in the magnitude comparison. If I don’t do that then the server thinks i’m speed hacking. I think theres some extra movement because of latency and I don’t know exactly how that works.

1 Like
#4

If you add some sort of vehicle to the game, will the script think that all the extra movement is speedhacking or not?

1 Like
#5

I was gonna make the playerwalkspeed a changeable table through a function so it can account for when a player enters a vehicle

2 Likes
#6

How will this account for legitimate walk speed changes such as a “shift to sprint” or if the server throughout the game needs to change the player’s walk speed?

1 Like
#7

I’m coding an advanced anti-speed-hack myself. One of the key factors one should take into account is that some players (especially the ones playing with their friends overseas with really high ping) will experience light to moderate ping jitter. Ping jitter is basically the ping value changing over time and it can change spontaneously in magnitudes of up to 250 milliseconds (A Roblox character could walk 4 studs in that period of time). During the moment the ping is increasing for a player, the server will not receive position updates for a bit and the player movement will literally start looking jittery for other players.

Thankfully Roblox does some physics prediction and smoothing server-side, so it will make speed exploit detecting scripts get angry less, but only to certain amounts of jitter.

JItter tolerance is easy to apply once you know what would be the best jitter tolerance value that would suit the majority of roblox players. Recently I’ve noticed one player who experienced instant ping changes up to 200 ms and that player might start having issues with your code. I’m still not sure what kind of ping jitter does the great majority of the Roblox playerbase experience and thus it requires more research.

Once you know what would be the ideal ping jitter tolerance, you just multiply your max tolerable velocity by (1 + ping jitter tolerance in seconds).

For example, if we decide to tolerate 250 milliseconds of ping jitter with 16 walkspeed:
16 x (1 + 0.4) = 22.4
(Players with less than 250 millisecond jitter should not exceed the speed of 22.4 studs per second.)

However, in practice, if you tried to read player position delta server-side you’ll find out that server will observe jittery position changes in player HumanoidRootPart even when their internet connection is not jittery at all. In that case you’d have to add even more tolerance overhead to protect the more “jittery” players from getting annoyed by your anti speed hack. But that’s where it would start falling apart - if our new tolerance values allow non-jittery players to achieve speeds of well beyond 20 walkspeed, then we have failed to make a meaningful anti-exploit.

Fortunately - If we track the history of player positions for the last “max_jitter_tolerance x 2” (eg. 500 ms) seconds and find the difference between position1 which existed, for example, 500 milliseconds ago and position2 which is the position the server is experiencing currently, we will see the TOTAL of distance the player has moved over the past 500 milliseconds. If the maximum jitter a player was experiencing was below 250 milliseconds, then the total distance moved (That was experienced server-side) in those 500 milliseconds will be much more likely to be closer to “WalkSpeed x 0.5 seconds”, and we’ll need way less tolerance overhead to make the anti-exploit less sensitive to other unexpected stuff.

Hopefully someone will make sense of what I’ve written here lol.

Also it should be obvious that this would only work on players that are not moving inside a vehicle. Vertical exploit detection is possible, however it gets much more complicated lol.

11 Likes
#8

I reccomend you use another part to base your position checking off of, as exploiters can just delete the humanoidrootpart and go on with their day.

Deleting the head would instantly kill the player, so that could be a good alternative.

#9

Forgot to mention that you should also take into account for a player’s ping - else it’d just be hell for players with, say, 300+ ping.

#10

It is normal that without the “+1.5”, the server is detecting speed hacking. The reason it happens is because the character is moving slightly faster on the server, so don’t be concerned about that. Another thing, I wouldn’t TP them back on the first trip, unless they move extremely far (like 200 studs in 1 second), if they don’t move very far, I would wait for multiple trips in a short timespan, like 4 trips in 10 seconds. Also, if they move very far (500 studs or something like that), I would respawn the character, because it’s obvious that they are speed hacking or teleport hacking. No laggy player would ever go that far, so it’s safe to respawn them at a distance that high. You can choose if you want to do that, but if they don’t move too far, don’t teleport them back on the first trip, and if they do move very far, you can teleport them back instantly or respawn them (even though thy are obviously exploiting, banning would be too severe, and simply making their exploits not work at all will be enough to get rid of exploiters). Now, exploiters could still get a tiny advantage if you leave a little room for that, but going very strict would also annoy laggy players. Don’t worry about exploiters taking that small advantage, they really aren’t going anywhere doing that.