I have a “DebuffModule” that applies burning/bleeding/poison/etc. to the target character, making them take damage over time.
When a script applies an effect using the module but gets deleted before the effect finishes, the effect ends prematurely which is not what I want:
I have searched on the forum for similar problems, but the 2 forum posts I have found didn’t give a solution. I know I’m not too amazing at searching though, so a redirect to another post discussing this topic (if there is one) would be appreciated too!
Here’s the basic script:
local ticks = Duration*ticksPerSecond
local tickDuration = 1/ticksPerSecond
local damagePerTick = TotalDamage/Duration/ticksPerSecond
task.spawn(function()
for i=1,ticks do
hum:TakeDamage(damagePerTick)
task.wait(tickDuration)
end
end
You could hold a Boolean in the module, set it to true while an effect is running, and make the script attempting to destroy it wait until it is set to false.
The problem is, the script would get destroyed because it’s parent would be destroyed too, do you suggest I should store the script somewhere “safe” until the effect finishes?
That is what I was going to suggest, place the script in a temporary location (such as ServerScriptService.TEMP) and only destroy it when the loop is done.
This does make me wonder if your system is set up incorrectly, as this shouldn’t really be an issue, especially if working with ModuleScripts.
I don’t recommend using temporary scripts. You could instead add tags to the tools and use CollectionService:GetInstanceAdded(tag) to call a tool handler function for the new copy when a tool instance is cloned, or you could just call the handler function in the code that creates the clone. You could even create your own Luau class for the tool and the constructor of the class would create the new tool instance clone.
While temporary scripts may be easier in many scenarios for various reasons, one of which is that the connections created in the script are automatically disconnected when the script is destroyed, I still prefer permanent scripts because they are less restrictive. Just remember to clean up connections and other possible memory leak sources when using permanent scripts.
Temporary scripts can result in many edge cases. While in your case, the temporary scripts has led to and effect stopping prematurely, a temporary script could also cause an effect that should be temporary to be permanent which may be an even more serious problem. For example, if a wand is used to freeze a character by anchoring it and unanchor it after a spesific time, if the wand gets destroyed too early, the character will remain anchored.
I appreciate the help! Sorry if I was a little slow to reply, this was my first topic. I don’t think I considered too well if the debuff manager should’ve been a module script or a regular script and I believe I might have to change it to a server script. Using a module scripts seems to make the effects harder to manage.
I’m not saying that you shouldn’t use modules. I have almost all of my code in ModuleScripts unless it’s just some simple testing code. I’m just saying that the scripts requiring those modules should be permanent.
I want to use a module in this case, but the times I apply these effects it’s probably either from a tool or player action, and since players can die and destroy the tools and scripts inside them before the effect ends, I can’t make them permanent, I don’t think
What I was saying was that I don’t recommend putting Scripts, LocalScripts or ModuleScripts inside tools at all. For server side tool code, you can have a permanent script or a permanent ModuleScript required by a permanent script in ServerScriptService. This script or module would handle every tool of the same kind in the game. ModuleScripts used by the client (or ones used by both server and client) can be put in ReplicatedStorage. You can also have a client-side script in ReplicatedStorage by Creating a script in ReplicatedStorage and setting its RunContext to Client. Alternatively, you can just have a LocalScript (or script with RunContext Client) in StarterPlayerScripts.