Add Instance:GetDescendants()

[Tiffblocks]

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.

[sleitnick]

Noticed that this was added today. Awesome! Excited for it to be enabled.

[Tiffblocks]

Instance:GetDescendants() is now enabled. However, as of right now only desktop, studio, and iOS are on new enough versions to support it.

[CodeNil]

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.

[AlreadyPro (Logan)]

GetDescendantsOfClass, perfect.

[Tomarty]

@AlreadyPro

GetDescendantsOfClass, perfect.

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.

Generalizing Whitelists/Blacklists for huge API performance gains

I was replying to @Davidii’s raycasting use-case thread, and had an idea for unifying everything related to whitelists, blacklists, and the much needed raycast-with-callback feature. I’m suggesting a generalized ‘InstanceCondition’ object for whitelisting/blacklisting things. This would generalize blacklists, whitelists, and callbacks, plus some specific use-cases like testing for transparency/non-cancollide/class could have their own types to boost performance InstanceCondition could be an …

@Tomarty

Imagine having this applied to instance:GetDescendants(), this has so many use cases!

For example instead of calling GetChildren and IsA thousands of times using something like this:

local function recurse(container)
local children = container:GetChildren()
for i = 1, #children do
local child = children[i]
if child:IsA(“BasePart”) then
child.Locked = true
end
recurse(child)
end
end
recurse(workspace)
You could just do this:

local parts = workspace:GetDescendantsOfCondition(InstanceCondition.newIsA(“BasePart”))
for i = 1, #parts do
parts[i].Locked = true
end

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.

[AlreadyPro (Logan)]

I love this idea, full support

[Tiffblocks]

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.

[sleitnick]

What do you think of @Tomarty’s post a couple up?

[Tiffblocks]

I do not think it’s a good idea.

[AlreadyPro (Logan)]

Are we ever going to get the same methods for WaitForChild?

[Tomarty]

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.

[EchoReaper]

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?)

[Maximum_ADHD]

bLoAtInG

There has to be a better solution here.

[Fractality_alt]

WaitForChildOfClass

Common need: Find the humanoid of a character immediately when it becomes available after spawning. Usual solution: WaitForChild. humanoid = character:WaitForChild'Humanoid' Why this is bad: Your code breaks if the humanoid isn’t named Humanoid, or if there’s another member of the character that happens to be named Humanoid. It’s ugly to make assumptions about name. Solution: WaitForChildOfClass. humanoid = character:WaitForChildOfClass'Humanoid'

[Fractality_alt]

Does GetDescendants make any guarantee about order?

[einsteinK]

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)

[Fractality_alt]

Yeah, I’m just interested in whether it’s depth-first or breadth-first and whether that ordering is guaranteed

[Tiffblocks]

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.