BC-0181 · TROUBLESHOOTING
Editorial review 2026-09-26
Checkpoint Does Not Work in Roblox Build
A checkpoint needs both activation and the intended later return location. Record the checkpoint touched, its acknowledgement and where the next ordinary respawn actually begins. A glowing marker alone does not prove that a return point was selected, and a round checkpoint is not automatically a permanent save.
Symptom
Checkpoint acknowledgement and the intended later respawn location do not agree.
Immediate action
State the marker-selection rule and preserve the activation-to-respawn trace.
Diagnostic branches
- Touching the intended marker has no clear acknowledgement.
- Investigate activation feedback without assuming a return point was stored.
- Activation is visible but the next safe observed respawn uses another location.
- Request agreement between the selected-marker rule and return location.
- Backtracking changes selection contrary to the authored rule.
- Correct that selection boundary rather than moving all checkpoint objects.
- Location is correct but score or inventory is wrong.
- Keep the working spawn selection and investigate reset-state retention separately.
Least-destructive change
Use existing safe activation/respawn evidence and repair selection without forcing loss of valuable progress.
Retest
- The selected-marker rule predicts both forward and safely available backward visits.
- An ordinary observed respawn begins at the intended location.
- The new-round boundary follows the declared starting-location rule without implying a cross-session save.
Escalation
If the return cannot be safely tested, leave it unverified and preserve the activation evidence. No stored-data guarantee or particular checkpoint API is inferred.
Working notes
Define the selection rule before testing. Does touching a marker choose the most recently visited checkpoint, preserve the furthest progress, or only acknowledge an objective? Backtracking can produce different correct outcomes under those rules. Use the intended rule, not the marker's appearance, to decide which return location is expected.
Inspect activation through ordinary safe play and note its visible feedback. If the design's normal failure/retry is safe for the current work, compare the subsequent spawn location with that marker. Do not deliberately lose valuable progress merely to force a respawn; an already observed failure can supply the needed trace.
Separate location from retained state. Returning to the selected marker with the wrong score or inventory is different from returning to the wrong marker. Record the location first, then hand off state-retention discrepancies to the reset guide rather than replacing checkpoint selection unnecessarily.
Compare forward progress and backtracking only where those routes already exist. A furthest-progress design should not silently move the saved return point backward on an earlier marker; a latest-touch design may deliberately do so. After a full new-round reset, inspect the intended starting location without extending the conclusion to a future login or another device.
Examples
- Selection example: the route reaches the bridge checkpoint, then returns through the earlier gate marker. If the authored rule is furthest progress, the next intended respawn stays at the bridge; latest touch would yield a different expected result.
- Proposed repair: Keep the current furthest-progress rule. After the bridge marker is activated, ordinary backtracking through the earlier gate must not replace that return point. Preserve the existing score and inventory reset rules.
- Trace fields: selected-marker rule / marker encountered / activation feedback / later failure or retry already observed / actual spawn / expected spawn. A visual marker change is not substituted for the later location check.