Reaching Into the Tree From Code

Inside any script, the global script refers to that script itself. So script.Parent is whatever it is sitting inside — for a killbrick, the laser part.

local laser = script.Parent   -- the part this script lives in laser.Touched:Connect(function(otherPart)    print("hit", otherPart.Name)end)

This is the right tool for a script that belongs to one part, and it has a real advantage: duplicate the laser and the copy works immediately, with no names to update. Nothing about the path depends on what anything is called.

It becomes fragile the moment you chain it. script.Parent.Parent.Parent encodes the exact depth of your model into the script, and reorganising the Explorer — dropping the laser into a folder, say — silently changes what that expression means.

workspace.Obby.Laser looks like a path in a language that has paths. It is not. Each dot is a search of that object's children for one matching the name, done freshly, at the moment the line runs.

So the expression is only as reliable as the names in it. If Laser has been renamed, is inside a folder now, or has not loaded yet, that dot does not quietly come back empty. It throws on the spot and the script stops.

workspace.Obby.Laser.Transparency = 0.5 -- If Obby exists but Laser does not:--> Laser is not a valid member of Model "Workspace.Obby"

That message is precise: it names the child it could not find and the exact object it looked inside. The harder error is the one you get when a lookup that is allowed to fail hands you nil, you store it, and you use it a line later.

local laser = workspace.Obby:FindFirstChild("Laser")  -- nil, no errorlaser.Transparency = 0.5--> attempt to index nil with 'Transparency'

FindFirstChild does the same search and returns nil instead of throwing. That single difference is what lets you check before you act — and the check is not optional, because skipping it just moves the crash down a line, as you saw above.

local laser = workspace.Obby:FindFirstChild("Laser") if laser then    laser.Transparency = 0.5else    warn("No Laser in Obby — was it renamed?")end

The warn in the else branch is doing real work. A script that silently does nothing when a part is missing is worse than one that crashes, because a crash at least tells you where to look.

There is a family of these, and two are common enough to learn by name.

A Roblox place does not load all at once. On the client especially, a script can run before the object it needs has replicated in — so a lookup fails not because the object is missing but because it is late.

WaitForChild yields the script until the child appears, then returns it.

local obby = workspace:WaitForChild("Obby")local laser = obby:WaitForChild("Laser") -- Both exist by the time this line runs.laser.Transparency = 0.5

It waits indefinitely by default, and after five seconds it prints an "Infinite yield possible" warning to the Output window. That warning is not an error and the script has not stopped — it is Roblox telling you the thing you are waiting for may never arrive, which usually means a typo.

Roblox has no getters and setters. A property is read and written with =, using exactly the name shown in the Properties panel — including its capitals.

local part = script.Parent part.Transparency = 0.5part.CanCollide = falsepart.BrickColor = BrickColor.new("Really red")part.Material = Enum.Material.Neon

Two things there are not plain values. BrickColor and Color3 are constructed types, and Material is an Enum — a fixed set of named options. Writing part.Material = "Neon" with a plain string fails, because the property wants the enum item and not text that resembles it.