I had one but It was giving me issues and temporarily removed it.
How would you suggest doing this?
What I thought about would be using a clean up module like Maid and do Maid:GiveTask(Connection) and call DoCleaning Internally inside the event.
Maid’s good, but a little overkill for just two connections. I’d do something like this:
-- Here's a basic structure I thought of, as well
type CachedTag =
{
Tagged: { Instance };
RemovedConnection: RBXScriptConnection;
AddedConnection: RBXScriptConnection;
}
-- I won't be changing your own code much aside from just adding typechecking
-- and little things that I think you could do instead
function Cache:AddTag(Tag: string): ()
assert(typeof(Tag) == "string", "Tag must be of type string!")
-- You probably wouldn't want to make another table if one already exists...
if Parts[Tag] then
return
end
local Tagged: { Instance } = CollectionService:GetTagged(Tag)
-- I'm just separating this since it's a little long to connect it as well
local RemovedSignal: RBXScriptSignal = CollectionService:GetInstanceRemovedSignal(Tag)
local AddedSignal: RBXScriptSignal = CollectionService:GetInstanceAddedSignal(Tag)
Parts[Tag] = table.freeze{
Tagged = Tagged;
AddedConnection = AddedSignal:Connect(function(Part: Instance): ()
table.insert(Tagged, Part)
end);
RemovedConnection = RemovedSignal:Connect(function(Part: Instance): ()
local Index: number? = table.find(Tagged, Part)
if not Index then
return
end
table.remove(Tagged, Part)
end)
}
end
-- ...so, if you wanted to implement a RemoveTag():
function Cache:RemoveTag(Tag: string): ()
assert(typeof(Tag) == "string", "Tag must be of type string!")
local Cached: CachedTag? = Parts[Tag]
if not Cached then
return
end
-- Remove the tag from the Parts table
Parts[Tag] = nil
-- Then, clean up the connections
Cached.AddedConnection:Disconnect()
Cached.RemovedConnection:Disconnect()
end
1 Like
What If I do not plan on removing any tags, since the tags I will have will already be added during development.
1 Like
You could skip a lot of that whole table then, and your Parts table could just be Parts[Tag] = Tagged
I thought about killing the old connection and making a new one.
There’s not really a reason to do that, should you already be handling it. And, setting Tagged to CollectionService:GetTagged(Tag) would mean that it’s already caught up with all of the instances that have the given tag
2 Likes
A lot of memory leaks are run internally and are unavoidable
I suppose one method to a potential memory leak is having connections on non-existent references like if you did:
local part = Instance.new("Part")
part.AttributeChanged:Connect(function(args)
print(args)
end)
part:Destroy()
Pretty much what I mean is make sure you disconnect any connections or type of connections to a reference before disposing of it.
I am pretty tired so this is likely a really poor example but I hope you can get the message.
Other devs please dont ridicule just correct politely and move on if this angers you or is wrong. Lord knows the amount of times theres been unneeded drama over bad examples/miss informed examples.
This is incorrect.
Source: Instance | Documentation - Roblox Creator Hub
disconnects all connections, and calls Destroy() on all children
2 Likes
My topic was proven to be partially correct and incorrect. Back then you just had to destroy the character/player yourself because roblox didn’t do it for you, and i guess they never updated the documentation section on that. but recently they’ve added something called PlayerCharacterDestroyBehaviour which is set to on by default. So you shouldn’t need to worry about having to do anything.
However, people have complained that roblox’s system isn’t exactly working correctly. so it may be best to just manually do what I did.
I’m not an expert on memory leaks, I was just learning about performance at the time of writing that topic. I was literally just scrolling through the documentation’s section on optimization and found this
I’m pretty sure I only had like 4-8 months of scripting experience back then anyway when i wrote that topic so yeah maybe trust someone else 
2 Likes
Fixing memory leaks can go hand-in-hand with optimization and smart thinking. For example, say that you have a house model. Rather than using 2 parts for the wooden frame and 4 parts for the glass for the window, you could simply have 2 wooden frame parts and 1 part in the middle, then using a SpecialMesh you could slim it smaller than the wood, but then extend the size to fit the area it needs to. Rather than using 6 parts in that instance, you’d only be using 3.
Just think kinda smart on those things and it’ll go a long ways.
1 Like
I never heard about this, thank you for the suggestion!
1 Like
No prob. I actually picked that up from an oooold game called Welcome To The Town Of Robloxia hahaha. The houses utilized the technique I shared if you wanted to view it yourself. I just found out the original game was deleted while trying to find it to link it in this reply. 
1 Like