local Aura = Character.Aura -- NumberValue, same concept as "mana" but different name
local Drain = instance.new("NumberValue")
Drain.Value = 10 -- Drains the Aura by 10 every second
Drain.Name = "Drain"
Drain.Parent = Folder
Module.DrainAura(Drain, Folder) -- Calls a function in a Module script
-- Function Represented below
local Module.DrainAura = (Drain, Aura)
task.spawn(function()
while Drain and Aura.Value > Drain.Value do
print("Loop!", Drain, Drain.Parent)
Aura.Value -= Drain
wait(1)
end
if Drain then
Drain:Destroy()
end
end)
end
This function works as intended, and prints out “Loop! Drain Folder”.
But when i delete Drain, it prints out “Loop! Drain Nil” and keeps the loop.
Clearly something changed, since the parent is Nil, but why is the instance itself not Nil???
-- I know i can do this to solve my problem. But i want to know why the 1st script doesn't work.
while Drain.Parent and Aura.Value > Drain.Value do
Aura.Value -= Drain
wait(1)
end```
when you :destroy something, it sets its parent to nil, but im pretty sure the thing itself doesn’t go away if you have a variable which stores it (like it keeps the thing, just with its parents as nil)
Does it affect performance? Like if the game builds up a bunch of items because they don’t go away?
I have variables for everything, including what i plan to destroy, is this bad practice or something?
It’ll only effect performance if you’re storing it in a table or keeping any strong references to it.
For example, if you have a bunch of Instances stored in a table and they’re all destroyed, the instances will still remain in the table, (assuming you don’t need them again) this will cause a memory leak. To fix this, you can either call table.clear to remove all the items in a table, or you can loop through the table and remove any items that are parented to nil.
for index, value in t do
if not value.Parent then -- check if the Instance is parented to something
t[index] = nil -- remove the element from the table
end
end
If you really want to make sure that you don’t have any performance problems with variables, just set the variable to nil
destroyed_instance_variable = nil -- setting the variable to nil will ensure that the instance will be garbage collected eventually
Debris calls Destroy on Instances after a certain amount of time. I use it often because if a thread is terminated while you’re using something like task.delay, the callback for task.delay will be canceled and never runs. Whereas, using Debris, even if the thread is terminated, the item will still be removed.
TL;DR Performance will only be effected if the destroyed instance still has any table or strong references. Otherwise, it’ll be garbage collected and removed from memory automatically
That is horrible news, i have variables for everything that i create, and everything that i eventually destroy, so should i change every script now?
For example, this function is used for a LOT of stuff
local Table = {["boolean"] = "BoolValue", ["number"] = "NumberValue", ["string"] = "StringValue"}
FoldersModule.AddInstance = function(Name, Value, Parent, Lifespan)
local Type = typeof(Value)
local NewValue = Instance.new(Table[Type]) -- If Type == "boolean" then create "BoolValue"
NewValue.Name = Name
NewValue.Value = Value
if Lifespan then
Debris:AddItem(NewValue, Lifespan)
end
NewValue.Parent = Parent
-- Should i set NewValue to nil?
NewValue = nil
-- Also does this rule only apply to variables with instances?
-- Or should i worry about other Variables? Example:
Type = nil
end
Sorry that i’m being dumb rn but i might have misunderstood what your first answer meant.
I assumed that just having a variable for an instance (like my example, NewValue) would affect performance if i didn’t set it to nil. If there’s nothing wrong with the example i gave, then that’s not true.
Could you clarify what this means? I got the table part, i’ll fix my scripts, but what does strong references mean?
Basically anything that will reference or call for the variable, but forget that part for now and just remember to always check table references since that’s easier to manage and will likely be the source of most memory leaks you encounter (at least in my scripting experience)