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.
1 Like
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.
1 Like
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?
1 Like
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.
1 Like
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.
Not really, they can just use ScriptContext to determine how long can basescripts run without yielding and disable basescripts entirely by setting ScriptsDisabled to true then start disabling scripts one by one.
You would need one on the server and the client.
The server can access all players localscripts. This means you can get all players and check for their antiexploit, should it not have one or its disabled, then ban the player.
Under no circumstance should your anti-exploit be offline. The local script on the player can check the players inputs and speeds and fire the server if anything wrong. The server will ensure that all players have their anti-exploit and that they are sane.
They cannot disable server scripts. This means that if they tamper with their local anti, they get banned.
1 Like
You would need remote events to check if their anti exploits are enabled or not because property changes of a script (local or server, it does not matter) doesn’t replicate to server if it’s done on client (this also includes the Disabled property), and if you use remote events they can surely find a way to fake the responses by reading the code inside the anti exploit localscripts and running a code that can respond like an anti exploit would based on the code they decompiled from an anti exploit.
Unless you somehow manage to find a way to create a check that only the actual anti exploit localscript can respond to properly, your idea will not work.
Also no, server can not access all the localscripts. It can’t access the ones inside Player.PlayerScripts because those ones don’t replicate.