Server-side only checks are the way to go. Implementing client checks is simply delaying the inevitable. As I said above, think of your client code like an exploiter can both read and edit it. This is pretty much exactly what exploits do, they simply do it in an indirect way by changing little pieces of functionality.
An exploiter could do any of the following to bypass your check in a minimal amount of code (10ish lines) with any modern exploit:
Make IsA return false for their BodyMovers/BodyGyros
Override the :Kick function & the :FireServer function
Disconnect your ChildAdded connection
Change the event returned by .ChildAdded to a custom one
Use a function you call (e.g. IsA, FireServer, wait, or Kick) and produce an error or permanently yield
.Disable the script (and yes, they can hide this easily)
@Sudden_Demise Did you not see our previous replies? I specifically mentioned that @PixelIGPM8 could have both client and server side anti exploit measures. I agree with @Hexcedeâs reply above.
If you read earlier, server-side checks are not able to check BodyMovers/BodyGyros, while client-side checks are. The thing is, client side checks, and checking for BodyMovers/BodyGyros is very likely not a sure-fire to prevent expoiters from flying. Reasons? I think @Hexcede covered that well enough.
Hereâs, once again, my reply from earlier on what direction I believe @PixelIGPM8 should take:
One of the problems I could see happening with the above, is that someone could mess with the RemoteEvent(s) sent between the localscript and script and potentially error/jam the script if they send it a certain way, and the script isnât prepared for those situations. So the safest way may be to just have server side checks, as it does most of the âheavy-liftingâ anyways, and is more reliable and secure in comparison to client side checks anyways,
However, as I explained above, physics will replicate to the server. This is why the exploit even works at all, if something is happening for other players it has to be replicating something. Tuning your physics anticheat to your game is extremely important for this, for example, vehicles and such will have their own physics, which I go over in my article a little.
The instances themselves will not replicate, however, introducing client checks is almost never ever worth it. Technically, yes, its true that you canât stop all exploits from the server easily however physics is by far the hardest but also isnât particularly much difficulty. The problem is, that even if you check on the client, it can be bypassed far more easily than it was for you to create it, the amount of people it will stop depends on its complexity, and, even then, it will only stop the people with more basic understanding of the exploit they are using.
I donât know what you are reffering to âFPSâ with (unless you mean FPS unlocker which is actually permitted by Roblox), but, I go over specifically WalkSpeed and JumpPower in my article and explain how you might implement a decent fly check, and there is discussion on noclip and such in replies.
WalkSpeed and JumpPower are both by far the easiest physics exploits to mitigate from the server.
I know that client code is not reliable however OP was referring to making a client-based anti-exploit. I know all about client code and it being able to be read/modified by exploiters, I also did recommend using server-checks.