You’ll also have to clone the children of the Contains folder. GetChildren() will get the children of the object you’ve given it and not the children’s children.
This is not true, get children doesn’t normally behave like this.
Proof:
local Part = Instance.new("Part")
Part.Parent = game.Workspace
Part.Name = 'HI'
for i,v in pairs(game.Workspace.Part:GetChildren()) do
v:Clone().Parent = Part
end
Mhm, maybe parent the value that is parented to the folder to the part and when all of the children has loaded then parent the value back to the folder.
This is probably something with the engine itself. Just did a little experiment and:
local parts = workspace.Part:GetChildren()
for i,v in pairs(parts) do
v:Clone().Parent = workspace.Hello -- before origin deletion
end
workspace.Part:Destroy()
for i,v in pairs(parts) do
v:Clone().Parent = workspace.Hey -- after origin deletion
end
Hello is the clone created before it’s origin was deleted.
Hey is the clone created after it’s origin was deleted.
When you call workspace.Part:Destroy() you end up clearing workspace.Part children (Destroy gets called for all the children and so on) which means that if you do :Clone() now for any of the previous children, they wont have any children/descendants.
i’m pretty sure this definitely is intended, because when you destroy a part, everything including itself and inside that part gets destroyed (parent property gets set to nil and gets locked etc.) and then eventually garbage collected. However when you still have a reference to a destroyed part, it doesn’t get garbage collected, still persists, so you can still use it but it no longer has any references to any other instances. So what i mean is because you are only getting the Children of the part, you only have reference to those specific children. When you are destroying that part, all of that parts’ children parent references are destroyed, So when you go to clone the “destroyed” part it appears as if the part does not have any children. (if that makes sense)