Roblox Scripting Tutorial: Understanding FindFirstChild and WaitForChild

·

·

Alright, welcome back to another scripting tutorial. Today we’re talking about two really useful functions in Roblox scripting that will help you find objects in your game without your code breaking: FindFirstChild and WaitForChild.

Let’s get into it.

Understanding the Roblox Hierarchy

If we open up the Explorer, we can see how Roblox organizes everything in a sort of folder structure. You’ve probably seen this already — you’ve got Workspace, and inside that maybe there’s a Baseplate, and under that, something like Texture. So that’s kind of the idea: every object has a parent (the folder or container it’s in) and can also have children (the things inside it).

This is important because when you’re writing scripts, you’re going to be navigating this structure a lot. And to do that safely, especially if you’re not sure if an object exists yet, you use these two functions: FindFirstChild and WaitForChild.

Working With Models and Folders

Let’s say you make a Model in Workspace. You drag some parts into it — call them Part1, Part2, Part3. This makes them children of the model. You can tell because when you move the model, all the parts move with it.

Now, Models are great when you want to group parts together. Folders, on the other hand, are more like general organizers — they don’t group objects physically. So if you use a Folder and move it around, the parts inside won’t move with it. You’d use a folder for organizing stuff logically, and a model when you want everything to behave as one object.

Using FindFirstChild

Let’s say you have a script inside a model and you want to reference one of the parts in that model.

Instead of doing something long like:

local model = game.Workspace.Model

You can just say:

local model = script.Parent

Since the script is already inside the model, script.Parent gives you the model directly.

Now let’s say you want to access Part1. You might be tempted to do:

local part1 = model.Part1

But here’s the issue — if Part1 doesn’t exist, that’s going to break your script. That’s where FindFirstChild comes in:

local part1 = model:FindFirstChild("Part1")

This way, if Part1 doesn’t exist — maybe you deleted it or renamed it — the script won’t crash. It just returns nil, which is safe. You can even wrap it like this:

if part1 then
part1.BrickColor = BrickColor.new("Cocoa")
end

Try it yourself: delete Part1 from the model and run the game. You’ll see nothing bad happens — it just skips that part. No errors, no red text, everything runs smoothly.

Using WaitForChild

Now let’s look at WaitForChild.

Say you want to reference Part2, but maybe it won’t be there immediately — maybe another script adds it later. If you do:

local part2 = model.Part2

Again, this might break if it doesn’t exist yet.

You could do:

local part2 = model:FindFirstChild("Part2")

But what if you know it’s going to show up — just not right away? That’s when you use:

local part2 = model:WaitForChild("Part2")

What this does is: the script waits until that part appears. So if Part2 gets added a few seconds later, the script doesn’t break — it just waits. Super useful when dealing with things that might load in after the game starts.

If you run this and remove Part2 from the model, then paste it back in while the game is running, you’ll see that it works — the script waits and then moves on. If it waits too long, you’ll get a warning like “infinite yield possible on WaitForChild,” which just means it’s been waiting a while and still hasn’t found the part.

A Real Example: Kill Brick

Let’s end with something fun and practical — a Kill Brick.

Make a red part, name it KillBrick, and put a script inside it. Here’s the code:

local killBrick = script.Parent

killBrick.Touched:Connect(function(hit)
local character = hit:FindFirstChild("Humanoid")
if character then
character.Health = 0
end
end)

So what’s happening here?

Whenever something touches the kill brick, the script checks: does this thing have a Humanoid inside it? That’s what Roblox characters have. We use FindFirstChild("Humanoid") because not everything that touches the part will be a player. Could be a random part. If it is a player, Humanoid will exist, and we set its Health to 0 — which resets the character.

And that’s it! You just made a functional kill brick using FindFirstChild in a real-world example.


This is a super beginner-friendly and essential concept in Roblox scripting. Using FindFirstChild keeps your code from breaking when things aren’t there. Using WaitForChild helps your script wait for things that will appear later. Both are incredibly helpful when you start building more complex games.

Thanks for sticking with it — and as always, go back and rewatch or re-read parts if you need to. In the next tutorial, we’ll dive into even more cool scripting stuff. See you then!