The 'mysterious flag pair' gating every master-only registration was never
BT-specific state waiting on unreconstructed stream builders. It is the
Entity base itself: InstanceBits=2 puts the instance field at mask 0xC
(ReplicantInstance=4), DynamicBit=8 makes DynamicFlag 0x100 -- so the
binary's (flags & 0xC)==0 && (flags & 0x100)!=0 reads 'a master-instance
dynamic entity', spelled MasterInstance + DynamicFlag in the 1995 headers.
Mover::DefaultFlags = DynamicFlag|MasterInstance, ENTITY.CPP:978 seeds
simulationFlags from the MakeMessage's instanceFlags, and our spawn recipe
has passed Mech::DefaultFlags since the boot ladder -- the authentic gate
was live all along. The BT411 donor's 'MasterHeatSinkFlag' name was a
fabrication that made an engine constant look like a missing subsystem
feature (donor drift #12).
Eleven sites flip from the GetInstance() mirror to the binary pair: the
heat-family registrations (x4), powersub (x3), gyro, hud, myomers,
emitter, and the Torso ctor's master/copy selection (@004b6b0c verbatim,
isDamagedCopy set in both branches). The MECHWEAP score-post and MECH view
gates are different families and stay as they are.
Statically proven (DefaultFlags carries both bits) and mission-soaked
clean. No [T2] divergence markers remain in the tree.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Myomers::MyomersSimulation (@004b8d18) reconstructed, five blocks in the
binary's order, and it answers a question left open since 5.3.94:
runSpeedMax (+0x7a0) IS WRITTEN BY THE MYOMERS. Each myomer's
RegisterMaxOutput (@004b8ef0) raises the mech's run-cycle cap to its
full-throttle AvailableOutput -- so the mech's true top speed is a
property of its MUSCLE ASSEMBLY, and it degrades live as heat crosses the
degradation band and as the myomer's own zone accumulates damage. The
1e9 ctor sentinel now stands only until the first myomer registers.
The drive computation (@004b8ac0): base = the mech base speed
(reverseStrideLength, mech+0x34C) scaled by the gear ratio -- input voltage
over the RECOMMENDED gear -- with a quadratic thermal bleed across the
degradation band, zero past failure, and the subsystem's wear taken off the
top. speedEffect republishes per frame as a 0..1 fraction of full drive:
input clamped to the SELECTED gear then the top gear, through
AvailableOutput, normalised by the base speed.
AND THE MUSCLES HEAL: while a myomer has NO VOLTAGE and its zone is not
destroyed, it hands its own zone a NEGATIVE explosive tick (-0.011,
0xbc343958) -- unloaded muscle knits itself back together. The donor's
history records this block as the fix for "torso twist dead after respawn"
(the Torso mirrors this subsystem's electrical level; with the base machine
never running, a myomer that lost power in the death window sat at
NoVoltage forever) -- and our runs respawn now, so the fix is live where it
matters.
Registered on the master (the sibling gate); the base electrical machine
runs FIRST and unconditionally, per the donor's hard-learned ordering note.
Not carried over: the port's BT_FORCE_SEEK / repair-test bench scaffolding.
Live run clean; the gait's speed sequence is unchanged (7.31972, 26.6726,
...) -- the muscle cap sits above the demanded 26.9 on a healthy Mad Cat,
exactly as it should.
Stub census: 18 across 12 files.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Under the documented rig (launch_pod.ps1 with the GL bridge up) the 'couldn't
load object' count went to ZERO. .BGF loading was never a reconstruction
problem, only a missing bridge.
What blocks now is a series of authored AttributeWatchers: BTL4.RES binds
them BY NAME and the engine Fails outright on any that does not resolve, so
each is a name our subsystems must publish. Five rungs climbed, each
run-verified: UnstablePercentage, SpeedEffect (Myomers table), AnimationState
+ CollisionState/CollisionNormal + ReduceButton (Mech), and the full Torso
table (all six authentic names mapped onto existing members).
The method that makes this cheap is banked: the shipped binary's string pool
carries each class's attribute names CONTIGUOUSLY in ID ORDER after the class
name, and in every case so far our member declarations sit in the same order
-- which confirms the layout and lets ids be pinned rather than guessed.
Intersecting those names with BTL4.RES gives the exact work list.
A THIRD miswired SharedData found on the way: Myomers carried Subsystem's
tables where it derives from PoweredSubsystem, the same defect as
MissileLauncher (5.3.33). Worth a sweep across every subsystem.
Staged member TYPES are provisional and documented as such: AttributeWatcherOf
reads *(T*)attributePointer and the instantiation comes from the resource,
which the string pool does not reveal. Nothing drives them yet, so settle the
types with the models that write them.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5