From 9abc839a4321c00524a6aea6ab49e492cb791652 Mon Sep 17 00:00:00 2001 From: arcattack Date: Thu, 9 Jul 2026 20:35:56 -0500 Subject: [PATCH] =?UTF-8?q?KB:=20archive-check=20verdict=20=E2=80=94=20no?= =?UTF-8?q?=20whirlwind/warp=20recovery=20asset=20in=20REL410?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- context/multiplayer.md | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/context/multiplayer.md b/context/multiplayer.md index 388a76a..dbe8c74 100644 --- a/context/multiplayer.md +++ b/context/multiplayer.md @@ -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,