Do you have zombies in your code?
Posted on February 17, 2014 by MrNicNac
Disregarding how cool it would be to have actual zombies running through your code and stomping on your errors - we don't actually mean the typical zombie you're thinking of.
We're using zombie to refer data left over from incorrectly removing something from your game. This could happen from ways like setting the parent of something to nil, or using that rusty, old remove function.
-- bad ways Workspace.Part.Parent = nil Workspace.Parent:Remove()
Let's be quick about it. What is the best way to make sure something is not lingering in the graveyard of data that you can't really see in the Workspace - or anywhere else in your game? Using the :Destroy() method.
Workspace.Part:Destroy()
Why is that? First off, simply setting the Parent property to nil will not remove the rest of the data that the part has allocated. This is why you can re-parent the part back to an existing object (like the Workspace) and it will still have all its original properties. The same goes for :Remove(). However, remove will go through all the children and descendants - setting all of their Parent properties to nil.
Notice how, again, it doesn't set all other properties to nil - and the parts are never collected via the garbage collection in Lua. This means they still exist someone as zombie parts waiting to come up and eventually lag your games.
However, there are currently scripts out there that use the :Remove() method and expect the zombie parts. They use these to their advantage. The most common sort of script that does this is a tycoon buy-button. However, this is also the reason for buy-buttons sometimes not working. Occasionally, the garbage collector will become throttled and collect the nil-parented parts used by buy-buttons. Use a different method in this case.
Just remember to always use :Destroy() when removing ROBLOX objects. We usually don't want things to rise from the dead and make everything explode.
Commentary
Leave a Comment