Weird getchildren() behaviour?

Ok so basically in part of my game I make a duplicate of a part and destroy the original, current script flow

Get table of children
Make new part
Destroy original part
Iterate through table of children cloning into new part.

However, im seeing some strange behaviour:

Original Part:
Screen Shot 2020-06-16 at 15.51.40

New Part:
Screen Shot 2020-06-16 at 15.52.03

This doesn’t feel intentional, any way to prevent this?

I am pretty sure you only got the descendants of the part and not the folder, that is why the vegetable oil has not loaded.

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

Screen Shot 2020-06-16 at 15.58.53

@TariqSpeeltRoblox applies to your response too.

1 Like

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 a lot of excess code and seems a lot more complicated and unnecessary then it needs to be :frowning:

Really just looking for a quick workaround / reasoning behind this behaviour.

Yeah I know right, but it might work that way instead. :man_shrugging:

1 Like

Weird, i just tried it on an empty baseplate and it cloned the parts just fine.

for i,v in pairs(workspace.Part:GetChildren()) do
	v:Clone().Parent = workspace.Hey
end

image

He was doing it with the value, try doing it with the value not the part, I wonder if there is a difference.

Same code, still works.
image

No, the difference is I deleted the part I was cloning from before loading the table, this I believe is the most likely cause.


still shouldn’t be intended behaviour.

1 Like

Why? I don’t see how this in any way relates to my issue?

Oh, sorry. I misread the message. My bad.

1 Like

So did you deleted the part and then cloned the deleted part’s children to a new part? :thinking:

Made a array of original part
Made the new part
Deleted original part
went through the array cloning the values into the new part.

Just tried doing that, and yup. It deletes the value inside of the folder.

local parts = workspace.Part:GetChildren()
workspace.Part:Destroy()
for i,v in pairs(parts) do
	v:Clone().Parent = workspace.Hey
end

Cloned:
image
Original:
image

2 Likes

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

image
Hello is the clone created before it’s origin was deleted.
Hey is the clone created after it’s origin was deleted.

I think this may just be an engine bug.

1 Like

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.

1 Like

Is this intended behaviour? it doesn’t feel like it.

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)