ModuleScripts continue to run after having the Destroy() method called on them

[ZhaoDan]

Simply put, when you Destroy a script, it halts it from running, when you Destroy a ModuleScript, it stays alive and is just nil parented, Repro:

[Seranok]

The reason that a script and all its spawned threads stop running when you call :Destroy() on it is because the script is parented to a place where scripts can’t run (in this case, nil). Module scripts have no such restriction: you can require a ModuleScript regardless of its parent.

[ZhaoDan]

The reason that a script and all its spawned threads stop running when you call :Destroy() on it is because the script is parented to a place where scripts can’t run (in this case, nil). Module scripts have no such restriction: you can require a ModuleScript regardless of its parent.

Can you change this behavior? I need a way to make ModuleScripts to stop running, and it was unexpected for it to continue running from Destroy() which was made to make scripts stop running. Perhaps make .Parent = nil keep it alive (for the sake of if anyone needed Modules to still run and be nil parented), but Destroy() kill it (for the sake of completeness to Destroy)?

[TheGamer101]

The reason that a script and all its spawned threads stop running when you call :Destroy() on it is because the script is parented to a place where scripts can’t run (in this case, nil). Module scripts have no such restriction: you can require a ModuleScript regardless of its parent.

Can you change this behavior? I need a way to make ModuleScripts to stop running, and it was unexpected for it to continue running from Destroy() which was made to make scripts stop running. Perhaps make .Parent = nil keep it alive (for the sake of if anyone needed Modules to still run and be nil parented), but Destroy() kill it (for the sake of completeness to Destroy)?[/quote]

Why not have your module return a function that you can use to disconnect all the connections it is listening to?

[ZhaoDan]

[quote=“Seranok” post=197111]The reason that a script and all its spawned threads stop running when you call :Destroy() on it is because the script is parented to a place where scripts can’t run (in this case, nil). Module scripts have no such restriction: you can require a ModuleScript regardless of its parent.

Can you change this behavior? I need a way to make ModuleScripts to stop running, and it was unexpected for it to continue running from Destroy() which was made to make scripts stop running. Perhaps make .Parent = nil keep it alive (for the sake of if anyone needed Modules to still run and be nil parented), but Destroy() kill it (for the sake of completeness to Destroy)?[/quote]

Why not have your module return a function that you can use to disconnect all the connections it is listening to?[/quote]

Long explanation, but, I’m making a custom respawn system now, and it would be inconvenient to disconnect every single module my game uses, with every singe loop and connection they run, overall they are currently really complex scripts, also, if I did go through the work to do such, it would make my modules less readable, and I would need to make sure I did the same with all future modules.

Currently the client has something like 4k lines of code, It would be a pain going through all that code and making it all disconnect just for a respawn system, that I was making custom because it lets me gain 4 seconds of load time, and no extra physics data or minor graphical issues.

Also, it’s expected behavior that Destroy stops scripts, Modules should not be an exception to this rule.

[Programmix]

The thing is that after you call require() on a ModuleScript, they return… whatever (a table of stuff, a function, etc.) Therefore, the ModuleScript isn’t actually what’s running. It’s all running on the script that required the module. The ModuleScript, more than a script, is a container for code and variables.

[ZhaoDan]

The thing is that after you call require() on a ModuleScript, they return… whatever (a table of stuff, a function, etc.) Therefore, the ModuleScript isn’t actually what’s running. It’s all running on the script that required the module. The ModuleScript, more than a script, is a container for code and variables.

Keep the table alive, as destroying the pointer to that data would cause some unexpected problems, but destroy and halt the script itself, because a Module is also a script. I don’t see why :Destroy() shouldn’t halt what the Module script itself is running (leave the requiring scripts to do their thing with the information they got from it)

[Tomarty]

[quote=“Weeve” post=197113][quote=“Seranok” post=197111]The reason that a script and all its spawned threads stop running when you call :Destroy() on it is because the script is parented to a place where scripts can’t run (in this case, nil). Module scripts have no such restriction: you can require a ModuleScript regardless of its parent.

Can you change this behavior? I need a way to make ModuleScripts to stop running, and it was unexpected for it to continue running from Destroy() which was made to make scripts stop running. Perhaps make .Parent = nil keep it alive (for the sake of if anyone needed Modules to still run and be nil parented), but Destroy() kill it (for the sake of completeness to Destroy)?[/quote]

Why not have your module return a function that you can use to disconnect all the connections it is listening to?[/quote]

Long explanation, but, I’m making a custom respawn system now, and it would be inconvenient to disconnect every single module my game uses, with every singe loop and connection they run, overall they are currently really complex scripts, also, if I did go through the work to do such, it would make my modules less readable, and I would need to make sure I did the same with all future modules.

Currently the client has something like 4k lines of code, It would be a pain going through all that code and making it all disconnect just for a respawn system, that I was making custom because it lets me gain 4 seconds of load time, and no extra physics data or minor graphical issues.

Also, it’s expected behavior that Destroy stops scripts, Modules should not be an exception to this rule.[/quote]

Perhaps you don’t need a respawn system, just teleport the character and reuse everything that’s already running?

I would recommend making initializable objects that can be disposed or reused.

I usually set up my modules like this when I need to disconnect stuff:

local Class = {}

local Methods = {}
local Metatable = {__index = Methods}

function Methods:Dispose()
	-- Disconnect stuff
end



function Class.new()
	
	local self = {}
	
	
	setmetatable(self, Metatable)
	
	return self
	
end


return Class

[ZhaoDan]

Reusing is not an option, The usual reason people want to respawn is if a script breaks, or something goes wrong, it’s my solution to there still being bugs in my game since it’s beta, yet there are enough players that I can’t just look at them and say ‘beta’ if the game breaks, so I have a quick respawn feature I added.

And I’m not really looking for things that ‘could’ work, as I already know I have those options, but they are far too much work, and they aren’t at all expandable, and they would make my code look messy. I’m asking for Destroy() to actually Destroy ModuleScripts, instead of just removing them.

While Destroy is being fixed, I will likely revert back to the original respawn system, or not allow respawns at all. I either want to do it the right way, or not at all, throwing ugly 'if ScriptRunning then’s in every loop, and storing all connections in a table does not sound appealing to me, my workflow, or my valuable dev time.

[Tomarty]

At one point I was trying to make a script that updated the game without using TeleportService. I think your suggestion would make that a lot easier
What bothered me was that I could be updating the game to fix something that was broken, and I can’t expect a broken thing to properly dispose. Well, unless I were to wrap the entire roblox API and keep track of all connections, which is a little crazy.