It’s not worth the hassle, in my opinion. Sure it will prevent people for a little while, but It sparks a flame in the exploiting community and it’ll only be a while before someone racks their brains together and comes out with a patch to your patch. It’s just a game of cat and mouse that is unnecessary. You should have good server side checks and make your game not affected by exploits the local character can do. Like I’ve said, there’s plenty of methods to check for speed hacks, jump hacks, teleport etc. If worse comes to worse, just make a custom character without a Humanoid - like Luanoid.
Your attempts to make an anti cheat should be fully server sided, I played around with client anti cheats for the past couple years as in the swords community, exploiting is a big issue with people resizing their handles. Long story short think outside of the box and try to fully understand what’s being exploited in order to develop something which will run from the server and you’ll need to identify weak parts in your game while doing this. While its not the best idea, something I found extremely funny when creating anti cheats was that if you put your script inside the control script, all the way at the bottom, use FindFirstChild instead of waitforchild so it does not yield in the Dev Console locally, most players would never find the local script since its inside something they see in every game they exploit. Eventually I felt so bad about having such a weakly designed system that I redid it but, this bought me enough time to be able to think out everything I need to create a server sided anti cheat for swords.
Very interesting, will be looking into this. This is one thing I’ve actually never used before in studio. With findFirstChild just verify the item exists by checking if its nil so it does not error and, thank you for the tip!
Yeah, I found out about it when someone in my dev team was looping through ~2.5k objects and doing this code:
repeat
wait()
until obj:FindFirstChild(name)
just to avoid the message in the console. I knew there was a better way, and looked up on the WaitForChild wiki and saw that if you specified the timeOut parameter, it would not print in the console
Before finishing I would like to Wish you lots with your creations (GAMES) In ROBLOX you have a lot of patience and above all love in your own creations that’s all Thanks for reading my message.
I leave a link for you to see another case Clic here
Hiding your localscript isn’t the way to go. Indeed it may prevent exploiters from finding your script by name, but there are plenty of other ways they can use, such as hooking FireServer, getting the calling env with getfenv(2) and from that point obtaining the script.
I would also like to add to the “don’t make a clientsided anti-exploit” discussion. In my opinion, one should feel free to do that if they want to, but don’t make it your main line of defense, but rather an extra layer which isn’t that significant. I’ve seen some very decent clientsided anti exploit, so it’s completly possible to make one if you know what you’re doing. But again, focus mainly on the server!
Most exploiters are script kiddies that don’t even know what they are doing, just copy/pasting code from a tutorial, but I agree - it’s totally possible for them to find the script and remove it. Basic users will look for something named like AntiExploitScript but for the most part client-sided exploits that are hidden well, updated often, with low focus, and the main focus on solid server script defense is enough to make your game secure.
Indeed most exploiters are script kiddies, but there is a fair amount of experienced ones. And all it takes is one experienced exploiter who makes a script for your game and releases it to script kiddies. That’s why you should never go by “noobs will never figure this out”
Luckily for me, in my scenario and I think many other ROBLOX devs who’s games are victims to cheats more often than not are not dealing with the most advanced exploiters. My client anti cheats which were hidden in the chat scripts way back when were a surprisingly easy counter to many of these less experienced exploiters. Only two exploiters I have seen have been able to correctly use getfenv(2) and it seemed they hooked it into Kick() locally to stop it. Out of the many cheaters I have seen the two that were able to bypass a client script without deleting it used my initial metatables against me (which I have since removed to prevent an exploiter passing false information) which was a pretty good win for me considering the two that did exploit it were only testing it for me since I do not own any exploits on a Mac to test my own systems against. Hidden local scripts provide a pretty large level of easy security against these simpleton exploiters many games are plagued with*.
*Not to be confused with nil scripts, as those make it very obvious, I believe personally, when those more experienced players come into your games as to whats going on behind the scenes.
Again, you’re assuming that you will be lucky enough to not stumble upon any advanced exploiter. It’s not what you should do. You should try to guess what an exploiter could possibly do and then prevent that. Obviously, you can’t prevent everything, but you can still detect some things and then kick the player.
Using a clientsided anti exploit gives you more ways of detecting a possible exploit, but keep in mind your checks could be spoofed, events disconnected, and so on. That’s another thing you can prevent (or at least detect).
But yea it’s pretty much a cat and mouse game, however with enough effort, you can make your clientsided checks take too long to figure out for them, so that they eventually give up.
OMG! Why are you having a script running on the client enforce this? You should instead detect when they are moving much faster than a normal humanoid could on the server side and set physics ownership of their character to the server for a while when something like that is detected. Won’t stop their inputs, but will sure annoy your exploiters as it will lag their character and their speed exploiting won’t register on the server side anymore.
Besides, that bit of code will bite only the first time a player’s character generates if it works at all. It won’t work after their first death unless it is part of a tool or GUI.
That is not how it works neither is that how it should be thought of. It’s that the change is blocked. Only the speed effects will be replicated but the property itself doesn’t change.
Yea just make sure to not pull a ripull and be proud of an anti cheat that uses :FireServer() when catches an exploiter, or ban all ur players because of an error in anti cheat
The ripull one actually made me laugh xd. But yea I took precautions and my anti exploit localscript tries to use other ways to communicate with the server first. If they fail, only then it falls back to using remotes. (It also checks if you’ve been disconnected after firing the remote and crashes you if you haven’t)
I pretty much killed any effective exploits on my game.
All you basically need are server checks. However, this is hard to do sometimes if there are things that the client heavily relies on but is not on the server. For example, the recoil of a weapon.
Exploiters can decrease recoil on the client side. A way you can prevent this is occasionally checking the client from the server.
The server will always have the correct recoil value. Periodically, the server will ask the client for their recoil value. If they don’t match up, kick them.
