Script.Disabled = true BUT it's still running?!

Help and Feedback Scripting Support
#22

If another script outside of the current script called:

[script].Disabled = false

As then the script can create threads again.

And you are right, they cannot infinitely loop - but they can keep calling each other. Its just the fun of threading.

#23

If it really comes down to this, you can have a script clone a disabled script. Then have that script remove itself.

Script 1

local NewScript = script.Parent.OtherScript:Clone()
NewScript.Disabled = false

Script 2 (This is the “OtherScript”)

while true do
    Print("TEST")
    script:Destroy()
end
#24

But why would anyone want that?

  • It would just create more lag as its another instance of the script (which isn’t actually needed).

You could just disable the script in studio in the first place if you don’t want it to run straight away. And then enable the script whenever you need it.

Can I highlight to everyone whos reading this, that by disabling the script you are disabling its ability to create more of itself / run itself.

1 Like
#25

That clears up a lot, I didn’t know that! Thanks for explaining.

#26

So that would probably mean that you would want to use a different method of stoping the loop. Maybe use Break to stop the loop, or change the while wait() do
Example

print("Start")
while wait() do
    print("Working")
    break
end

Another Example using a variable

local ScriptWorking = true
print("Start")
while ScriptWorking == true do
    print("Working")
    ScriptWorking = false
    wait()
end
#27

Thats exactly what you would do :slight_smile:

You just break the code when you want it to stop at a certain point, you disable the script if you do not want it to run at all.

1 Like
#28

I just did some testing, and it looks like setting Disabled from the same script does nothing, however doing that from an other script successfully stops it.

What bothers me is the facts that all connections are “paused” once a script is disabled. This didn’t use to be a thing, as I remember doing script.Changed:Connect(print) and then disabling it used to print "Disabled" (and other events such as RenderStepped worked aswell).

That means the behavior of Disabled was definetly changed :thinking:

2 Likes
#29

As stated above, it disables the script but the current thread keeps running.

#31

Yea, but apparently that’s not the case when you disable the script from a different script.

2 Likes
#32

That is because the other script can stop anymore threads being created, whereas doing it internally means it stops every other thread except itself.

Until the thread has got to the end of the script, it will keep running. The other script cannot however disable any current threads which are active.

1 Like
#33

I’m not sure what you mean. What I’m saying is the script can only be stopped with Disabled if it’s set from another script
Consider the following code:

_G.me = script
while wait() do
    print(math.random())
end

Now, doing _G.me.Disabled = true from another script is going to stop the output spam.

However, doing this

while wait() do
    print(math.random())
    script.Disabled = true
end

will not stop the loop.

2 Likes
#34

What I said previously was wrong, the outer thread can stop scripts and the current thread running.

When it is done inside the script, it doesn’t change the current threads properties - that is because it is a thread, an instance of the script. It doesn’t understand that it can be ‘disabled’. If it is done outside the script then the script can affect the current running thread (instance) of the script, as such it can disable it.

Threading is quite hard to explain, so apologies if any of this causes blanks. The point is however, that whereas the thread cannot change itself - outer scripts can.

#35

Let’s take a step back here and address the why. What prompted this thread to be made? Are you testing out properties in Studio or do you have a specific use case in mind where this is applicable?

1 Like
#36

A thread of a script is made when any script is ran, this is a general issue meaning that it cannot be generalised into a single script causing this ‘issue’. Every script is bound by this ‘issue’ of disabling.

I’ve put ‘ around issue because it’s not really an issue, it’s just people not understanding.

I don’t want this to sound rude, but can we stop making this chat thread more complicated :sweat_smile: as we are over complicating a simple issue - expanding an issue is fine if you don’t understand or need something explained.

#37

So you are saying the problem is solved if I Disable it from another script?

Any other script even a module?

Edit;
(This is not possible, if the script disabling itself requires the module)

Although Disabling a script with another script will deactivate the script immediately.

1 Like
#38

This has happened to me as well… Can’t remember the specific case though.

#39

By thread, I wasn’t referring to a script. I was talking about this DevForum thread. I think you misconstrued the meaning of my response.

I don’t care to make this more complicated. I’m asking about the root issue as to why the Disabled property needs to be used in the first place.

Please read my post again.

#40

The script will not be disabled until the script finishes running, for example, never ending loop will never end even if script is disabled.

script.Disabled = true

while wait() do
print('a')
end

do this then

local disabled = script.Disabled

script.Changed:Connect(function(prop)
	if (prop == "Disabled") then
		disabled = script.Disabled
	end
end)

while wait() do
	if (disabled) then
		break
	end
	print("1")
end
#41

Work-arounds such as the one you mentioned in your post shouldn’t be relied on (not targeting what you posted specifically, however the concept of it), in general they’re messy and realistically there isn’t a point in having to implement them since there shouldn’t be an instance where disabling a script after run-time is the best solution as mentioned by @colbert2677.

Irregardless, according to the developer.roblox.com documentation, all threads should be terminated, however this doesn’t accurately reflect the current behaviour where the current running thread will continue until it finishes. The documentation should be updated accordingly to reflect this or the behaviour should be changed to reflect the documentation.

5 Likes
#42

Apologies, I have been talking about Threading in this thread so if you can’t tell it’s getting VERY CONFUSING at this point.

The main question was basically answered / investigated, now it is just people asking addition questions.