So in my game there are a lot of moving parts that move with local scripts, not with server-sided scripts because they lagged a lot. So I wanted to know:
Are exploiters literally just able to disable the scripts?
Is it a good idea to keep these things client-sided?
Yes. The exploiters could disable the scripts. They can just delete them. However, it will only effect them. Other people will not get the scripts deleted. The parts will only stop for the exploiter, but still will be moving for everyone else.
localscripts can be manipulated in many ways by exploiters.they can be completely removed or disabled or if you have global variables and values in it. it can be changed. but it won’t be replicated to the server so it can only be used by the Client itself.
In conclusion: they can disable these LocalScripts and make their games so much easier and there’s nothing I can do about it?
Inn conclusion: they can disable these LocalScripts and make their games so much easier and there’s nothing I can do about it?
If an exploiter deletes a local script, it will only delete for them…
Pretty much yes. Thats why you do these things on the server to prevent exploiters from making the game easier for themselves (in some cases).
I’ve seen a simple counter to this, that would require an exploiter to have knowledge of how your scripts work to stop it.
You can create two scripts that watch each other with a .Changed listener. If anything changes on the script, you can fix it. If the script is disabled, you immediately re-enable it. If it’s deleted, you replace it.
There is a way to break this, but that would require them to understand that you need to break the listener, which reduces the amount of exploiters who will be able to do that, as it’s more complex than a simple script kiddie can comprehend.
actually you can, make a serverscript and use remotes to execute it on client.
that will give you the right to add whatever type of checks you want to that client script. so pretty much patching most of the major problems.
You can’t assume that even skids won’t be able to bypass your stuff. If your game is big enough there is likely going to be scripts made specifically for it. They could edit the globals of your script to make it error, or mess with the constants, literally there are many ways to do it. They probably don’t even need to use the Disabled property at all.
Why would you ever use globals?
No suggestion is perfect, but two scripts watching each other is a much safer method than nothing at all.
You don’t understand, they could edit game to be nil or something, or empty out table so that occurrences of table.insert etc don’t work, there are many ways.
2 scripts watching each other is pointless, because exploiters don’t need to disable scripts.
They can just deactivate both scripts as well lol
That’s irrelevant to the discussion. The whole point is trying to prevent easier methods to make exploiters work harder to break your scripts.
If you stop the easier exploits, many exploiters will just give up, especially the script kiddies who don’t know what they’re doing. Obviously there will always be loop holes, but you can catch those with scriptcontextservice and check for errors.
For instance, if they set game or table = to nil and their script throws a weird error, you just catch that in a scriptcontextservice error listener and kick them.
They also cannot deactivate both scripts, I’ve done this method and tested it with Synapse myself. In the time that it takes to deactivate one script, the other script will have already reactivated its partner script. The only way to break it is to write an infinite loop of listener events to break the actual listener.
which will account for anti-exploits 
It won’t lol, the stack trace will come from your script not the exploiter’s script.
then you did it wrong
You know that exploiters can just disconnect event listeners right?
I really don’t think you know what you’re talking about then.
Using scriptcontextservice, I can see every single error that’s thrown on the client. Here’s an example of me logging it. In this image you can see I literally have the randomized script name that comes from synapse, the error message that was generated and the user. The code that I ran was just error(“test”) obviously.
If you’d like to replicate this, you can look at the documentation about ScriptContext.Error. I also like to use LogService.MessageOut to look for script injected print statements.
These are some common anti-exploit methods that I’ve used and are pretty common to check for script injection.
How is this relevant to this though.
The game script would error, since that one was edited, not the exploiter’s script. The exploiter’s script didn’t error
Okay you clearly don’t understand. If any script errors, it’s clear someone tampered with it. If you’re writing good code, your code shouldn’t just randomly error.
anything that runs locally can be effected by exploiters. They can disable them, read them and any information being passed on between remotes.
They can disable the scripts. However you can create a anti exploit to make sure your scripts are still running.
Not really. Filtering enabled prevents client side things from replicating to the server so what the exploiter would do will be client sided. If a exploiter deletes a local script, it will not replicate to the server.