Last week I shipped a feature: faction-styled gateway portals at the three homeland frontiers. They worked perfectly in Edit. They worked perfectly when I ran the lune suite. They failed silently when a real player teleported through one.
This is the postmortem.
The feature
Each launch faction has a “homeland frontier” — the portal that lets their members enter contested territory. I wanted each portal to:
1. Render in the faction hard-locked palette (e.g. Alliance navy + gold, Horde blood red + bone)
2. Play a 1.5-second faction-themed warp FX on teleport
3. Cooldown for 8 seconds after use (anti-spam)
What I tested
In Edit mode: visual + click handler + warp FX. All green.
In lune suite: handler logic + cooldown timer. All green (24 suites, 135 PASS lines).
In Play mode (single-player self-test): teleport through Alliance portal -> arrive at Alliance Front -> warp FX plays -> cooldown ticks. All green.
What broke
The first real Play test by a beta tester: teleport through the Alliance portal -> arrive 200 studs off the ground at the Alliance Front, fall to death, lose gear.
Silent failure. No error in the console. The teleport succeeded. The destination was wrong.
Why it broke
The destination CFrame was being computed at module-load time on the server, using a hardcoded coordinate from the Alliance Front waymark network. The waymark had been moved earlier that day (commit 7068f51 — “Stitch homeland landmarks with a deterministic waymark trail network”) to fix a different bug.
The teleport code was still pointing at the old coordinate. Edit mode showed the right visual because Edit mode uses the CLIENT current camera frame, not the server resolved waymark. lune suite passed because the test instantiated the module fresh and computed against the test-fixture waymark, not the live one.
Play mode (single-player self-test) passed because I tested from the same Edit session that had the right coordinates cached.
Real player broke because the server resolved the live waymark, which had moved.
The fix
Two commits:
1. trail live path: defaultDeps was missing makeCFrame — the trail-builder was producing stale CFrames because it did not have access to the makeCFrame helper at module init. Adding the dep fixed the resolution path.
2. Root-cause trail live-verify blocker: dead rojo serve and sync race — Rojo 7.7.0 had a known atomic-write race that caused stale state on rojo serve restarts. Pinned to a known-good atomic-write behavior.
Both commits are live. The portal now teleports to the live waymark every time.
What I learned
Three rules I am adding to every Play test from now on:
1. Edit-mode visual does not equal Play-mode behavior. Always run a Play probe before claiming a feature works. The visual pass is necessary but not sufficient.
2. lune suite does not equal live behavior. Tests that use fixtures will pass even when the live data is wrong. Add at least one test per feature that resolves against the CURRENT live state, not a fixture.
3. Self-test from a stale Edit session does not equal real-player test. If you self-test from the same session that wrote the feature, you carry the cached state with you. Real player, fresh session, fresh Play boot is the only honest test.
Why I am posting this
Because if you are building a Roblox game — or any game — the same three failure modes will hit you. Edit-mode visual, fixture-based test suite, and stale-cache self-test will all show you green when the game is broken.
The cost of catching this bug now: 2 commits + 4 hours.
The cost of catching it after launch: thousands of player reports + a Discord crisis + a season-rollback.
Play tests cost less than postmortems. Always.
Try EFER: Roblox -> Search “Eternal Fusion: Eternal Realms”
Read the full V6 sprint ledger: EFER AAA V6 PROGRESS — public progress ledger
Get the lore book: Eternal Fusion: Eternal Realms — The Lore Book on Gumroad
Next devlog: what I am building now that the portals are stable.
