How to check ping and use it for WalkSpeed anti exploit?

[Kampfkarren (boyned)]

You check the players ping by sending the client’s time whenever it sends a RemoteEvent (you can plug this into as many RemoteEvents as you want or just have one dedicated to it), then when the server receives it subtract the server’s time by the time given by the client. Start to average it out over time and make sure your averages aren’t global (otherwise outliers will destroy it). Instead, have ping average in the context of a short period of time (i.e. average out their pings in the last ten seconds).

You make sure they can’t alter the ping parameter by checking on the server if all the times are valid, not ahead of the server, etc.

The most a player can go with a latency of n seconds (assuming they’re frozen in place for all that time) is just that time multiplied by their walk speed. Be generous and have a margin of error, and don’t immediately start kicking people when they break this limit. Ping is variable.

[Beartikal]

So would the average out have to be 10 seconds?

[Kampfkarren (boyned)]

No, it was just an example.

[Corecii]

@Kampfkarren

subtract the server’s time by the time given by the client.

This is not how you get ping.

You get ping by getting the local time, asking the client to respond, then checking the difference between the new local time and the saved local time:

local start = tick()
script.PingRemoteFunction:InvokeClient()
local ping = tick() - start
-- you should actually use RemoteEvents instead, but that's too long for an example

There is no way to guarantee that the server and client’s clocks are synced up enough to tell differences in milliseconds. In fact, it’s very likely that the server, client, and all other clients have clock differences of multiple milliseconds, maybe tens of milliseconds, or multiple seconds! It’s not possible to 100% accurately measure the single-trip time.

This is also called round-trip time, because it’s the time it takes for a message to go to and back i.e. a round-trip.

---

You can’t very accurately change the allowed player velocity according to ping. The most you can do is say “the player could have been moving for as long as their ping time without the server knowing”.

Instead, you should have higher thresholds than the actual speed and up those thresholds some for high ping. For example, have a normal limit/threshold of 20 studs/per second, but with a 1 second ping you up it to 30 per second.

If it’s not clear, you should not have a threshold/limit of 16 studs per second/walkspeed. I noticed in one of your previous posts that you had your threshold set that low. That’s way too close! It’s expected that some exploiters can barely get through with a slight advantage. There will always be an overlap between network latency, player skill, and exploiters. To catch all exploiters, you would also have to catch all high-ping players and high-skill players, which would not be a good thing.

---

Edit: Example using RemoteEvents

-- server
local pings = {}

game.ReplicatedStorage.PingRemoteEvent.OnServerEvent:Connect(function(player)
	local pingInfo = pings[player]
	if pingInfo and pingInfo.sent then
		pingInfo.received = tick()
		pingInfo.ping = math.clamp(pingInfo.received - pingInfo.sent, 0, 5)
		pingInfo.sent = nil
	end
end)

local function playerAdded(player)
	pings[player] = {
		ping = 1
	}
end

game.Players.PlayerAdded:Connect(playerAdded)
for _, player in next, game.Players:GetPlayers() do
	playerAdded(player)
end

game.Players.PlayerRemoving:Connect(function(player)
	pings[player] = nil
end)

spawn(function()
	while true do
		for player, pingInfo in next, pings do
			pingInfo.sent = tick()
			game.ReplicatedStorage.PingRemoteEvent:FireClient(player)
		end
		wait(5)
	end
end)

local function getPing(player)
	return pings[player] and pings[player].ping or 1
end

-- client
game.ReplicatedStorage.PingRemoteEvent.OnClientEvent:Connect(function(player)
	game.ReplicatedStorage.PingRemoteEvent:FireServer()
end)

[Kampfkarren (boyned)]

I completely blanked on the definition of ping. This post is correct.

However, using RemoteEvents instead of RemoteFunctions is NOT advisable here. You’re just adding extra overhead for the exact same effect. This is one of the few cases where RemoteFunctions are the correct solution.

[Beartikal]

Any way to tell if the client is exploiting their ping/remote fire delay?

[Kampfkarren (boyned)]

If they’re sending lots of other events in the meantime.

[Corecii]

@Kampfkarren

However, using RemoteEvents instead of RemoteFunctions is NOT advisable here. You’re just adding extra overhead for the exact same effect. This is one of the few cases where RemoteFunctions are the correct solution.

It’s never safe to ask the client something i.e. use InvokeClient. The client can error, disconnect, or yield forever. Then what?

It’s always save to use InvokeServer, and in my opinion it’s rarely ever safe to use InvokeClient. Check out the example code I added to my original post.

---

@Beartikal

Any way to tell if the client is exploiting their ping/remote fire delay?

No way that I’m aware of. You could have penalties for too high ping. It’s entirely possible for an exploiter to actually increase their ping for their whole network if they wanted, too.

If you use something like my example, you could check if the sent time was too long ago and give a penalty if it is. Any real player with a reasonable connection would respond within two seconds in the worst case scenario (e.g. 3G mobile network that’s switching connections, satellite internet that can barely play Roblox, etc.) Most players will respond within 0.3 seconds.

[Kampfkarren (boyned)]

In your example, you are using RemoteEvents in the same vein as RemoteFunctions. If the client errors, disconnects, or yields, then you don’t use the same thread. They’ll be failing your ping checks, and you can sufficiently say that they’re either horribly laggy (which nobody enjoys) or are a hacker.

[Kiansjet]

It’s impossible to differentiate between someone using a network lagswitch and someone actually pinging bad. I think this solution I proposed earlier today may be a tad bit more reliable.

@Kiansjet

What you could do is keep multiple previous records of player positions, so if a player only travels 8 studs on check 1, but 24 studs on check 2, with a walkspeed of 16, the two would equal the allowance of 32 studs over 2 seconds. Of course people may stutter for more than a few seconds, so you may want to keep record of 5 or 10 per player depending on your memory usage and performance preferences.

PS: These threads are closely related. If you have any more questions in regards to your anti-exploit, making a new thread may not be the best idea if it’s closely related to a previous one.

https://twitter.com/KiansjetRBX/status/971208479313571840

[Corecii]

I think RemoteEvents are a much cleaner way to do this. If you implement it using RemoteFunctions then you have to create a new coroutine every time you call it and do error checking. I’ve rewritten the example using RemoteFunctions and it looks messier and harder to understand at a glance for me.

Additionally, it’s easy to forget to use a new coroutine and implement error checking, and even easier to forget or forgo for any beginners that might be reading this and don’t know how to do those things. Using RemoteEvents prevents even the chance of leaving those things out, as they’re not necessary when using RemoteEvents. RemoteEvents do not add significant overhead.

Example

-- server
local pings = {}

local function playerAdded(player)
	pings[player] = {
		ping = 1
	}
end

game.Players.PlayerAdded:Connect(playerAdded)
for _, player in next, game.Players:GetPlayers() do
	playerAdded(player)
end

game.Players.PlayerRemoving:Connect(function(player)
	pings[player] = nil
end)

spawn(function()
	while true do
		for player, pingInfo in next, pings do
			coroutine.wrap(function()  -- we use coroutine.wrap because spawn does not start instantly
				local success, err = pcall(function()
					pingInfo.sent = tick()
					game.ReplicatedStorage.PingRemoteFunction:InvokeClient(player)
				end)
				if not success then
					warn("Failed to get ping: "..tostirng(err))
				else
					pingInfo.received = tick()
					pingInfo.ping = pingInfo.received - pingInfo.sent
				end
			end)()
		end
		wait(5)
	end
end)

-- technically you could take out the pcall and let it error, but that just sounds bad to me

local function getPing(player)
	return pings[player] and pings[player].ping
end

-- client
game.ReplicatedStorage.PingRemoteEvent.OnServerInvoke = function(player)

end

There is the upside that you can catch if the client errors for any reason, such as injected code.

There’s a few posts in this thread that share my opinion: “RemoteFunctions are unsafe.” Additionally, the very last post states that it’s actually faster to use RemoteEvents than RemoteFunctions i.e. one RemoteFunction call has more overhead than two RemoteEvent fires.

I’m not going to tell you to never use RemoteFunctions for stuff like this. If you like it better then feel free to use them. I think there are many good reasons to use RemoteEvents instead, though, and I’ve attempted to bring some up for consideration.

[Kampfkarren (boyned)]

A thread which I don’t have access to.

[Autterfly]

For future reference;
D = (R / 2) * WS
Where D is the (rough) max distance (in studs) a client should be able to travel under R seconds of round-ping at WS walkspeed.

Value Type: float
Description: Used to set how quickly a Humanoid can walk in studs per second. The default value is 16.

Even then this may not be very accurate. WalkSpeed is one of the harder things to stop, since distance checks are only really effective while taking into account all sorts of things, which may include but are not limited to:

• Network latency
• Hardware framerate
• Synchronization Client->Server

The fact is, if you have the math down to the last decimal, it’ll work perfectly on a holy and perfect connection, but would instantly die the second a network spike is hit.
Give it too much leniency and suddenly each little bit of that can be taken advantage.
Make it too strict and now your normal players on the lower end hardware (or even just environmental or geographical factors) are hit hard.

You have to compromise on this, and it’s probably not worth much of the effort.

[Corecii]

That’s one reason we need a Upcoming Developer tag as a reminder to only link to public topics or instead use quotes. You’re already aware of that, but I just thought I’d mention it for anyone else reading who hasn’t seen the thread.

Here are some relevant bits from that thread

• 72% of voters use only RemoteEvents
• 25% of voters use a combination of RemoteEvents and RemoteFunctions
• 3% of voters use only RemoteFunctions

@Tiffblocks

I use RemoteEvent for server -> client broadcast, and RemoteFunction for client -> server.

@Tiffblocks

Even when the RemoteFunction has no return value, I still use it because of this semantic distinction between client -> server and server -> client.

@Anaminus

RemoteFunction: Interesting, but ultimately unsafe. Would be more safe if it had a timeout mechanism.

@Rerumu

And regarding security and timing out I believe RFs do time out but one of a number of requirements have to be met, but that wouldn’t really matter because the returns can still be caught from __namecall.

I know they’ve timed out for me when I:

• Did not implement OnClientInvoke/OnServerInvoke
• The client’s ping goes above a certain extent or they just get generally very laggy
• The client disconnects

@NWSpacek

What communication devices you use depends entirely on your game.

Do you have a lot of data that the client can request at arbitrary times? You will need a few remote functions.

Do you have a lot of different inputs that clients can send only at specific times? You will need a few remote events.

@Arificiality

It’s ironic that RemoteFunctions are really slow. They have their uses though.

It’s actually faster to fire a remoteevent and then fire the client back with the data, by a very large margin, than to do one RF call.

[Kiansjet]

It’s “New Member” now. I don’t blame you if you’re losing track lol.

[General_Scripter (Aaron)]

The problem with the possibility of players being flung around due to players colliding or a player jumping in a confined space could always throw some false-positives when working out the magnitude between two vectors. The same would apply if you were to teleport players.

I have made an experimental anti-speed exploit file. I noticed that quite a lot of false positives were thrown when including the Y vector in the calculation due to falling. Feel free to take a look at it, knowing me, I’ve probably done quite a few things wrong but it works as far as I can tell. I just haven’t really had the opportunity to test it with larger servers than 2-3 players.

[Kiansjet]

Or you can just ignore players with humanoid states like jumping, falling, free falling, and ragdoll.

[Kampfkarren (boyned)]

So they’ll just set their states to those.

[Kiansjet]

Does it replicate over FE?

EDIT: I’d test it myself if I could immediately.
I’m at school from 7-3 and I go on DevForum during passing periods and break.

[Kampfkarren (boyned)]

That I’m unsure of. If you ever have a question that can easily be tested, just test it.