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).
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 GetChildrennormally 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.
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
