What they mean is memory leaks made by the game developers themselves, not Roblox. Something like the following code:
while true do
-- create a part
local part = Instance.new("Part")
-- wait a bit
task.wait(2) -- better than wait(), guaranteed to wait exactly that length of time
-- "destroy" it
part.Parent = nil --bad practice, the part still exists in memory. Use :Destroy() instead, which will actually remove it, or use Debris:AddItem() to remove it after a certain time
end
While this code isn’t good, it may now take longer to crash your server since there’s more RAM to fill.
interesting. Yeah, the only clarity I have right now with Untracked is that its just memory that can be used later. I think GC related memory leaks contribute to the number as well. I definitely agree there should be more transparency on not only Untracked, but the other categories as well
So there are specific signals that allow for more memory. Is this estimation based on the amount of complex calculations an experience does and decreased if it doesn’t need a huge amount of ressources?
But in general, great that more memory is offered.
We have no current plans to penalize or reward experiences based on their server memory use. Client cash rate is one factor in the ranking algorithm, though.
Thank you for the feedback. Are you referring to a client or server categorization? We’re working towards providing a better breakdown of what server-side systems are using what resources within Creator Analytics.
Yeah, I think they might tell us what sort of signals and criteria they are looking for once the experiments are over.
If I were to guess, I’d say the following might be considered:
Max player count
Starting/runtime total memory value
Content Streaming settings (from what I’ve seen, bigger maps that have this enabled have generally higher network-related memory values like raknet, replicator, etc.)
Amount of RBXScriptSignal and RBXScriptConnections
No idea if I’m even in the right ballpark but those seem to be reasonable I think.
Assuming the experiments are a success, we will share the memory formula here on the devforums and update the docs appropriately (likely in our performance docs, which we have been actively working on improving). Thanks for the reminder!
I know guys stated you would provide more clarity once the experiments are over. However, are you able to tell us the maximum allocation that any given experience can receive? This could be great for development planning if we knew the absolute ceiling/maximum.
My team has been pushing against this limit for a while, so we really appreciate the change!
However, it’s important to note that part of the reason we have issues with this is due to the lack of visibility into the root causes and possible solutions for untracked memory.
I agree with devSparkle, would it be possible for us to have a visual display for RAM use? Something similar to Task Manager’s display for RAM (particularly the categorized bar) would be extremely easy to read visually and interpret how much RAM is being used in each category.
The bar is segmented into distinct sections, and each section can be a category. The whole bar is the total memory of the place, set to either client or server (like how logs currently do).
Seconding this. “Untracked Memory” is simply way too encompassing. It could be practically anything really. Better tools to dig into the memory to find out the issues would be nice.
Thank you - this is an amazing change that will allow us to improve and expand our map and allow higher player counts without worrying about server crashes!
