This method is something games such as Phantom Forces or Trident Surival uses to keep their game secure.
This method has never been mentioned on the Roblox DevForums AFAIK so i decided to make a post about it.
Actors are a great way to keep your game’s performance good, but it’s also good for keeping your game secure and prevent exploiter’s.
Let me explain: Creating an actor in your game will basically create a new space in your game, now just imagine you’re making a shooter, exploiter’s will hook Raycasting (Most times) to make features such as Silent Aim.
But by putting your LocalScript in an actor that will also run the script on a different space, what does that mean? the exploiter can’t hook anything, can’t getgc or manipulate anything to the LocalScript since the script is being in a way different space.
There were 2 Methods exploiter’s were able bypass this.
Back then Synapse X released a function to prevent that called run_on_actor that will run the script on the actor’s space, This was the first method, but since Synapse X discontinued you shouldn’t worry about that.
The other method was the auto execute actor bypass method. This method worked by reparenting the LocalScripts parent to something that’s not an actor.
So how are you able to do this?
Go to your StarterPlayerScripts or StarterCharacterScripts and create a new actor, now put your LocalScript into that actor. and that should be all.
This post is for my friend since he can’t, so i decided to help him.
This isn’t true at all. Just because something is in an actor does not mean it is exploit proof. The player can do whatever they wish to their client. You can only take preventative measures; you can not stop exploiting.
Actors doesn’t create a “new space”, either. Code just runs on the different core and variables are still stored in the same RAM every other CPU core uses.
i highly doubt that the script injection engines aren’t advanced enough to not be able to get actors and all that stuff from these scripts. Unless there’s some proof that it actually helps, I simply don’t believe it.
This will not prevent exploiters, it may prevent skids (bad exploiters) from tampering with easy-access variables. If they try hard enough, they will still be able to change things. And this definitely won’t prevent flying scripts, teleporting, ESP, macros, etc.
Alternatively, they can just fire remotes. Remotes must be under the game to function properly. If you reparent it under the game, fire it, then parent it to nil, the exploiter will detect this and get the remote.
