vwemirror/BT412
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

KB: archive-check verdict — no whirlwind/warp recovery asset in REL410

Browse Source 
Searched the full pod install (nick-games/tesla4pod_extracted REL410/BT;
BTL4.RES byte-identical to ours) and the whole nick-games archive: no
whirl/warp/tunnel/vortex asset by filename or RES resource name, no such
psfx in BTDPL.INI. The decomp drop path (DropZoneReply FUN_004bffd0) fires
no effect — only Mech::Reset + the level-2 "translocated" cockpit alarm.
BTPLAYER source is absent from all archives (binary-only). RP411 analog
uses InitialStasisFlag (sim gate, no visual). Verdict: the pod build's
respawn is mech-redrop + translocated alarm; the "blue whirlwind" is not
a shipped REL410 asset.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
arcattack
2026-07-09 20:35:56 -05:00
co-authored by Claude Opus 4.8
parent 83b3f31957
commit 9abc839a43
1 changed files with 18 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
context/multiplayer.md
+18 -4
View File
@@ -199,10 +199,24 @@ 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. The whirlwind/recovery VISUAL remains unfound: no
whirlwind/tornado/vortex-named asset in BTL4.RES (ModelList/VideoModel/GameModel/Animation
sweeps) and no vortex-like .PFX; still open. Mech::Reset (@0049fb74) full subsystem-reset
sweep is still a bring-up TODO.
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.**
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
on the wreck rewrites the alarm to 4/3, un-latching → the death transition RE-RAN (double kill,