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:
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)?
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?
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.
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)
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
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.
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.