Interesting statement because I just ran my own test and this was not the case.
I had tried it myself some time ago and no, at least not with me, although I had done everything correctly.
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
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
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.
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.
Once again, tested this out and it wasn’t the same.
@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
Parent
property 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.
I have. The screenshots are from a playtest. The children were in the exact same order.
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.
But then why wasn’t that the case with me? I had even added 20 parts manually from about 100 parts, one piece at a time, but it failed. For example: (I don’t remember exactly from the output) If I added parts A B C to the workspace in this exact order (by hand, not by code), then maybe I got a list with the order of BAC, CAB, BCA, CBA or ACB, everything except A B C. I’m pretty sure I did everything correctly. So I had assigned each part to the workspace one by one and the result was “Wrong”. I was stuck for hours, if not days. So I certainly did not make a mistake. Why would it work for some people and not for others?
Or some forces are playing a trick on us, or the Devhub just has a mistake. There have been a few mistakes on the Devhub, it can happen sometimes.
EDIT:
Recently @Alvin_Blox made a tutorial about this. I wonder if he is aware of this (I’m just asking this out of curiosity, really nothing more).
The Video:
Perhaps the issue was in the chunk you used to obtain the resulting order. Did you use pairs
in a for
loop? If so, this might explain why the iteration did not follow any order when indexing objects inside the table.
However, I searched up this on older devforum topics and found that there’s a big confusion even among Roblox staff…
The children are returned in ChildOrder, this is the order that the children are added in. The first children to be added are first in the table GetChildren returns.
This is however not guaranteed and it could be changed in the future.
Currently :GetChildren() is consistent when deserializing and serializing to a file but it may not be consistent across the network. It sounds like we’re going to make the guarantee in the future that the order will be consistent even across the network.
@daftcube At this point I think it’s up to you to extract your own conclusions. My point is GetChildren
normally returns an ordered table, but it is by no means a reliable behaviour. So don’t assume this function is “deterministic” in your work!
I used ipairs, pairs (pairs rather not) and even a for loop, so I do not see why that should be a problem.
Maybe this explains everything.
I think so too. But since we unfortunately can’t see the inner function exactly, I think that it will be difficult for us, Devs, to understand this function correctly. For the rest I just assume that maybe this function will never be understood correctly. But who knows, everything could change.
I had no idea this was going to spark such a large discussion! Thanks for everyone who responded, I learned quite a bit here.
it claims that it works like that however i’m having issues as to where it’s working exactly not like that, i have a gui that displays the children of a folder in viewportframes however they went out of order when i replaced the folder with a copy of itself, same order same everything, and everything is just jumbled up and makes zero sense, so i believe this sadly is not the case