I’m scripting Super Stela Games 2, which is a new game on ROBLOX but this time, I’m scripting to make sure it’s organized so that it’s easier to keep track of the game’s code and to make sure the script runs efficient to prevent no memory leaks.
When I script to play sound locally, I usually parent it under player GUI or the player object under game.Players. I haven’t tried parenting the sound to soundservice but I’m considering doing it to organize the game more and it might make the game run more efficient because soundservice is designed to store sound there.
What are the pros and cons of parenting a newly created script under soundservice or under player object under game.Players or player GUI to play a sound locally?
You can’t possibly create a memory leak on ROBLOX. You don’t have access to the heap. It’s all managed under the hood for you. You’re only dealing with the stack.
Also, the garbage collector will pickup any unused object with no references.
It doesn’t matter where you parent the sound. If you’re worried about sounds being parented all over the place, just add:
Memory leak could happen on ROBLOX. It’s unrelated to this topic but here’s one scenario that could happen. I can save that for a different topic but I’ll explain one example of it.
The local script is parented under screen GUI and the viewport frame is parented under screen GUI
A local script calls a remotefunction to retrieve a model stored in serverstorage. It looks like this
local modelRequest = game.ReplicatedStorage.getModel:InvokeServer()
Then a script on the server creates a local table and returns it that looks like this:
function game.ReplicatedStorage.getModel.OnServerInvoke(player)
local vpModel = game.ServerStorage.Model:Clone()
vpModel.Parent = game.ReplicatedStorage.Cache
local table = {
[“viewportModel”]=vpModel,
}
return table
end
Then back in the local script
local vpM = modelRequest[“viewportModel”]:Clone()
vpM.Parent = script.Parent.ViewportFrame
Let’s say that if a player kept on clicking a button to load a model in server storage to the player’s viewport frame, a memory leak could definitely happen.
This is one example but I can discuss with it more in a different topic.
No it won’t, because you’re still parenting the object to the ReplicatedStorage. It resides under a parent (still being referenced), it’s just not being used directly. It’s like having a pointer to an object but not accessing that pointer. It’s redundant.
That code just instantiates an object and places it under ReplicatedStorage. Then, the client clones their own copy on their machine.
Even if you didn’t parent the object in ReplicatedStorage, the variable would go out of scope as soon as the return is triggered. Meaning the server has no reference to that object anymore. The garbage collector will free the memory it used up.
You cannot create a memory leak on ROBLOX. I think you’re mistaking the difference between not using an object and a memory leak.
A memory leak is when you create objects on the heap, then remove all pointers and references to that object without freeing it from memory. The program will have no way to access the memory it originally allocated unless you access that exact memory address and overwrite it.
If an object loses all its references, the garbage collector will dispose of it. ROBLOX takes care of the heap under the hood. You can only create variables on the stack. Which is automatically handled by the garbage collector.
If ROBLOX was prone to memory leaks, it wouldn’t have the reputation it has today. It’s very embarrassing for a company to release software that causes memory leaks. Especially how ROBLOX is meant to teach kids how to code. If they would allow kids to manually handle memory, it would be a nightmare. You’d be able to crash a whole PC just by allocating memory manually on the client in a while loop.