Support paths in FindFirstChild and WaitForChild

Currently using :FindFirstChild() or :WaitForChild() is annoying for developers to use. It takes a longer to type and bloats code. Supporting paths in FindFirstChild and WaitForChild would fix this and would make updates New Content Property on TextObjects like this less problematic

local PlayerGui = game.Players.LocalPlayer:WaitForChild("PlayerGui")
local CashFrame = PlayerGui:WaitForChild("ScreenGui.Folder.Frame.Cash")

What about for games that actually name their instances this way? Could present the same problem. Ideally there should probably be a new function Instance:WaitForPath/FindFirstPath, but I do agree these conflicts can be annoying.


1000% this. I recall a survey looking into this a few years ago and pretty much everyone wanted it. It might be a good idea to come up with a method that doesn’t involve splitting the path by a certain character to prevent naming conflicts. Maybe have a separate function for finding an entire path?

Also, obligatory “I have a library that does what you’re looking for” link:


I feel like a much better implementation would be an array of strings to avoid syntax conflict, but overall I agree that this would be a great feature to add.


Possibly making WaitForChild/FindFirstChild take any number of variables (I mean the things you put into the function, I don’t know the correct word for it), like print does.

Instead of this:

It would be this:

local CashFrame = PlayerGui:WaitForChild("ScreenGui", "Folder", "Frame", "Cash")

That would solve the problem of objects with . in their name.

WaitForChild and FindFirstChild take additional arguments after the name argument, so how would it interact with those?

-- example of other arguments

-- would the variable number of arguments be used like

-- or like this?

It would be weird to have other arguments after variable arguments (do any other functions do this?). The 1 could be interpreted as an implicit conversion from number to string (passing a number to FindFirstChild and WaitForChild for the name implicitly converts it to a string) which would make it ambiguous as to whether the 1 is used for the timeout or as another string for the path.