From 6cd5f0b9400d3b392ff83cedda6f90b1a6faece9 Mon Sep 17 00:00:00 2001 From: arcattack Date: Thu, 9 Jul 2026 21:15:48 -0500 Subject: [PATCH] =?UTF-8?q?KB=20CORRECTION:=20the=20blue=20whirlwind=20IS?= =?UTF-8?q?=20in=20the=20game=20=E2=80=94=20the=20translocation=20sphere?= =?UTF-8?q?=20(tsphere.bgf)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- context/multiplayer.md | 61 +++++++++++++++++++++--------------------- 1 file changed, 31 insertions(+), 30 deletions(-) diff --git a/context/multiplayer.md b/context/multiplayer.md index 09e4187..b2ba466 100644 --- a/context/multiplayer.md +++ b/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