# 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).