For my anti-exploit, I decided to implement some client-sided checking to detect walk speed and jump power changes easier. As a measure to attempt to prevent players from deleting the LocalScript that gets put into their character, I put a second backup LocalScript in their HumanoidRootPart which checks every 0.2 seconds to make sure that the main script is there. The main script also constantly checks for the backup script, to make it significantly harder for inexperienced exploiters to bypass the anti-exploit.
This is pretty much useless, an exploiter can easily just delete the client script. No point in wasting resources on trying to make a localscript detect walkspeed/jumppower changes.
Also, the humanoid state checks are easily bypassed, so that’s also useless to do.
Not entirely. I see a lot of developers say that client-sided anti exploits are useless and shouldn’t be used, however many of those who use exploits on Roblox are most likely inexperienced and just use them for fun. Many probably don’t even know how to script.
In conclusion, I wouldn’t say that they are useless, nor would I say you shouldn’t use them. They would provide a little bit of protection. But on the other hand, they are weak and can be deleted.
It’s always good to do checks on the server just in case.
Thank you. My demographic is mainly 9-12 year olds so most of the exploiters don’t have much scripting knowledge. Of course I also have server-side checks but if it can be prevented from the client first it’s less performance heavy.
Client sided scripts are useless because of how easy they are to delete and change/exploit. It’s bad practice to let the client handle anything important.
However in your script it looks as if the main script doesn’t wait for the secondary script automatically making it look suspicious when main script loads in before the secondary script.
Check is also looking for script.Name which is “clientAnti”, whist the secondary scripts name is “clientAntiChecker”.
Are you checking for the name of the script before or after you change it’s name to the random characters? If you try printing “Check” after you set the variable and it comes out nil I’d suggest I’d suggest creating a function that checks for the script on a loop for a certain amount of times when it can’t find it and then kicks the player after it surpasses a certain set threshold
You should if you’re not already try setting the code that changes the name of the script before the check.
It’s also a waste of resources to run this on a loop. I’d suggest using statechanged instead. I also personally find it pointless to change the name of the script. If someone is exploiting it’s insanely obvious that a bunch of random characters is something you don’t want them getting ahold of.
Both of the scripts are set to the same random string for each player to make it a little bit more difficult for an exploiter to create a universal script to destroy them (I’m well aware it’s still easy to do). The names are set before they are parented to the character.
I’ve added a 5 second wait for the checking to start because the players said they were getting kicked after they died, so I’m hoping this fixes it. I will be releasing the update and updating this thread shortly.
My game is mainly for children and I’d say 90% of the exploiters are copy and pasting public exploit scripts into their injector.
You mentioned that you are placing the LocalScript in their HumanoidRootPart. When the player dies, their character is deleted and re-inserted. Sometimes their character doesn’t load in time either.
what’s happening here is that your main script is loading before your backup script is loading leading to the antievent check being triggered, to fix this maybe like wait a bit before checking
I’ve added a wait time before the loop starts for the checking of the other script, and this seems to fix the issue. Thank you!
I can’t use StateChanged because if the player stands still and then deletes both scripts one by one, nothing will be triggered because they deleted everything without changing their state.
