TeslaRel410/emulator/render-bridge/DEATH-SEQUENCE-NOTES.md

Death-sequence camera — findings (2026-07-09)

Pilot report (networked mission one, arena, Mad Cat): at death the bridge render shows the inside of the escape pod instead of the authentic sequence (trainer video: the dying pilot never sees the pod interior — the view rides to the blue-swirly translocation portal, the new mech steps out of the portal onto the field; the pod eject is a third-party visual only).

Reference capture: captures/netdeath-20260708.fifodump (4.5 MB, complete networked mission incl. the death and mission-end fade; taken 2026-07-08 UTC-night). Probes: probes/deathcam_probe.py, probes/viewflush_probe.py (run with py -3.13; they replay the capture into a headless VirtualBoard).

What the wire actually says

• The camera DCS chain never leaves the wreck. Chain eye stays ~7.8 m from the vehicle root through the whole death tail (never >100 m from it anywhere in 18,477 frames). So the fp_cam <100 m chain-sanity guard in live_bridge.py is NOT the culprit, and the transit is NOT a camera-chain move.
• Type-3 (view) flushes carry projection + fog only, no camera pose: floats [0..8] frustum edges, [9] ≈1.73 FOV scale, [10..11] = 832×512, [12]/[13] = hither/yon (0.25/1300 in gameplay), [18]/[19] = fog near/far, [20..22] = fog RGB. Only 65 flushes in the whole mission — they fire on change, not per frame.
• The mission-end fade is on the wire and already renders: ~22 flushes sweeping fog near/far from (193, 1205) down to (0.01, 0.05) with RGB fading to black — the reverse of the mission-start black hold.
• At death the 0x1f articulation batches switch to driving nodes anchored at the world origin (0, 1, 0) — the portal diorama animating — while the mech's own nodes stop updating. This is the clearest wire signature that the death sequence is active.

Hypothesis (matches the BT411 decomp)

BTPOVStartEndRenderable (game source) is constructed with BOTH dplMainZone and dplDeathZone. The authentic transit is a view/zone re-parent: the game moves the pilot's dpl_VIEW into the death zone, whose own camera root does the ride (death site → portal at origin → dropzone). Our bridge only follows the main-zone camera chain, so it stays at the wreck — with the escape-pod geometry spawned around it.

Reconciliation with the EARLIER respawn-death capture

The 2026-07-09 analysis of netdeath_snap.fifodump (~9MB, the earlier networked death WITH respawn; see weapon-visuals memory + death_strip.py) found the chain camera DOES transit: death site → (0, 10, 0) at the portal during the black hold → dropzone for the fade-in. Two death variants:

• Respawn death (lives remain): chain camera rides to the portal. The fp_cam <100 m from vehicle sanity guard REJECTS exactly this ride → falls back to the wreck → pilot sees pod/shroud geometry. For this variant the guard IS the bug: relax it once a mission is established (e.g. keep the guard only until the first accepted lock, or accept large excursions when the chain eye moves CONTINUOUSLY frame-to-frame).
• Mission-end death (tonight's capture): no transit at all — fog fade at the wreck, mission over. The wreck-side view may be authentic here; compare period footage of an end-of-mission death before changing it.

Next steps

1. Find the death-zone view root on the wire: at the death frame, diff the node topology (nest/link records) for a second camera-like chain, and check which display list the portal diorama nodes hang from.
2. Bridge fix: detect death-sequence-active (origin-anchored 0x1f activity + fog fade + the known w3/w4 flips) → release fp_cam and follow the death-zone chain (or, worst case, synthesize the ride: ease the eye from the wreck to the portal diorama at origin).
3. Note: this capture's death was at mission end (no respawn) — capture a MID-mission death (lives remaining) to see the full portal ride + new-mech reveal before calling the fix authentic. Compare against the pilot's VHS stills (7-frame sequence, matched 2026-07-08).