Previously documented GetDescendants order no longer documented


On the old wiki, the order of GetDescendants was clearly explained and shown:

However now, the order is no longer documented.

Is this intentional and this order shouldn’t be relied on, or just an oversight in the documentation?



Through some experimentation it appears GetDescendants() will return a list of descendants in the order they were added to their parents. Order occurs in a depth-first manner, getting A.B, then B’s children, then A.F then F’s children.

This behavior is in contrast to the explorer reordering children alphabetically when you reload or paste a tree of instances.

This is likely a side effect of the internal data structure and I don’t think this should be documented because that would suggest it’s safe to rely on, which I don’t think is wise.

In the image below, the members A.B.Apple and A.B.A have been cut and pasted and are the last two instances to be added to A.B. The save file was reloaded to cause the explorer to reorder the instances alphabetically.

image image



The order of objects returned by GetDescendants is likely the same as from GetChildren. Note that this order is not necessarily reliable:



It is explicitly defined that GetDescendants returns instances in preorder traversal order, according to the “child order” of the instances. Note that child order is different from insertion order.

It’s definitely an omission that these docs didn’t make it over to the developer hub, and I’ll try to get this fixed.



@Kampfkarren @Tiffblocks Thank you for bringing this to our attention. It was definite an oversight on our end. I’ve updated the documentation on the DevHub with the content from the wiki page.