ObiectValue doesn’t seem to automatically unassign removed objects, Is this some kind of memory leak?
1 Like
Same thing happened to me. It didn’t clear our the object
This type of problem get’s into my nerves, This is the only roadblock keeping me from continuing my projects haha
That’s intended behavior, an ObjectValue instance holds a reference to an instance even if the instance has been destroyed/parented to nil. You can circumvent this by setting the ObjectValue’s value to nil.
local objectValue = workspace.ObjectValue
local instance = workspace.Part
objectValue.Value = instance
instance.AncestryChanged:Connect(function(_, parent)
if not parent then --Instance is being destroyed.
objectValue.Value = nil
end
end)
2 Likes
Still, Why is it still referencing destroyed object/instance, Objects that are destroyed are rarely even used
A stupid and lazy design. roblox should change this to a weak reference
necro bump moment
personally i’d rather have object values keep their references and not have to spend an hour trying to figure out why it suddenly vanishes randomly.
if you destroy an object, it’s common practice to remove everything related to it, object values shouldnt be an exception.
The core issue lies precisely here. The role of the destroy function is very limited, resulting in a large amount of redundant code to prevent memory leaks caused by references, which should have been handled automatically in a modern game engine
How would the engine be absolutely sure you won’t use the ObjectValue again?
Use cases are rare, but not non-existent, and making it a weak reference would also break the norm as references to Instances are typically strong.
In 99.9% of cases, developers no longer need an instance after it is destroyed. However, roblox does not. Instead, it continues to use the outdated and rigid strategy of lua. You have to manually clean up all related references to prevent it from occupying memory and wasting resources. This merely causes trouble for both new and experienced developers or leads to writing a large amount of repetitive, redundant code that has nothing to do with gameplay at all
99.9% is an overexaggerated amount, and even if it wasn’t there’s still that 0.1%.
0.1% of a large number is still a large number!
Have you never indexed a property of a destroyed instance before?
Additionally, you the developer aren’t doing the actual garbage collection, dereferencing an object just marks it to be garbage collected later on.
If you’re referencing an object, you expect it to always be there until you stop referencing the object, changing this would cause a whole lot more issues that would confuse developers even more.