No, it doesn’t kick for being laggy, I tested it numerous times.
2 Likes
punish them for freezing by teleporting them to whatever hazard there is :}
1 Like
If someone uses this glitch to exploit, and it’s prevention script is client side… can’t they just delete it?
1 Like
They could probably put the localscript in the character and have a serverscript check each player and if they don’t have that localscript then they get kicked.
3 Likes
Exploiting is a whole different issue. Most people who use this glitch wont exploit so it is still effective. Also you could add an anti exploit that checks if scripts are destroyed.
1 Like
This will absolutely kick players with lower performant machines as lower FPS means that the time between updates takes longer, which is the exact same thing you’re checking.
Low FPS = larger time gaps between checks on tick()
Your Code: if time gap > 0.2 then kick player
3 Likes
You can use this to setup this system & detect if the script gets destroyed, and the destroyed detector is serversided:
Step 1: Make a script in SSS and put the following in the script:
for i, v in ipairs(game.Players:GetPlayers()) do --THE FOLLOWING ONLY WORKS IF THE LOCALSCRIPT'S PARENT IS THE ACTUAL PLAYER'S STARTERPACK!!!
v.Backpack.ChildRemoved:Connect(function(child)
if child.Name == "Put The Name Of The LocalScript Here" then
local newClone = script.LocalScript:Clone()
newClone.Parent = v.Backpack
newClone.Disabled = false
end
end
end
Step 2: Make a localscript named “LocalScript” as a child of the above script AND MAKE IT DISABLED! Put this code in it:
-- This is basically the OP code
local RS = game:GetService("RunService")
local player = game.Players.LocalPlayer
player.CharacterAdded:Wait()
local HB = RS.Heartbeat
function WaiT(seconds)
local start = tick()
repeat HB:Wait() until (tick()-start) >= seconds
return seconds
end
while true do
local Start = tick()
WaiT(0.1)
if (math.abs(tick()-Start)) > 0.2 then
player:Kick('Freezing') -- Adjust the punishment to whatever fits your needs
end
end
Step 3: Make sure that you made another LocalScript with the above code in it labeled LocalScript and put it in StarterPack.
Done! 
1 Like
not having an update within 0.1 seconds means the llayer is running less than 10 fps. Thats why i recommended to change it to something like every 1 second with a gap of 2 so that way itd only kick them if they were freezing or running less than 1 fps for more than a second, which is realistically impossible.
2 Likes
This doesn’t actually work because changes like the script being disabled don’t replicate to the server.
7 Likes
But we’re changing the disabled property in the server… so isn’t it already replicated?
It doesn’t stop anything, i’ll tell you why though.
What your doing is adding back the localscript when it’s deleted. You also are disabling the scripts on the client, and enabling it on the server. But then guess what the exploiter does?
He/she disables the script after the server enables it. And the server won’t even know that the script was enabled back on the client, since it doesn’t replicate to the server.
2 Likes
Oh that makes a lot of sense now… I hate exploiters…
So basically check for Instance.Changed() and switch it?
EDIT: Or will the server not even detect the change?
The server doesn’t even know that the expoiter enables disabling a script doesn’t replicate to the server.
However, you could constantly disable the script on the server. BUT this absolutely won’t do anything.
The server can’t stop client code execution, disabling the local script on the server won’t do anything.
1 Like
So basically the best practice is to never use localscripts IN THE CLIENT for this stuff?
Yah, client side detection can’t really stop anything. Exploiters can stop any scripts running on their client.
1 Like
I found an old but interesting post regarding the detection of disabled localscripts.
However, I guess there is no technique to protect localscripts 100%.
There’s just some stuff you can’t really stop from getting exploited if I’m being completely honest. Like an exploiter can just change the CClosure of the script that’s making it so they can’t completely freeze their Roblox Client. When it comes to exploiting your best prevention measures are just to make everything server sided unless absolutely necessary to be on the client. This system requires being on the client since Server Scripts don’t have RunService’s “update” functions and events due to the server not really caring about it (even though it technically could, Roblox decided it shouldn’t.)
In this case however, it seems like you guys are overthinking the possibilites instead of the reality. No matter what you do, your projects can be exploited in certain ways. Stop trying to make the “most secure anti-freeze” script as even if you could, would all that hard work even matter? Someone will just make a completely new function to end up bypassing whatever security measure you just made.
This quote sums up what I’m trying to explain. Don’t over-complicate a system that doesn’t need to be complicated. Sure it’s flawed and can do with adjustments, but trying to make it a high grade prevention method is just oversight.
2 Likes
https://gyazo.com/ce4e206583fe6dfa12fbc6d5b59715c1
However, the client can setup their own remote function which returns a value. Bypassing the fact that the remote only works if the script is enabled.
For eg:
Client deletes the actual script:
Runs a script which sets up a listener to that 'disabler checker 'remote, here’s a pretty easy bypass of that system.
game.CheckerRemote.OnClientInvoke = function() --return some value end
2 Likes
Not even. They could just simply prevent OnClientInvoke from returning anything and cause the thread that invoked the RemoteFunction to hang. Typically why you will almost never see OnClientInvoke/InvokeClient being used. There is always a manual two-way remote communication going on in that case or use of coroutines.
1 Like
I’m actually very surprised this post is still up and available.
There doesn’t seem to be any reliable way to detect freezing. A WindowDragging event similar to UserInputService’s WindowFocused/WindowFocusedReleased events would be very helpful.