In my sandbox tycoon, when a dropper is placed and starts spawning ores, the untracked memory slowly climbs up and to very high numbers. I assume there is a memory leak somewhere in the dropper script based on this, however I don’t know how to fix it - if this is even the issue. Below is the script, and function that runs when a dropper is placed.
I don’t think it’s a good idea using the second (Parent) argument of Instance.new. Refer to the following:
Basically, I think it would be more efficient if you set the parent of the part at the very end (after you set the properties of the Instance). I believe this would lead to a reasonable boost in memory and performance.
Example:
local Part = Instance.new("Part")
Part.Name = "part"
Part.CFrame = CFrame.new()
...
Part.Parent = workspace
This helped slow down the rate that the data is increasing at, but it’s still going up a lot. I’m starting to think that what I posted isn’t the problem…
Are you sure you’re parenting them after setting all their properties/names/etc first?
Also, I don’t recommend an infinite loop to check if its avaliable, just use getpropertychanged/changed (fix this part):
I think i found the issue, the script that deletes the ores may be causing the problem, gimmie a moment to look into it more.
EDIT: Its probably the part where it removes ores, seems unnesscary as you can just set a Destroy with a corutine with a check/debris:addItem in the first script to remove it + the second script fires a remote event everytime it needs to destroy an ore.
AKA, Sending alot of remote events to just destroy/delete the ores that spawn with an infinite loop is not a good idea, just have it delete within the same script that it’s created in.
I’m pretty sure it would have to be an infinite loop though, because the ores are always dropping. Also, for the remote events, we use them because the client tweens ores and fires the remote event when the ore needs to removed, as movement is done locally we cant really tell when to remove it from the server without the remote
We tween the ores to prevent physics lag. The ores just follow nodes that get aligned when a player places a conveyor belt. The tweening isn’t the problem.
I’m not saying the tweening is the problem, I’m just seeing if theres a way to do the deletion without the use of remote events since (If im guessing) the more droppers = more ores = more remote events that are required to be called = memory usage/data usage going up in insane amounts
Well, that’s not exactly the case. It goes up very slowly, hence a memory leak. It’s not rapidly increasing as players place down droppers. It takes a few minutes. Plus, after AbiZinho’s post, the rate has decreased even more.
You should try to “isolate” the problem, have you made sure nobody is placing any droppers/ores then checked the memory + after placing the droppers/ores and checking the memory again?
If it continues to go up even without droppers, its something else thats causing the problem. If it goes up slowly after you’ve placed it then its something to do with the droppers/ores.
We have isolated the problem to the droppers and the ore removing function. Like I said earlier, It could also be something else that’s effecting it as well.
Then I believe the actual issue comes down to the script that removes ores, also, why are you setting the SetNetworkOwnship right before it gets destroyed?