Module 9 · Events and scheduling
Event parameters
Receive the specific data an event supplies and validate what it represents.
What you will learn
- Read an event callback parameter
- Trace a touched Part back to a possible character
- event parameter
- Data supplied to a callback when an event fires.
- character
- The in-world Model representing a player's avatar.
Loading saved progress…
Understand
Read the idea and follow a worked example.
Why this matters
Touched tells Coin Quest which other Part made contact, but that Part could belong to a character, loose debris, or another world object.
The mental model
The Touched callback receives the other BasePart. Its Parent may be a character Model, but code must check rather than assume.
A touch is evidence of contact, not proof of a player or permission.
New words and symbols
--!strict asks Studio to check your code for type mistakes. It is an instruction for the editor and produces no Output message.
Matching quotes such as "hello" surround a string: a piece of text. The quotation marks tell Luau where the text starts and ends.
print(...) calls the built-in print function. Put the values to show inside its parentheses; separate multiple values with commas. Read the result in Studio's Output panel.
local is read as “local”: it creates a name that is available only in the current code scope.
if is read as “if”: it starts a decision by evaluating a condition.
then is read as “then”: it marks the body that can run when the condition is truthy.
end is read as “end”: it closes a block such as a decision, loop, or function.
: is read as “colon”: it calls a method with the object supplied as the first receiver value.
= is read as “is assigned”: it evaluates the right side and stores that value in the name on the left.
A tiny example
--!strictlocal Players = game:GetService("Players")local checkpoint = script.Parentassert(checkpoint:IsA("BasePart"), "Script must be under a BasePart")checkpoint.Touched:Connect(function(otherPart: BasePart) local character = otherPart.Parent local player = character and Players:GetPlayerFromCharacter(character) if player then print(player.Name, "reached the checkpoint") endend)Line by line
- 3
Players provides the supported character-to-player lookup.
- 7
Touched supplies the contacting BasePart.
- 8
Its parent is a candidate character.
- 9
GetPlayerFromCharacter validates that candidate against connected players.
- 10
The guard rejects non-player touches.
Read the code aloud
Read one statement at a time: name the value being read, what the operation does, and where its result goes. Keep identifiers exactly as written so you can find them again in the code.
Pause at calls, conditions, and loops. Explain when the body runs before moving to the next statement; use the line notes above when a symbol is unfamiliar.
Execution trace
Start with the statements outside function bodies. A function definition creates a callable value; its body runs when a call, event, or scheduled task reaches it.
Trace the arguments at each call and the branch or loop inside that call. Return to the caller when the function returns. For an event, use the action named in Try it to trigger the callback.
Line 3: Players provides the supported character-to-player lookup.
Line 7: Touched supplies the contacting BasePart.
Line 8: Its parent is a candidate character.
Line 9: GetPlayerFromCharacter validates that candidate against connected players.
Line 10: The guard rejects non-player touches.
State before and after
Before running, identify the starting values and any existing Studio objects this example needs. List what you expect to change.
After your practice change, check this result: Only character-owned contact reaches the player-specific branch.
Reading or printing a value leaves it unchanged. Look for assignments, calls that change state, and property updates to explain each change you observe.
Predict before running
What happens when a loose Part touches the checkpoint?
Try it
Mark each step after you have tried it.
Common mistake
local player = Players[otherPart.Parent.Name]Names are not proof that a Model is a connected player's character. Use GetPlayerFromCharacter.
Checkpoint
Submit once you have considered every question. Retries are unlimited.
Recap
- Events can supply useful parameters.
- Touched supplies contact, not identity.
- Validate a candidate character with Players.
Next: Next, you will keep and disconnect event connections deliberately.
Studio Companion
Not connected
Connect once. Compatible challenges will prepare automatically as you reach them.