How to make a LocalScript re-enable itself when its Disabled property changes

Help and Feedback Scripting Support
,
#1

I’ve been making an anti-exploit, I tried to make it a server-side anti-exploit but I learned the hard way that it only works if it’s client-sided, via LocalScripts. What I want to achieve is, more like a question and asking for help.

Is there any way to stop a LocalScript from being disabled from a client-side, by the client? For example, an exploiter disables an anti-exploit LocalScript with an injected script, is there a way to make it so the script re-enables itself?

I knew trying “script.Changed:Connect()” wouldn’t work, but I still tried it, but it was no use as expected.

#2

A “while true do” loop will always be active as long as the script is enabled. You could try using that.
Alternatively, you could try using “script:GetPropertyChangedSignal()”, though I’ve never tried using it like that before.
Just so you know, if a script has already been disabled, then it can’t enable itself again, another script has to enable it.

#3

I’ve tried using GetPropertyChangedSignal() as well, same result as using “Changed:Connect()”.

I’m not entirely sure if a “while true do” would make it so the LocalScript re-enables itself when a client disables it.

#4

As I said, it’s not possible for a disabled script to directly re-enable itself, as it’s disabled meaning no code can run.
However you could try having another script running a “while true do” loop, checking if it’s Disabled, and if it is, then it could re-enable it.

#5

You won’t be able to tell if the script is disabled from the server, as any changes the client makes won’t replicate to the server. I don’t think there is an easy/good way to do this because pretty much anything you do can be disabled by the client.

#6

Yeah I was considering this as well. I was also wondering if there was a way to make it so it’s not possible to disable a specific LocalScript in the first place. Or maybe even an event similar to “Changed” but that fires immediately before the property is changed, just how “DescendantRemoving” works.

#7

With my limited knowledge, I can’t think of any way, but you could try to have two local scripts checking if the other one is disabled constantly, and kick the player if either of them detects the other script is disabled.

#8

Wait, that’s actually a good idea. I remember trying something similar and it turned out working, just not as wanted previously, but I’ll try changing it up a bit and try it again, and I’ll let you know if it works.

1 Like
#9

While true do is very uneffcient don’t use that. It would lag your game.

#10

What do you think about coroutine? It would check if it is disabled or not.

#11

As long as you include a wait (even wait() could work), and you aren’t doing anything performance-intensive, you should be ok.
Alternatively you could use RunService.Stepped:Connect or Heartbeat.

#12

How is a coroutine done? I’ve never really tried such thing before.

#13

I tried RunService.Stepped and RunService.Heartbeat too, they did not work sadly.

#14

@jsnotlout1 Sadly it ended up not working, which is quite disappointing, I’ll be looking for more solutions.

1 Like
#15

You basically use it like a function.
coroutine.wrap(function()

end)

Coroutines allow multiple things to run at the same time basically.

#16

I’d recommend doing what :GetPropertyChangedSignal inside of the most important local script in the game, so that if the exploiters do try to disable it, it will get reenabled and at the same time, if they disable that script, the game won’t work properly.

#17

I tried this and unfortunately it did not work, basically it did not re-enable itself.

#18

This method didn’t work either unfortunately.

#19

As I said, do it inside of a different more important or just very important local script.

#20

Oh, apologies, I missed that part of the message. Although it’d be a great feature if ROBLOX were to implement a system where specific scripts up to the developer’s choice, are not able to be disabled.