Hey folks!
Just a simple API question: Is :GetChildren() deterministic?
In other words, will :GetChildren() return the same results given the same ordering in the explorer hierarchy every single time?
1 Like
A simple test gives us the answer:
No.
Nothing more to it. Can I ask why exactly you want it to follow the exact hierarchy? There may be a different solution.
1 Like
Just test it out to know;
-- Make sure to run when nothing new is being added to the instance having its children read from
local function same(t, t2)
for i, v in ipairs(t) do
if t2[i] ~= v then return false end
end
return true
end
local lastArray = workspace:GetChildren()
for i = 1, 30 do
game:GetService(“RunService”).Heartbeat:Wait()
local newArray = workspace:GetChildren()
if not same(lastArray, newArray) then
print(“GetChildren is undeterministic based on 30 iterations”)
break
end
lastArray = newArray
if i == 30 then
print(“GetChildren is deterministic based on 30 iterations”)
end
end
1 Like
The developer hub (Instance | Documentation - Roblox Creator Hub) specifically states that “The children are sorted by the order in which their Parent property was set to the object”, so yes it will always be returned in the same order as the hierarchy in the explorer.
2 Likes
Interesting contradiction. Whether it does or not, I would tend to think designing anything around that documented behavior would be not the best idea.
1 Like
Interesting statement because I just ran my own test and this was not the case.
1 Like
I had tried it myself some time ago and no, at least not with me, although I had done everything correctly.
1 Like
This may not be telling you that the returned table is sorted but simply they’re sorted in explorer. If you try it yourself you may see different results.
So pretty much this is false either way you look at it.
And yes, the same thing happens with pairs and ipairs
2 Likes
This is exactly what I was talking about. I was working on a project and I thought what the wiki told me. But it seems to be wrong, so I lost hours. It really sucks
2 Likes
Yes.
If you really wanted to sort things how the explorer does, you sort them alphabetically.
local children = table.sort(children, function(a, b)
return a:lower() < b:lower()
end)
Something like that. You may have to mess around with it a little more but that’s the basic concept.
idk why I said yes at the beginning but yes.
2 Likes
This behavior is documented, you just have to read it.
It works the way it’s stated it’s not ordered as seen in the hierarchy, that’s not what is stated.
2 Likes
Once again, tested this out and it wasn’t the same.
1 Like
@RuizuKun_Dev
I don’t think you understand what we’re talking about. Try it yourself, a simple script. You will see that the result will be quite different from what we were promised. I tried it myself and @suspectshot108 even showed a screenshot. With full respect.
OK, so you agree with us that it doesn’t work in sync with the explorer?
It will display Instances in an alphabetical order so it’s easy to find; however GetChildren will return an array of Instances in an order they were added.
The children are sorted by the order in which their
Parentproperty was set to the object.
This makes sense because internally they are probably using an array like object to store the Children
If you want GetChildren array to be in sync with the Explorer you can make code that will parent the items in an alphabetical order or sort the GetChildren array.
2 Likes
I have. The screenshots are from a playtest. The children were in the exact same order.
1 Like
I made a mistake earlier stating that they will be returned in the order of the explorer. @suspectshot108, @RuizuKun_Dev is correct the children are returned based on the order in which they are parented to object, I just tested this.
How you see objects within the viewing tree doesn’t necessarily have objects sorted in the order their Parent property was set, e.g duplicating a part might not have the duplicated part show up at the end in the explorer, it might even be inserted between the original part and the next in the explorer.
Set up the Parent property yourself individually through late instancing or something for multiple parts with unique names and when you iterate through the container (containing these late instanced objects) and print every part’s name you’ll notice the order.
Hello! Yes, of course GetChildren is “deterministic”! As correctly stated by @cjjdawg, when calling this function on an object, it returns its child instances according to the order in which they were parented to that object.
You can prove this in many, many ways. Here’s a very intuitive one:
math.randomseed(tick())
local tab = workspace.Folder:GetChildren()
local backup = {}
for i = 1, #tab do
local n = math.random(1, #tab)
tab[n]:Clone().Parent = workspace
backup[1 + #backup] = tab[n]
table.remove(tab, n)
end
print("Instances were parented to workspace in this order: ", table.unpack(backup))
print("When calling GetChildren on workspace, we are given objects in this order: ", table.unpack(workspace:GetChildren()))
I placed 8 objects, named A to H inside a folder parented to the workspace. Then this code will choose every object in a random order, copy it and parent it to the workspace. You will see that workspace:GetChildren() will always return the objects in the same order they were parented to the workspace.
Edit: output example
Instances were parented to workspace in this order: B C D A G E F H
When calling GetChildren on workspace, we are given objects in this order: Camera Terrain Folder B C D A G E F H
Note: It’s true the devhub is known for its bugs and typos, but an error like this is very infrequent. You should normally trust the information provided in the devhub articles.