KB CORRECTION: the blue whirlwind IS in the game — the translocation sphere (tsphere.bgf)

My earlier 'not a shipped asset' verdict was wrong. The effect is POVTranslocateRenderable
(engine) / BTTranslocationRenderable (our port), which loads tsphere.bgf BY FILENAME (not via
the RES table, so every resource-name search missed it) and runs a collapse-on-death /
expand-on-respawn sphere keyed on the SimulationState dial. Wiring already exists in
btl4vid.cpp; the renderable is a no-op stub in btstubs.cpp. That's why it never shows.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

context/multiplayer.md

@@ -199,36 +199,37 @@ transition, HUD all landed since P6): console egg → mesh → RunningMission on
    own resource-type table) — `*int.scp` are internal-AUDIO scripts, NOT per-mech intro scripts;
    and `adrop` (id 1994) is a **type-14 MakeMessageStream** = the map's four DropZone make
    records (0xE0 each: classID 3, origin, facing, name "two"/"three"/…), i.e. the respawn
-   infrastructure, not a whirlwind. **Whirlwind/recovery VISUAL — CONCLUSIVELY NOT IN THE SHIPPED
-   ASSETS (archive-checked 2026-07-09).** Searched the full pod install
-   `nick-games/tesla4pod_extracted/.../REL410/BT` (its `BTL4.RES` is byte-identical to ours) +
-   the whole nick-games archive: NO file or RES resource named whirl/warp/tunnel/vortex/swirl/
-   cyclone/twist anywhere; the `BTDPL.INI` `[effects_to_load]` psfx list is only damage/boom/smoke/
-   shockwave/flush (no whirlwind); the only "arrival"-ish assets are 8 Avatar-specific `avarr*`
-   animations (type 16) — chassis-specific, not a universal respawn effect. Decisive: the DECOMP of
-   the drop path fires NO effect — `DropZoneReply` (FUN_004bffd0) calls only `Mech::Reset`
-   (@0049fb74, place at drop origin) + `Set_Alarm_Level(this+0x2c, 2)` = the **"translocated"
-   cockpit alarm** (level 2, already wired in our DropZoneReplyMessageHandler); `CreatePlayerVehicle`
-   just makes the mech. RP411's analog (`RPPlayer::CreatePlayerVehicle`) spawns with
-   `VTV::InitialStasisFlag` (materialize-in-stasis, a sim-state gate — no visual). The BTPLAYER
-   source is ABSENT from all three source archives (410src / elsewhen RP411 / game/original), so the
-   respawn logic lives only in the binary — and the binary's drop path has no effect spawn. **Verdict:
-   the REL410 pod build's respawn = mech re-dropped at the zone + translocated alarm; the "blue
-   whirlwind" is not a shipped REL410 asset (likely a memory of the earlier DOS / Virtual World
-   arcade BattleTech). No further hunt warranted unless a different asset pack surfaces.**
-   DEEPER SWEEP (2026-07-09, all negative): (a) `BTL4OPT.EXE` string table — no
-   whirl/warp/tunnel/vortex/tornado/swirl/cyclone; the only "recovery" string is
-   `ShortRecoveryTime` = a **Generator** (power subsystem) electrical attribute, unrelated to
-   respawn. (b) Class registry `BTREG.CPP` (in the 410src archive) registers ONLY
-   Mech/Projectile/Missile/BTPlayer/BTTeam/CameraDirector — no recovery/tornado/dropship class.
-   (c) Effect system: `DPLIndependantEffect` numbers ≥1000 map to `psfx[n-1000]` (the 0–23
-   damage/boom/smoke/shockwave PFX); <100 are the same PFX — none is a whirlwind. (d) Camera
-   system (`CAMINST.CPP`) = static positioned cameras (tran/quat/yaw-pitch clamps), no death/
-   recovery cam. (e) Build manifest `BTL4.BLD`/`.ORG`/`FILELIST` + mission ops `BTL4.OPS` —
-   locations + dropzone lists only. Benign near-misses ruled out: `NoReturn` GameModel (id 330)
-   decodes to `{500,500,0, 1,1,1,0}` = the 500×500 arena **out-of-bounds boundary**; `swiftwnd`
-   = the Swiftwind scout **vehicle** (btravine map); `wndsfx01-03` = ambient **wind AUDIO**
-   (type 3); `BLUEBEAM.BGF` = the **PPC weapon** beam geometry.
+   infrastructure. **⚠ CORRECTION (2026-07-09): the "blue whirlwind" IS in the game — it is the
+   TRANSLOCATION SPHERE, and our port STUBS it.** (My earlier "not a shipped asset" verdict was
+   WRONG; it was wrong because I searched only RES resource NAMES + the keyword "whirlwind" — but the
+   effect (a) loads `tsphere.bgf` by FILENAME via `d3d_OBJECT::LoadObject`, NOT through the RES table,
+   and (b) is called "translocate," not "whirlwind.") The mechanism, fully recovered:
+   - **Asset:** `content/VIDEO/GEO/TSPHERE.BGF` (2085-byte low-poly sphere; also in the pod install
+     REL410/BT + RP + VWETEST/CYCLE). The exe string table has `tsphere.bgf` / `tsphere`.
+   - **Engine class:** `POVTranslocateRenderable` (L4VIDRND.cpp:1749 / .h:638) — a `VideoRenderable`
+     (Watcher) that loads `tsphere.bgf` and runs a state machine keyed on a `StateIndicator` "effect
+     trigger" (the player's `SimulationState` dial) vs a control state: `IdleState` → (trigger hits
+     control state) `InitialCollapseState` (sphere scales `COLLAPSE_START_SCALE 100`→1 over
+     `COLLAPSE_TIME 1.3s`, then `SetIsDead(true)`) → `WaitForReincarnateState` (jitters via cos/sin
+     `TRANSLATE_LIMIT 2.0`) → (trigger leaves control state = respawn) `ExpandRevealState` (scales
+     1→`EXPAND_END_SCALE 150` over `EXPAND_TIME 1.0s`, `SetIsDead(false)`) → IdleState. Rotates
+     throughout (`ROTATE_RATE`). I.e. the sphere COLLAPSES onto the mech at death and EXPANDS to
+     reveal the reborn mech at respawn — exactly the "blue warp that comes to get you & respawns you."
+   - **Wiring (already present in our port!):** `btl4vid.cpp` `MakeEntityRenderables` for a
+     `BTPlayerClassID` REPLICANT creates `new BTTranslocationRenderable(entity, Watcher, GetMainView(),
+     sim_state=GetAttributePointer(SimulationState), drop_zone=GetAttributePointer("DropZoneLocation"),
+     1)` (FUN_00458d2c, alloc 0x40, control state 1); our own POV instead gets `BTPOVStartEndRenderable`
+     (the mission fade in/out). So peers watch each other's translocation sphere; your own death is a
+     POV fade.
+   - **Why unseen:** `BTTranslocationRenderable` (declared btl4vid.hpp:320) is a NO-OP STUB in
+     `btstubs.cpp:365` (`: BTRenderableBase(entity) {}`). Porting it = reimplement over the engine's
+     `POVTranslocateRenderable` (its `d3d_OBJECT::LoadObject("tsphere.bgf")` + Execute state machine are
+     already in L4VIDRND.cpp; the DPL instance/DCS calls are commented — render via our d3d_OBJECT +
+     Scene renderable path, same infra as the beam/reticle renderables). TODO — task #52 whirlwind visual.
+   NOTE the respawn-cycle SIM path is separate + done: `DropZoneReply` (FUN_004bffd0) → `Mech::Reset`
+   (@0049fb74) + the level-2 "translocated" cockpit alarm; `CreatePlayerVehicle` (FUN_004bfcac,
+   disassembled — make+link only, matches RP analog). The sphere is a pure RENDER-side watcher on the
+   SimulationState dial, independent of that sim path.
    Mech::Reset (@0049fb74) full subsystem-reset sweep is still a bring-up TODO.
    **Three respawn bugs found + fixed on the way (all [T2], 2-node force-damage verified):**
    (i) **death-latch un-latch** — `IsMechDestroyed` tested `graphicAlarm>=9` alone; a later leg hit