The way I implemented GetDescendants means that the return type is purely visual/documentation. It uses raw Lua API manipulation to create the table and put the instances in it (like Terrain:ReadVoxels()). Both Array and Objects correspond to different types internally, when not using raw Lua API.
Noticed that this was added today. Awesome! Excited for it to be enabled.
Instance:GetDescendants() is now enabled. However, as of right now only desktop, studio, and iOS are on new enough versions to support it.
Thanks for this amazing feature, saves alot of time, would it be possible to add an argument to GetDescendants for class, so you can do Instance:GetDescendants(“BasePart”) to return all BaseParts within that instance, would save even more time by not having to loop through GetDescendants and create a new table.
The api is going to get so messy! We just need a single powerful method like :GetDescendantsOfCondition(condition), where condition would be much more generic.
You could also potentially use that suggested feature to filter parts where CanCollide=false, or Transparency=1, or any combination of things, and most importantly it would be fast.
I love this idea, full support
I’ve considered adding GetDescendantsOfClass and GetDescendantsWhichAre methods to accompany it. It seems relevant to the common usecase of model-based invisicam, because recursing through the model and calling :IsA() on everything to find stuff to make transparent is quite slow.
What do you think of @Tomarty’s post a couple up?
I do not think it’s a good idea.
Are we ever going to get the same methods for WaitForChild?
Every time a new method is added to Instance, there’s a chance it will break someone’s code, for example:
local module = require(script.Modules.GetDescendantsWhichAre)
If there’s a way we can fit more functionality into a single method in a way that makes sense, I think it’s worth considering.
I agree that spamming in new API members is bad, more specifically for bloat than anything else. I agree that an alternative that doesn’t involve API bloat would be worth looking into, though not the previously linked thread because it would increase code bloat in the cases where we’d otherwise make a dedicated feature, and also seems pretty niche (if for pretty code, why don’t you make a module, and if for performance why don’t you organize your instances in a way where you can easily trim what you’re searching down from the beginning?)
There has to be a better solution here.
Does GetDescendants make any guarantee about order?
I would assumed it’s the same order as GetChildren (it doing a recursive thing), which also doesn’t have a “defined” behaviour (although it’s pretty safe to say it’s in the order the childs got added/replicated)
Yeah, I’m just interested in whether it’s depth-first or breadth-first and whether that ordering is guaranteed
I wrote this in ReflectionMetadata:
Returns an array containing all of the descendants of the instance. Returns in preorder traversal, or in other words, where the parents come before their children, depth first.
But for some reason, the wiki has replaced it with the much less insightful:
Returns an array containing all of the descendants of the instance.
In other words, this returns the children of this instance, and the children of those children, and so on.
I have fixed this.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.