The CORRECT way to use dots, FindFirstChild(), and WaitForChild()!

Hey there! If you’re reading this, that must mean you’re confused on FindFirstChild(), WaitForChild(), and Item.ItemInsideOfParentedItem (this is an example). I won’t bore you with boring stuff, so let’s start!

Item.BlockThatIsParentedUnderItem

When using the dot (.), you save some time typing. (There’s more). This is used when you are SURE that the item is parented under the other item. An example of this would be

local part = game.Workspace.Part

When the script runs, the part is already in workspace. But what if you wanted to check if a part is inside an another part? If you use the dot, and it’s not there, it throws an error. We don’t want that! So, to check if a part is in another part, we use the next function!

FindFirstChild()

FindFirstChild() is used for checking is a part is in another part. Here’s an example of code

local humanoid = touchedPart.Parent:FindFirstChild("Humanoid")
-- This would be used in a killbrick script

For this, we would use FindFirstChild(). Why? Because, if for some whatever reason a part flys out of the sky and hits the lava, well, that part doesn’t have a humanoid! If we used the dot, it would throw an error. If we use FindFirstChild(), then the variable humanoid would be equal to nil. We can then use an if statement and kill the player if the humanoid is not nil. Now then, there’s one more function that is commonly misused. And that is…

WaitForChild()

WaitForChild() is basically what the name suggests, it waits for the parameter to become a child of the item. Also, the code underneath the WaitForChild() won’t run until the WaitForChild() statement finds the child. For example, let’s say we had one script that did this

wait(2)
local part = Instance.new("Part") -- Creates a part
part.Parent = game.Workspace -- Parents the part

And another script that did this

local part = game.Workspace:WaitForChild("Part") -- Will wait until part is added
-- Code below runs after the part is found --
print("Two seconds have passed, and the part exists!")

(Please don’t actually use this in your actual code it’s just an example)
This is good for large models too. Let’s say we had a model with like a thousand parts that will load in when the game starts, something like this

-- Insert random script here that makes the model load --

One thousand parts won’t load so quickly, so if we wanted to print something after it’s loaded, we would do this

local model = game.Workspace:WaitForChild("Useless_Model")
print("Oh my god the model loaded")

(Sorry if example is bad I couldn’t think of many examples)
(You get the point right?)
A common mistake for developers is using WaitForChild for absolutely EVERYTHING, something I did when I first learned about it. Here are 2 reasons not to do this:

  1. It takes so freaking long to type
  2. It’s seriously unecessary

Conclusion

And that sums it all up! I hope you learned something in this tutorial! If you have better examples for the WaitForChild(), feel free to comment down below, I’m sure newbies would appreciate it. Anyways, that wraps up today’s lesson. Have a great time developing fellow devs! (Mostly scripters)

Did this help you?

  • Yes
  • No
  • I just read this for fun
  • I freaking didn’t understand this and I should comment down below for assistance

0 voters

7 Likes

another thing is that using . is more efficient than FindFirstChild()/WaitForChild()
so if you have a loop on large number of objects and you are sure that the children exist
you should use .

6 Likes

Thanks for providing ALOT of helpful information! :slight_smile: (Seriously)

Good introduction. Only thing you could include is the timeout parameter within the WaitForChild() function, which ends the yield if the item to look for is not found within the timeframe (in seconds). This’ll prevent any infinite yield warnings within the console/output.

local part = workspace:WaitForChild("Part", 5)
1 Like