The respawn glitches (2 mechs, on-fire respawn, camera-inside, can't-control,
wreck-never-disappears) all traced to one architectural divergence: our respawn
SEVERED playerVehicle on death and CREATED a new mech, leaving the old as a
permanent wreck and building a duplicate viewpoint whose old render tree was
never torn down.
The authentic engine (FUN_0049fb74 + RPPlayer) REUSES the same mech entity: on
respawn Mech::Reset heals it and moves it in place. Implemented faithfully,
adapted to our layout (the 1995 raw offsets map to different 2007 engine fields,
so reset the equivalent named members, not the offsets):
- Mech::Reset (real, was a reposition-only stub): reposition + kill dead-reckon
(projectedOrigin/projectedVelocity/updateVelocity + our relocated gait
accumulators) so the replicant stops lerping to the death spot; clear the
death latch (movementMode=1, graphicAlarm=0); Heal every damage zone
(new Mech__DamageZone::Heal: full structure, intact skin); DeathReset
(vtable+0x28) every subsystem; ForceUpdate to broadcast.
- btplayer.cpp: VehicleDead no longer severs playerVehicle; the respawn re-post
gates on the mech still being dead; DropZoneReply resets the EXISTING mech in
place (heal+move) instead of creating a new one, then fires the warp. Warp
moved to the shared placement (initial drop-in + respawn).
Verified 2-node: mech entity ID stays 3:22 across 3 deaths (reused, not a new
3:32); each Reset logs alive=1, 20 zones healed, 33 subsystems reset; A sees ONE
mech (no wreck+new pair). Warp fires each respawn.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
