I can’t say for 100%, but I am pretty positive that they can’t just erase a few lines of the code. Although, they are able to completely read/delete the whole localscript.
they can most definitely do this, all they need to do is copy the source of the localscript, modify that, and then create an exploit that deletes your localscript and replaces it with their own. As stated in my guide, you should only be using a client-side anti-cheat if it is also being supported by a server-side anti-cheat.
I do believe it is a common misconception that placing the anti-cheat code within important client-side code will protect it, security through this method or obscurity is never actual security.
You can use a server script to access it too.
local suspicious = {}
game:GetService('RunService').Heartbeat:Connect(function()
for i, player in pairs(game.Players:GetChildren()) do
local humanoid = player:WaitForChild('Character'):FindFirstChild('Humanoid')
local speed = humanoid.WalkSpeed
-- If they are going too fast:
table.insert(suspicious, player)
-- This is more like 2 step verification where the server adds them to a table and keeps checking to see if the problem persists.
-- You can loop through the suspicious table via while wait() loop outside the RunService function. You can double check through the other for i, v... loop and then kick the player.
end)
I’ve never tried this but just asking.
Is a script
in StarterCharacterScripts
considered client sided?
This is a very useful tutorial and I will keep all your advice in mind when making my games. Thanks for the contribution.
Theoretically, as long as you don’t freeze so hard that no data was sent to the server for 30 seconds, you wouldn’t get kicked. Also theoretically, network lag can’t cause a false positive on anti walkspeed/tp. It might be the anti noclip firing that.
Then again, this anticheat is for games without moving parts that pushes the player (on the new version, it takes account in collision group)
The reason why the method specified for checking the player’s speed uses math to calculate their speed based on the distance traveled since the last check is because any changes the client makes to it’s own WalkSpeed is purely on the client, the server merely sees the effects of changing this because the client owns the physics for their own character.
As for this, by all technicalities, a server script inside that location is on the server, however, as far as I am aware, the client is able to delete anything in their character model and this deletion will replicate to the server as well for some odd reason, meaning that the client can easily disable this script unless some sort of fail-safe is put in place such as this script contacting a server script in a place the client has no influence over (such as ServerScriptService
)
I was just hopping around the map with a youtube video playing, without any moving parts. Also, it seems to sometimes not account for respawning, I died at one point and it printed “Detected” when I respawned.
A person in your topic comment just bypassed it, don’t ever use a single localscript for the purpose of anti cheats. It will always be bypassed if you use 1 localscript for anticheats, this isn’t “unbypassable”.
Also, would this code be a proper anticheat? It’s meant to only detect speed hacks
I heard .running exposes the client walkspeed
while .Running does appear to expose the client walkspeed, I do believe an exploiter could still bypass this by making their client lie when the state is changed, or just decide to disable the running state and opt for a custom walking system. The best method as far as I’ve seen for checking how fast a player is moving still has to be the one I specified in the guide for the speed exploit check example.
It’s because of ping. The client didn’t know the character respawned and gives the old character position instead of the position after respawning. Only noticeable on like 400+ ping.
I kinda patched it. It’s like a zero-day bug.
you can combine .Running with magnitude, and it will work well, some dude on the topic comment just did this
.Running can be easily bypassed so what you suggest is just using more performance for the same result.
It might be even a worse result as false positives can happen on legit players.
i know .Running can be easily bypassed by teleporting instead, but yours can too
let me guess, jump out of a seat? pfft, it teleports them back, not kicks them, so it shouldnt be that much of an issue
fun fact: if you meant something like a run function, then do the run function on the server so it wont get detected : )
also i recently tested your anti cheat and it kept teleporting me back, you should fix that
fun fact, mine can’t
Actually, when you jump out of a seat, your state changes like this
Seated > Jumping > Freefall (unsure, it might just skip this one) > Landed > Running
The function connected to .Running will only start firing when your humanoid state is Running so it won’t teleport you back.
If you meet the condition that there are no part pushing the player then yes I will.
fun fact, uno reverso card
then what does?
no, no part pushes the player
if youre gonna continue this, dm me instead, im not gonna ruin some dudes tutorial again
I’ve updated the guide with a section on fly exploit checks and sections detailing how to secure remotes properly as well as what things the client is able to replicate to the server when it changes.
humanoid:GetState()
Just to add, exploiters can also spoof states, so getstating platformstand can easily be bypassed
Curious to see the code
All I’m doing Is im setting the Humanoid NetworkOwnership to nil (and it surprisingly worked)