I am was doing BrawlDev beginner tutorials but I don’t know why WaitForChild and FindFirstChild are important and if somebody can also explain the code of the kill bricks and the model detecting if part2 exists since I don’t understand how it works. Lastly which projects should I do to understand furthermore knowledge of WaitForChild and FindFirstChild?
local killbrick = script.Parent
killbrick.Touched:Connect(function(otherpart)
local humanoid = otherpart.Parent:FindFirstChild("Humanoid")
if humanoid then
humanoid.Health = 0
end
end)
local model = script.Parent
local part2 = model:WaitForChild("Part2")
if part2 then
part2.BrickColor = BrickColor.Color3.fromRGB(255, 0, 0)
print("part2 is found")
end
Hey! Okay, I will try to explain this as best as I can.
There is a hugeeee difference between waitforchild and findfirstchild. Both are used when trying to “find” something. FindFirstChild searches right now instantly, and if it does not find it, it returns nil. WaitForChild searches, but if it is not there it pauses the script and waits until it is there, or till a timeout (WaitForChild("Humanoid", 5)) 5 would be the timeout in this example. FindFirstChild is best for situations where the object might not be there, and you are okay with that. WaitForChild is best for when you KNOW it will be there.
Kill Brick Code Explanation
Main Kill Brick Part
local killbrick = script.Parent
killbrick.Touched:Connect(function(otherpart)
local humanoid = otherpart.Parent:FindFirstChild("Humanoid")
if humanoid then
humanoid.Health = 0
end
end)
killbrick.Touched:Connect(function(otherpart) ... end) — this connects a function to the brick’s Touched event. Whenever any part touches the brick, this function runs, and otherpart is whatever part touched it (could be a leg, arm, torso, a random ball someone threw, anything).
otherpart.Parent:FindFirstChild("Humanoid") — since otherpart is just one limb/part, we look at its parent (the whole character model) and check if it has a Humanoid inside it. Only actual player/NPC characters have a Humanoid — a random dropped part wouldn’t.
FindFirstChild is used here (not WaitForChild) because most things that touch the brick won’t have a Humanoid at all. That’s expected and normal — you don’t want to wait around for something that may never come. You just want to check “does this exist? No? Fine, do nothing.”
if humanoid then humanoid.Health = 0 end — if a Humanoid was found, set its health to 0, which kills the character.
Part2 Code
local model = script.Parent
local part2 = model:WaitForChild("Part2")
if part2 then
part2.BrickColor = BrickColor.Color3.fromRGB(255, 0, 0)
print("part2 is found")
end
model:WaitForChild("Part2") — this time we expect Part2 to exist inside the model, we just might be running this script before Part2 has fully loaded in. So instead of risking an error, we tell Roblox “wait until Part2 shows up, however long that takes, then give it to me.”
Because WaitForChild pauses until it finds the object (it doesn’t return nil the way FindFirstChild does under normal use), the if part2 then check right after is actually redundant — by the time that line runs, part2 is guaranteed to exist. It’s not wrong, just unnecessary here.
One real bug: BrickColor.Color3.fromRGB(255, 0, 0) isn’t valid — you’re mixing two different color systems. It should be either:
part2.BrickColor = BrickColor.new("Red") (BrickColor system), or
part2.Color = Color3.fromRGB(255, 0, 0) (Color3 system, sets the actual Color property, not BrickColor)
Some ways to practice would be:
Tool/Weapon with delayed parts* — build a sword tool where the blade Part loads a moment after the tool itself; use WaitForChild in the tool’s script to grab it safely.
NPC with a variable inventory — spawn NPCs, some with a “special item” child and some without; use FindFirstChild to check for it and react differently.
Checkpoint/leaderboard system — use WaitForChild to grab leaderstats under a Player, since leaderstats often get added by a separate script and may not exist the instant your script runs.
A “trap” brick that checks tags — similar to your kill brick, but check FindFirstChild("ImmuneTag") on the character before killing them, so tagged players survive.
Loading a GUI element that’s created dynamically — a script that clones a GUI into PlayerGui, then a second script that uses WaitForChild to find it (since it wasn’t there at game start).
I hope this helped, and you understand it more. Let me know if you need a better explanation!
Asher explained it pretty well but later you might be spamming WaitForChild. The function WaitForChild is often used to find parts in workspace as parts & meshes sometimes aren’t loaded there. And this basically only applies for them as Models and Folders are always loaded so workspace:WaitForChild(“Rockfolder”) is not needed. There also isn’t a need to call WaitForChild on Server Scripts (Script) as the server always loads all Parts in the workspace.
(If your script is telling you a instance doesn’t exit you might still need to use WaitForChild)
Considering streaming WaitForChild make no sense at all. By design. More suitable for such cases ChildAdded or DescendantAdded.
As @asher_dz has said, FindFirstChild gets child by its name and returns immediately, WaitForChild does the same if the child is there and blocks indefinitely if it’s not there. Or, in client code, if the child has not been streamed yet.
Also WaitForChild makes no sense on server side for “static” instances. Can be used for “tricky” logic though, for example, one server script might wait for another server script to create the child.
wrong, just cause the server starts with the instances, does not mean WaitForChild makes no sense.
server just like client has to “download” / initialize instances when its opening.
there can be edge cases where your server scripts are executed before server initialized the instances you are so happened to be indexing, causing regular member expression to error (workspace.SomeThing)
server has to unpack .rblx file, deserialize it and put instances into server memory, it takes time (half a millisecond, hence it being an edge case)
image this:
you have place with 2000 instances (lots of map parts and etc),
server opens up
your script tries to get BlockA in workspace, but your script executed much earlier than the BlockA was put in memory due to big instance queue, giving u result of an error
its not related directly to waitforchild, by sending that link I imply that its common sense to understand that no matter how fast things are, they take time to happen, same with server opening up and putting instances in the memory
you don’t even understand basic engine design and you call yourself The_GrandOptimizer (cringe user btw)
you don’t need to decompile studio to know that an engine WaitForChild would rely on FindFirstChild, it’s documented that WaitForChild would yield only if the instance wasnt found at initial lookup, can’t you conclude from that that it uses FindFirstChild?
