e40abc86ea5c392b6f97931cb585fc2d3c835e97
98
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CydandClaude Fable 5
|
e40abc86ea |
BT410 5.3.100: the collision economy -- armor is never touched by a crash, and the wall stops one-shotting the mech
The 5.3.99 open question is closed the way the binary closes it, not with a
divisor. Two pieces:
THE DIVERT (damage hub @0x4a0368): type-0 Collision damage NEVER reaches the
armor zones. Our handler was routing wall crashes through the same
cylinder-lottery path as enemy fire, which is why 24k-point kinetic numbers
one-shot vital zones. The binary short-circuits them into
THE DISTRIBUTOR (@0049ffcc): the manual's "collision damage" technician
setting. Gated on the owning player's advanced-damage flag; priced against
a 100 km/h reference impact --
scale = (2000 / mass) / (100 km/h)^2 / (1 - elasticity^2)
amount = raw * scale; under 0.5 the tap is FREE
n = Round(amount * 2) sub-hits of amount/n each
-- and applied as rattle crits to random INTERNAL subsystems (HeatSink /
Gyroscope / Torso families only), drawn by cumulative
collisionCriticalHitWeight against a [0,1) roll. An un-won roll lands
nowhere; the binary does not normalize the weights, so neither do we.
LIVE, same arena mission as 5.3.99's four-death run:
[colldmg] rattle 0.677919 pts in 1 sub-hits (scale=3.6e-05)
[crash] BLOCK dmg=18831.1 iv2=711.428 KNOCKDOWN
[crash] BLOCK dmg=331.878 iv2=12.549 (x6, pressed against a wall)
deaths: ZERO (was four)
An 18.8k-point crash becomes 0.68 points of internal rattle; the low-speed
wall grind prices as free taps under the 0.5 floor; the knockdown stagger
still fires above the velocity threshold. Walls now block, stagger, and
rattle -- they no longer execute.
Plumbing: MechSubsystem::CollisionCritWeight() accessor (the weight was
already streamed at +0x10C, protected), Mech::DistributeCollisionDamage
declared, random.hpp include.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
4ace2571d9 |
BT410 5.3.99: walls are real -- frame rejection, crash self-damage, the knockdown stagger, and a pricing question left honestly open
The response half of the ground model (binary @4aa6cf-4aab0b), after the
5.3.98 snap:
WALLS BLOCK BY FULL FRAME REJECTION, never slide or climb: any blocking
contact restores the start-of-frame position and zeroes the velocity.
THE CRASH HURTS: the accumulated collision Damage is dispatched at our own
mech, zone -1 -- through the same cylinder lottery as enemy fire -- which
is what makes wall-grinding self-limiting in the original.
A HARD HIT STAGGERS: past the binary's |v|^2 > 40 threshold (@0x4ab184),
both gait channels bind the bump clip (slot 0x20, the reason the clip
array outgrows the name table) and recover to Standing at its end. Both
channels together, per the donor's foot-slip finding: staggering only the
leg channel desyncs the two cycles permanently.
LIVE, one arena run, no fault -- and the run turned into an unplanned
full-system exercise: 8 wall contacts (three at knockdown force, iv2
745-932; one low-speed bump correctly blocked without stagger), and the
self-damage cascaded through vital zones to MECH KILL, pilot notification,
respawn HEAL-and-place, four times over. The death and respawn machinery
all held.
OPEN, stated rather than tuned away: THE PRICE IS TOO HOT. Wall crashes
land 14k-24k damage points against a game where a PPC is ~12 and an upper
torso carries ~124 -- a hard crash one-shots vital zones through the
lottery. BT411's economy audit hit the identical symptom ("tapped a wall
and died instantly") and traced part of it to compounded StaticBounce
reflections across multi-solid frames. The fix lives in the
Mech::ProcessCollision override (with the crushable-icon sentinel and the
gyro crunch), which is the NEXT increment -- the pricing stays as the
engine computes it until that override is reconstructed from the binary,
because guessing a divisor would be tuning, not archaeology. The [crash]
log line prints amount + iv2 under BT_MECH_LOG as the audit trail.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
ed04ba2d4e |
BT410 5.3.98: the ground snap -- the mech walks the arena's actual terrain, and there is no gravity
The probe half of the master performance's ground model (binary
@4aa630-4aa6cc, via BT411's raw-asm decode), placed after Simulate's position
integration:
place the collision volume; drop a probe from the volume's authored bottom
(origin.y + collisionTemplate->minY); ask the zone's box tree what surface
lies under it (BoundingBoxTreeNode::FindBoundingBoxUnder); and if the query
hits (h > 1e-4), put the origin ON that surface exactly --
origin.y -= (h - lift).
The design is worth stating because it is not the obvious one: THERE IS NO
GRAVITY ANYWHERE IN THE MECH. Placement is absolute each frame. Walking
up-slope rides the lift window (an implicit step allowance), walking off a
roof drops instantly, and a probe MISS holds Y -- so a falling-through-the-
world runaway is structurally impossible rather than merely guarded against.
The engine side needed NOTHING reconstructed: Mover's own ctor already
builds collisionTemplate/collisionVolume from the model's BoxedSolidStream
resource and the zone tree was live all along. One include (boxsolid.hpp --
mover.hpp only forward-declares BoxedSolid, so the extents were an
incomplete type).
LIVE, arena run, no fault -- the y track tells the story by itself:
y = 20 -> 11.747 -> 10 -> 10 -> 0 -> 19.4049 -> 0
Spawn deck, down a ramp (caught mid-slope), an intermediate level, the arena
floor, up onto a structure, and off it. Every previous run had y pinned at
its spawn constant for the whole mission.
Deferred with the collision increment: frame rejection on blocking hits, the
crushable-icon sentinel, the crash clip (SetLegAnimation 0x20) on hard
impacts, and the gyro crunch feed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
aadc372307 |
BT410 5.3.97: combat damage now limps the mech -- and a fresh leg hit can no longer one-shot it
Two corrections to the damage model's leg branch, both read straight off the binary's own control flow (part_012.c:6900-6945, the _DAT_0049c99c/9a0 compares), closing a delta the notes had carried as staged: THE KILL GATE WAS WRONG. Our reconstruction felled the mech whenever a leg zone reached 1.0. The binary only does that when the mech is ALREADY LIMPING (mode 3/4): a first leg hit -- even one that takes the zone straight to 1.0 -- produces a LIMP, and the fall needs a second blow to land while the gait is already gimped. Two-stage leg death, exactly the BattleTech flavour, and measurably more forgiving than what we shipped. THE ALARM WAS RIGHT. The limp/kill signal writes AlarmIndicator::SetLevel at mech+0x2c -- the statusAlarm, exactly as our MECHDMG had it (levels 3/4 limp, 9 down). Confirmed rather than changed. AND THE MISSING LINK STAGED: nothing promoted statusAlarm 3/4 into the movement mode the gait keys on. The binary's own damage code READS mode 3/4 to decide "already limping", so the promotion demonstrably exists -- its writer is the master performance (mech4 @004a9b5c, the function Ghidra never decompiled). Until that lands, Simulate promotes status 3/4 -> simulation state 3/4 (guarded so a death mode is never overwritten), marked STAGED with the evidence. The chain is now END TO END: enemy fire -> cylinder table -> leg zone crosses 0.5 -> statusAlarm 3/4 -> movement mode -> the limp advancers replace the normal gait -> the drag leg shows on the wire -> the demand clamp caps the throttle. Live regression: the normal mission's speed sequence is bit-identical a third time (7.31972, 26.6726, ...); the promotion block is inert until real leg damage arrives. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
7c2363d89f |
BT410 5.3.96: the LIMP is real -- all twelve mech2 functions reconstructed, and the drag leg shows up on the wire
The "gimp" family had two conflicting donor readings -- limp vs jump-jet --
flagged in 5.3.94 rather than guessed at. The binary settles it: LIMP. The
mode test in every gimp function is mech+0x40 in {3,4}, the same values the
damage model documents as "limp gait graphic (left 3 / right 4)"; there is no
jump-jet control anywhere in the pod cockpit; and the donor's port routing
("graphicAlarm 3/4") was the same field under a different name. Its
"run-jump clip" mech3 annotations were the misreading that started the murk.
RECONSTRUCTED, completing all 12 of mech2's census functions:
GimpLegClipFinished @004a7970 GimpBodyClipFinished @004a6344
AdvanceLegAnimationGimp @004a71f4 AdvanceBodyAnimationGimp @004a5bf8
+ the limp branch atop both normal *ClipFinished
+ the limp pick in Simulate (replaces the normal advancers while limping)
HOW A LIMP WORKS, now from the bytes rather than description:
It replaces ONE stride. Limping left, the right stride (6) hands off to
the left limp figure (0x16 -> the self-cycling 0x18) while the other leg
keeps its normal clips. The asymmetry IS the limp.
Both machines CLAMP THEIR DEMAND while in a cycle -- the leg machine
writes the mapper's own speedDemand cell down to the damaged side's cap
(new MechControlsMapper::SetSpeedDemand, matching the binary's direct
mapper+0x128 write), the body machine clamps bodyTargetSpeed, both floor
at zero. A limping mech cannot command more than its figure carries, nor
reverse out of a forward cycle.
The limp advancers keep states 0x16-0x1b LIVE -- the normal advancers
treat those as the reset group, which is exactly why the limp flavours
must be selected while limping or the figure is neutralized mid-cycle.
No death latch, no wind-down: the movement modes are exclusive.
ALSO EXPLAINED IN PASSING: Ghidra's 3760-byte FUN_004a6344 -- the census's
largest function -- is really THREE functions. The two normal ClipFinished
callbacks (@004a6928/@004a6d8c) are reached only via data pointers, so the
decompiler folded them into the gimp-body machine's extent.
All movement-mode reads route through Mech::MovementMode() (mech+0x40 == the
simulation state), which honours a BT_FORCE_LIMP=3|4 dev hook so the gait
could be verified before the damage model's limp hook exists.
VERIFIED, two runs on the rig:
NO-REGRESSION: the normal mission's speed sequence is BIT-IDENTICAL to
5.3.95 (7.31972, 26.6726, 22.1601, ...). The branch costs nothing.
FORCED LEFT LIMP (new pod_render_limp.conf): the mapper still demands
26.9; the hull lurches at 10-23. And on the wire the healthy walk's tight
pose-count pairs (650/649 ... 434/421) BREAK to a 3x asymmetry -- the
drag-leg joint at 18 poses against its partner's 55. The limp is visible
in the data exactly the way it will be visible on screen.
STILL OPEN in this family: the damage hook (leg zone >= 0.5 -> mode 3/4, a
MECHDMG increment -- nothing sets the mode in real play yet), and
IntegrateMotion's remaining pieces.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
c578a9b790 |
BT410 5.3.95: the stride becomes the speed -- and the hull now breathes with the gait
Half of IntegrateMotion's job, taken now because two findings made it safe:
THE GAIT SLEW RATE IS THE AUTHORED ACCELERATION. The binary's ctor sets
forwardCycleRate, gimpCycleRate and groundCycleRate all from the model's
maxAcceleration (rec+0x44 -- 30 for the Mad Cat) and airborneCycleRate from
superStopAcceleration. That closes both of yesterday's unsourced-rate
worries at once: the ctor default of 1.0 (which would have taken ~27 seconds
to reach speed) is retired, and replacing the explicit acceleration model
with the stride rate preserves drive feel EXACTLY -- same slew rate, same
demand, different (authentic) path for the value to travel.
SO: Simulate now takes currentBodySpeed = bodyStride / dt, the binary's own
relationship (IntegrateMotion @004ab1c8: local velocity z = -distance/dt).
The old acceleration model survives only as a [T3] fallback for a model with
no gait clips at all, so unverified fleet mechs stay drivable.
LIVE CURVE, arena run, no fault:
spd = 7.32 stepping off (stand->walk clip)
spd = 26.67 22.16 27.31 30.54 ... the run cycle around the demanded 26.9
The old model pinned spd at exactly 26.9022 every frame. Now the mech steps
off slow and its hull speed oscillates within each stride -- heel-strike vs
mid-swing. Cadence in the motion is not noise; it is the point. The mech is
carried by its animation, which is what "the gait IS the locomotion" meant in
the 1995 design.
Also queued a correction from the raw decomp: IntegrateMotion's replicant
branch writes +0x598 with a VECTOR op, so motionEventName is likely a Point3D
rather than the CString the BT411 member map suggested -- flagged in the
sidecar for the dead-reckon increment rather than churned now.
Still staged from IntegrateMotion: the airborne pick, the dead-reckon fold,
the orientation integration, the turn-in-place dispatcher.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
9a74f2aa09 |
BT410 5.3.94: THE LEGS WALK -- AdvanceLeg/BodyAnimation live, 16 of 22 joints animating in paired strides
The last link is in. AdvanceLegAnimation (@004a5028) and AdvanceBodyAnimation
(@004a5678) reconstructed and wired into Mech::Simulate, and the first live
run put a walking gait on the wire:
before 22 handles, 1 animating (the vehicle root)
after 22 handles, 16 animating, ZERO 2-float records
root 812 poses; six PAIRS at 650/649, 599/596, 563/563,
542/540, 531/529, 434/421; three slow joints at 25
Six left/right pose-count pairs is six joints per leg cycling in alternating
strides -- the symmetry is itself evidence that the handed clip alternation
(Right, Left, Right, each clip one stride) is running correctly. Chain, end
to end, every stage previously verified in isolation and now live together:
mapper demand -> AdvanceLegAnimation (state machine) -> SelectSequence
-> SequenceController::Advance (keyframes -> Joint::SetHinge/SetRotation)
-> BTL4HingeRenderable (5.3.88 matrix transport) -> 12-float flush
-> render bridge applies. Mission drove itself clean, no fault.
RECONSTRUCTED FROM THE RAW DECOMP, NOT THE DONOR -- and the sidecar says why:
BT411's versions carry port-era replicant accommodations (its mapper cell
does not replicate; the binary's does) and a turn-in-place dispatcher it
relocated INTO the leg machine from mech4's master performance. None of that
is 1995 code. Here the leg version reads the mapper unconditionally, exactly
as decompiled, and state 4's ARMING stays where the binary has it -- in
mech4, not yet reconstructed.
THE TWO CHANNELS DIFFER MORE THAN THEIR ClipFinished TWINS DO, all
binary-verified: the leg version has the wind-down block, the turn-in-place
case and the "Standing Not Supported" guard; the body version has none of
those, its case 4 sits in the plain-advance group, and move_joints reaches
every body Advance AND its reset's Reset -- the caller decides whether the
body channel poses joints or only measures stride. Wired accordingly: leg
poses, body measures (move_joints 0), body distance dropped at a seam marked
STAGED -- consuming it as the forward step is IntegrateMotion's job (mech4).
Also faithful: case 0 FALLS THROUGH so a freshly armed clip advances the same
frame it was selected; the plain group's Standing guard is unreachable via
that fall-through and catches direct entry only; each cycle plays its clip at
cycle/stride of the authored rate (a slow walk IS the walk clip played slow);
and the reverse cycle's caps are all negative with the advance ratio folded
positive at the end.
UNSOURCED, named in the sidecar rather than invented: idleStrideScale
(+0x5ac, defaults 1) and runSpeedMax (+0x7a0, the run cycle's upward cap --
LoadLocomotionClips does not set it; defaulted huge so it never binds until
its real writer is found). ForceUpdate(8) is a STAGED no-op pending the
replication emitter.
Still deferred: the airborne Advance* flavours (@004a5bf8/@004a71f4, jump
jets) and the Gimp*ClipFinished limp machines.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
a87c49c158 |
BT410 5.3.93: the clip loader runs LIVE -- the Mad Cat measures itself, and a 1995 copy-paste bug ships again on purpose
LoadLocomotionClips + ResolveAnimationClip + MeasureClipStride + LoadClipSlot
reconstructed and WIRED into the ctor's GameModel block. animationClips[] is
no longer an empty array: every gait slot resolves by the model's animation
prefix, and the locomotion constants are now MEASURED from the authored clips
instead of asserted as bring-up defaults. First live run, arena mission:
[mech] clips 'mad': standSpeed=5.23 walkStride=18.51 revStride=56.05
revSpeedMax=26.26 gimpSpeedMax=-4.23 gimpStride=-20.26
limpSet=1
That line carries three verifications at once: the prefix printing as text
proves the Mech__ModelResource layout is right at +0x40; the reverse figures
come out NEGATIVE exactly as the transition machines expect; and the mission
ran clean to live driving afterwards (703 log lines, no fault).
DRIVING FEEL CHANGED, deliberately: speedDemand at 0.6 throttle went 14.4 ->
26.9, because the placeholder top speed (30) gave way to the measured 56.05.
The Mad Cat is simply faster than the bring-up guess. Authenticity arriving,
not a regression.
TWO BINARY BEHAVIOURS REPRODUCED ON PURPOSE, both documented at the function:
The speed caps read keyframeData[keyframeCount] -- one entry PAST the last
frame. Fencepost is the binary's own (0x690 + 8 + [0x670]*0xc); whether the
authored table has count+1 entries is unestablished, but the clips were
authored against this read and the measured values are sane.
The reverse-cycle stride is computed from STALE locals. The decomp is
unambiguous: bbr and bbl are both measured into local_8/local_c, and the
divide's second terms come from local_10/local_14 -- still holding the
RUN-LEFT figures. gimpStrideLength = -((bbl + rrl_stale)/(...)). A 1995
copy-paste bug, shipped in every pod for thirty years, reproduced here with
a comment pointing at the wwr/wwl block that shows the intended pattern.
(And an earlier scare resolved: the negation IS in the binary -- the very
next instruction is 0x350 = -0x350. My first decomp window cut one line
short and briefly indicted the donor's minus sign.)
ONE DELIBERATE DIVERGENCE, tagged [T3]: the binary dereferences every resolve
result unguarded -- a model missing a mandatory clip crashes on load. Here a
miss stores NullResourceID (SelectSequence resolves it to an inert controller)
and the dependent measurement is skipped. Keeps the boot alive on unverified
clip sets; revisit when the fleet's models are known-good. Measurement binds
pass a NULL finished-callback (measurement parses, never plays -- the binary's
live pointers can never fire there).
Ctor additionally zero-initializes the whole gait channel -- globalTimeScale
defaulting to 1 specifically, because zero would silence every clip advance --
and fills the clip array with NullResourceID before the loader runs, so the
uninitialized-member class of bug (see 5.3.83) is closed here BEFORE the
consumers arrive.
MECH.HPP: the optional limp set carved out (hasGimpClips + 4 measured limp
figures + gyroRumbleTimer); reservedState 150 -> 140.
Next: the four Advance* entry points -- the last link before the legs move.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
64f99ffcc8 |
BT410 5.3.92a: reconcile two stale claims in MECH2.NOTES.md
The slot-map section added in 5.3.92 corrected two things the doc still asserted higher up: that gimpStrideLength is authored negative (the sign is applied at measurement) and that animationClips is sized AnimationCount (it is AnimationSlotCount, 0x21). Both now agree with the correction rather than leaving a reader to hit the stale version first. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
3629755d90 |
BT410 5.3.92: the gait slot map -- the clip array is bigger than the name table, and the "gimp" members are the REVERSE figures
Went to source animationClips[] and found two things: a bug in what 5.3.91 committed, and a naming trap that has already cost BT411 a shipped defect. THE BUG, MINE. I sized animationClips[AnimationCount] -- 0x1d, from the enum. Wrong. The name table stops at 0x1d but the ARRAY does not: slot 0x20 (mech+0x64c) is the bump/crash clip the mech binds on a hard wall impact. So the array is [AnimationSlotCount] = 0x21 and Set*Animation's Verify bounds against that instead. Sizing a real array off a name table that stops earlier reads fine and corrupts whatever sits next door; caught by reading the clip loader, not by the compiler. THE SLOT MAP, recovered from LoadLocomotionClips and now written down in full (suffix, meaning, and which measured constant each clip yields): 5 swr stand -> walk standSpeed 6/7 wwr/wwl forward walk CYCLE walkStrideLength = (s6+s7)/(d6+d7) 8/9 wsr/wsl walk -> stand 10/11 wrr/wrl walk -> run reverseSpeedMax 12/13 rrr/rrl run CYCLE reverseStrideLength 14/15 rwr/rwl run -> walk 16/17 sbr/sbl stand -> back gimpSpeedMax 18/19 bbr/bbl reverse CYCLE gimpStrideLength (NEGATED here) 20/21 bsr/bsl back -> stand 22/23 wgl/wgr walk -> limp gimpLeft/RightSpeedMax 24/25 ggr/ggl limp CYCLE gimpLeft/RightStrideLength 26/27 gsl/gsr limp -> stand 0x20 bmp bump / crash stagger THE TRAP: THE "gimp*" MEMBERS ARE THE REVERSE FIGURES, NOT THE LIMP ONES. gimpSpeedMax and gimpStrideLength are measured from sbr and bbr/bbl -- the reverse gait. The real limp has its own gimpLeft*/gimpRight* pair. This is the same bad naming that produced the states-16-19 misreading recorded in 5.3.91, and it has now caused the same error twice from two directions. Also settled: gimpStrideLength's negative sign is applied AT MEASUREMENT, not authored into the data -- which is where the fold in the transition machines comes from. And the limp clips are OPTIONAL: the loader probes for wgl and leaves hasGimpClips 0 with slots 22-27 unfilled if the model lacks it, so the deferred gimp branch must check that before routing into the limp machine. THE ENUM IS NOT THE SLOT MAP, and MECH.HPP now says so at the enum itself. The names are verbatim from the binary and authoritative AS NAMES, but slot 0x0e takes the run-to-walk clip while the table calls it RightReverseAnimation, and the forward walk alternates 6/7 rather than the pair the WalkForward names suggest. Read the slot map for "what does this play"; read the enum for "what did the original call this index". ATTRIBUTION NOTE: the four clip helpers (ResolveAnimationClip @004a7f50, MeasureClipStride @004a8054, LoadLocomotionClips @004a80d4, LoadLocomotionClipsExt @004a86c8) are exactly the four addresses the manifest lists under mech2.cpp that BT411 files under mech3. The manifest's attribution comes from the binary's own file tagging, so they belong here -- which also accounts for all 12 of mech2's functions. BT 51/51. Still nothing calls the gait. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
d8aea8d871 |
BT410 5.3.91: the gait transition machine -- two channels, one table, and a reverse cycle that has been misread twice
mech2.cpp exists. Six of its twelve functions are reconstructed: the two
Set*Animation binders, the two *Transition tails, and both *ClipFinished jump
tables (@0x4a69aa leg / @0x4a6e0a body). Compile-verified, BT 51/51, links
clean.
TWO CHANNELS, DELIBERATELY NEAR-DUPLICATE. A mech runs two clip channels over
the same states and the same clips; only the speed they consult differs:
LEG reads the LIVE mapper GetSpeedDemand() -- responds to the stick at once
BODY reads bodyTargetSpeed, a snapshot -- which is what lets a dead-reckoned
or networked mech walk with no controls mapper of its own
So LegClipFinished and BodyClipFinished are twins rather than one shared
routine, exactly as the binary has them. Kept that way on purpose: where the
two jump tables agree, a divergence in this file is a bug, and that mutual
check is worth more than the duplication costs.
EVERY CLIP IS ONE STRIDE, which is why every state is handed -- a walk is
Right, Left, Right, and each entry to and exit from a cycle has its own handed
pair so the mech always leaves on the correct foot. The 29-state enum is
VERBATIM from the 0x3c-stride name table at .data:0050cfe8, the table the
"Unsupported mech animation" assert indexes, so the names and their order are
the original's rather than inferred from behaviour.
THE COMMIT TEST. Both exits that leave a walk cycle test the demand AND the
current cycle speed slewed by one carryover:
if (demand < standSpeed && (cycle - rate*carryover) < standSpeed) -> stop
if (demand > walkStride && (cycle + rate*carryover) > walkStride) -> run
Requiring both is what stops a momentary flick of the stick yanking the mech
out of a stride it has already committed to. Drop either conjunct and you get
a mech that stutters between gaits on noisy input.
TWO THINGS THAT READ WRONG AND ARE NOT:
gimpStrideLength is authored NEGATIVE. The cycle time from it comes out
negative and is folded positive before being spent (@0x4a6c6e / @0x4a6d3d).
That fold is not defensive coding -- remove it and the limp plays backwards.
States 16-19 on the body channel are the REVERSE gait, not a limp, despite
sharing the gimp caps. BT411 records misreading these as "gimp, fall back to
standing" TWICE; that makes the body loop stand -> reverse-entry forever, a
slow reverse with a wrong-footed exit. Read here by structural symmetry with
the leg table, where every previously-decoded body case mirrors its leg twin.
DEFERRED, and named in the sidecar: the four Advance* per-frame entry points
and the two Gimp*ClipFinished limp machines -- with them the gimp-level branch
at the top of both *ClipFinished, so a limping mech currently runs the normal
machine. That branch needs a TU-safe read of the graphic alarm level (BT411
routes it through a mechdmg bridge to dodge an AlarmIndicator ODR split), worth
reproducing carefully rather than reaching for the alarm directly.
NOTHING CALLS ANY OF THIS YET. The Advance* functions are the entry points and
they are the deferred half, so no gait state is ever selected and a run behaves
exactly as before. Same caveat as 5.3.90: a blocker removed, not a behaviour
delivered.
HEADER: MECH.HPP gains the enum, six declarations, and the channel state --
legStateAlarm/bodyStateAlarm (read via GetLevel; the binary's +0x3b0/+0x728 are
mirrors of the alarm level, so no separate int is kept), legCycleSpeed,
bodyCycleSpeed, forwardCycleRate, gimpCycleRate, standSpeed, gimpSpeedMax,
gimpStrideLength, globalTimeScale, animationClips[0x1d]. 41 ints carved from
reservedState, 191 -> 150. walkStrideLength/reverseStrideLength/
reverseSpeedMax/bodyTargetSpeed already existed from the Phase 5.3 locomotion
work and are reused.
STILL UNSOURCED: animationClips[] is declared but nothing fills it. The clip
handles come from the mech's model resource and must be resolved before the
Advance* increment, or SetLegAnimation hands SelectSequence a garbage ID. It
fails soft (SelectSequence tolerates a missing resource with an inert
controller) but it is a hard prerequisite for the gait doing anything.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
c2b0a371ba |
BT410 5.3.90: the gait player is real -- SequenceController::Advance was the Fail() stub under the legs
Asked what was next for the rebuild, went to measure it, and found I had told
the operator the wrong thing one turn earlier.
THE CORRECTION. I said mech2.cpp (the gait state machine) was the next
package. It sits on top of SequenceController's playback methods, and all
three of those -- SelectSequence, Advance, Reset -- were Fail() stubs. Advance
is the function that actually walks a clip's keyframes and writes each
animated joint. mech2 without it would have called straight into a Fail. So
the dependency runs:
Mech::AdvanceLegAnimation mech2.cpp -- the STATE MACHINE, still absent
-> SequenceController::Advance THIS -- keyframes -> joint writes
-> Joint::SetHinge / SetRotation / SetTranslation
-> the joint DCS flush fixed in 5.3.88
5.3.88 fixed the bottom link, this fixes the middle, the top is still missing.
WHAT THIS DOES NOT DO: make the legs move. Nothing calls any of it yet -- no
gait state is ever selected because mech2 is unreconstructed -- so a run looks
identical to yesterday's. This removes a blocker. Saying otherwise would be
easy and wrong.
RECONSTRUCTED (compile-verified, BT 50/50, links clean):
SelectSequence @004277a8 -- find + lock the clip, parse its layout. The
fetch is FindResourceDescription and NOT SearchList: the ID arriving here is
already resolved, and SearchList would treat it as a resource LIST and walk
the clip bytes as IDs.
Advance @0042790c -- snap through every keyframe the new time has passed
(writing authored poses), then interpolate the partial frame. Returns the
forward distance covered, which is what the gait feeds into mech motion.
Reset @004283b8 -- return every animated joint to neutral, so an abandoned
gait doesn't leave the skeleton frozen on a stale frame.
THE PART THAT CANNOT BE SEEKED. The pose block is packed BY JOINT TYPE -- 8
bytes hinge, 12 ball, 24 ball+translation -- so the root-translation table
behind it is not reachable by arithmetic on any stored count. SelectSequence
must walk the entire skeleton summing per-joint sizes to find it. Which also
means the parse depends on the mech's own skeleton agreeing with the clip: an
unresolvable slot returns NULL and contributes 0, keeping the walk honest
rather than drifting keyframeData onto garbage.
TWO CONTRACTS worth recording before mech2 is written against them:
move_joints == 0 is NOT "do nothing" -- it advances the clock and
accumulates distance while leaving the skeleton alone. That is how the body
channel measures a stride without fighting the leg channel over the same
joints.
The finished callback is RE-ENTRANT BY DESIGN. At end of clip it picks the
next state, re-arms this controller through SelectSequence (rewinding it to
frame 0), and advances the carryover itself -- so its return value is the
distance that carryover covered, folded straight into Advance's own return.
mech2's BodyClipFinished has to honour that or the gait double-counts.
NOT CARRIED OVER from the donor: its BT_HIP_LOG diagnostic and audio
footstep-broadcast path, neither of which is 1995 code. footStepThreshold IS
parsed -- the field is real and authored -- but nothing reads it yet.
AND A CAVEAT ON THE 91% I QUOTED: seqctl.cpp is not in the 50-TU BT census at
all (its code sits below the BT address range the census was built from), and
that figure counts a TU as done if the FILE EXISTS -- 18 files still carry 26
Fail() stubs between them. The census understates what "playable" needs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
33fd921cea |
BT410 5.3.89: the hit-location cylinder MEASURED -- 18 tables, 8 distinct, and two chassis that never twist
The operator recalled the damage model as "a pie wedged cylinder" and asked how it maps across the mechs. It is exactly that, and the shipped data is now extracted rather than described. dmgscan.py brute-forces every offset in BTL4.RES and accepts a candidate only if the ENTIRE nested type-29 structure parses -- thresholds strictly ascending and terminating at exactly 1.0, zone indices in range, names NUL-terminated. A wrong format guess cannot survive that, so finding exactly 18 tables -- the count DAMAGE-MODEL.md already claimed from an independent reversal -- is a confirmation of the format, not a coincidence. MEASURED: 18 tables, every one 7 bands x 8 wedges = 56 cells. Only EIGHT are distinct by content; the other ten are duplicates. 22 zones 4 twisting x3 Avatar / Mad Cat class -- table A 22 zones 4 twisting x2 Avatar / Mad Cat class -- table B 21 zones 4 twisting x3 Loki 22 zones 4 twisting x2 Thor 21 zones 4 twisting x2 SND2 24 zones 4 twisting x2 Battlemaster / Vulture 20 zones 0 twisting x2 Black Hawk 17 zones 0 twisting x2 Owens BLACK HAWK AND OWENS ROTATE NO BAND WITH THE TORSO. Every other chassis rotates its upper four. That is a real behavioural difference in the shipped data, not an absence of it. The zone COUNTS match the per-chassis .SKL dz_ sets exactly, which is what lets a table be fingerprinted back to a chassis. It is not always unique -- Avatar and Mad Cat share a zone set but have two DIFFERENT tables, and no chassis name sits near the stream, so they are recorded A/B rather than guessed. Stated as undetermined in both the notes and the visual. THE GEOMETRY, now named: 18 wedge names in six anatomical rings (Foot, Leg, Hip, Waist, Chest, Top). Slot 0 starts at angle 0 spanning 45 degrees, so under atan2(z,x) the mech's +X is right and +Z is front. Each named face covers TWO adjacent wedges (Right = 7,0 / Front = 1,2 / Left = 3,4 / Rear = 5,6) -- so dead ahead is the SEAM between two Front cells, never the centre of one. Bands 0-2 are chassis-fixed; the live torso twist is added to the impact angle before the wedge pick on the rest. And the scatter is generous in a way worth knowing at the controls: a clean foot-wedge hit is only 50% that foot, 30% the lower leg, and 20% of the time the OTHER foot entirely. ALSO: an interactive plate of all of it -- every cell of all 8 tables, plan and elevation, and a twist slider that rotates the upper bands live -- published for the playtesters. Its dataset regenerates from dmgscan.py. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
07eb74d1f7 |
BT410 5.3.80: joint articulation is live -- 22 nodes, and the twist reaches the board
RecurseSKLFile now builds a joint renderable for any node whose page name resolves to a live skeleton Joint: HingeX/Y/Z -> HingeRenderable (watching Joint::GetHinge), Ball -> BallJointRenderable (watching GetEulerAngles), otherwise the static path. Each holds the rest offset in one DCS and the live rotation in a child DCS, and its Execute diffs the watched value and calls DPL_FLUSH_DCS -- the engine's own mechanism (L4VIDRND.CPP:1026+). The value comes from the mech's JointSubsystem via ResolveJoint, so sim and renderer read one source. Gated on BT_JOINTS while it proves out. [skl] video\max.skl -> 26 nodes, 1 objects, 1 eye, 22 articulated The bridge reported anim_abs=1 joints=0 twist=+0.00 before; it now reports joints=1 twist=-0.86, matching the game's [torso] twist=-0.856. With the mech stationary, frames that differed by 0.0% now differ by 62-80%. A crash it exposed: Mech::ResolveJoint passed segment->GetJointIndex() straight to GetJoint unchecked, and a segment with no joint reports -1 -- GetNthImplementation then indexes [base + -1*4] and dies (guest 00426A1D). Torso never hit it because it only asks for its own authored joint name; the walk asks for every page. Now bounds-checked against GetJointCount. Open: the canopy does not stay rigid in the view, though it and the eye hang off the same articulated node. Cancelling the bridge's cage compensation (CAGE_TWIST_SIGN=0) did not close it. Leading hypothesis: SetupCull builds worldToEyeMatrix from GetSegmentToWorld(siteeyepoint) -- the SIMULATION's segment transform -- independent of the render tree, so the canopy follows our render chain and the eye follows the sim's, and they diverge whenever one carries the twist and the other does not. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
3c289ff10a |
BT410 5.3.78: the torso twists from the button path; two buffer overruns fixed
BT_FORCE_TORSO sweeps the twist BUTTONS -- the members the streamed direct mappings write -- so the chain runs without a hand on the RIO. Live on the pod: twist sweeps -0.015 to -0.891 rad and back as cmdL/cmdR alternate, at the resource rate 0.873 rad/s, inside the authored +/-2.443 limits, with jointtorso resolved. End to end: attribute id -> direct-mapping destination -> TorsoSimulation integrator -> skeleton joint -> the canopy eye hanging off that chain. 5.3.68's table and 5.3.71's integrator both confirmed against real button semantics. Two buffer overruns, one of them mine. Reading TORSO.CPP back caught the ctor still zeroing dynamicsState[22] after I shrank the array to [16] by carving the command members out of its front: 24 bytes past the end of every Torso, on the heap, every mission, since 5.3.68. A sweep for the same shape across BT/BT_L4/MUNGA found a pre-existing one -- MECHMPPR.CPP zeroing reserved[22] against reserved[21]. Both now bound by ELEMENTS(). The rule for this tree: any array carved out of a reserve block must have its initialiser bound by ELEMENTS, because the carve is exactly the edit that silently invalidates a literal. Neither explains the residual host fault (it predates 5.3.68 at 3/3), but both were real corruption running in every mission -- and the Torso one was introduced by the very fix that cut the fault rate, which is worth remembering whenever a rate MOVES instead of going to zero. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
bd1070110b |
BT410 5.3.71: torso button commands wired into the sim; residual fault rate measured
TorsoSimulation now carries the donor's digital command handling (binary @004b5cf0): elevate up/down, twist left/right with limit clamps, the centre-button recenter latch slewing home across frames, and the ramp machinery kept verbatim including the binary's punchline -- the shipped build unconditionally overwrites the ramp with 1.0f, authored dead weight preserved as the binary's shape. recenterActive carved from the dynamicsState reserve. With 5.3.68's table fix the RIO/TM twist buttons land in these members and move the torso, and the canopy eye rides the twist chain. Also corrected in the roadmap: the 5.3.70 TriggerState 'wart' was not a wart -- CheckFireEdge already compares fireImpulse's bit pattern as a signed int, sign-correct for button ints and floats alike, and the donor binds and types the member identically. Fault rate, measured: riostreak.sh ran four consecutive vRIO-live runs -- CLEAN/CLEAN/FAULT/CLEAN, faults only ever in the load window (ticks 42-53k), clean runs always past launch. Post-fix tally 8 runs / 2 faults (~25%; was 3/3 before the Torso fix). Our load window is ~60s where shipped's is ~15s: if the residual is a constant-rate hazard during load, shipped's expected per-run rate is only ~7% -- 'shipped survives' may be exposure luck, and the residual is most likely an emulator-fork serial/DPMI interaction rather than a game defect. Next probe: hook the fork's page-fault path on the fixed cr2 and dump recent serial-IRQ deliveries + guest cs:ip history, plus a shipped-exe streak for the baseline. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
8231bee58c |
BT410 5.3.68: THE LIVE-RIO FAULT IS FIXED -- it and the TM crash were one defect
The [map] audit named it in one run: subsystem 17 = Torso, attribute ids 12/13 unresolved. The donor's decompiled torso.hpp carries the authentic enum with binary offsets -- ids 3..15, including StickPosition(9), TorsoUp/Down/ Left/Right(10-13), TorsoCenter(14), MotionState(15). Our table stopped at seven entries with MotionState at id 9, on the strength of a comment claiming the rest were messages. The streamed control mappings bind BY ID as direct WRITE destinations, so the truncation produced two different crashes from one cause: in TM mode the button ids 12/13 resolved NULL (the boot write-fault the moment the joystick polled), and in RIO mode the analog id 9 resolved to our motionState StateIndicator -- every analog packet from a live vRIO wrote raw floats over a watcher-socketed object, and the corrupted chains walked into unmapped memory ~30-40s later. That was the 'intermittent' pod fault at the fixed DPMI-host address. vRIO down = no analog = no corruption, which is why the norio conf launched: every observation from the whole hunt drops out of this mechanism. Fix: the full 13-entry donor table; five int command members carved from the dynamicsState reserve (class size unchanged); ctor zeros them. Verified, two agreeing runs each way: TM mode launches with a clean audit and the Thrustmaster joystick driving the torso (stickY=0.907 -> torsoElev 0.349); RIO mode with vRIO STREAMING launches, zero faults, weapons cycling. pod_render_rec is no longer poisoned and the norio workaround is obsolete. The audit-before-the-archive-call pattern (BT_MAP_LOG walks the same streamed table CreateStreamedMappings consumes, naming what will not resolve) turned a two-day intermittent-corruption hunt into a one-run lookup. The streamed RES tables are binding contracts on our attribute enums. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
4cf09917ce |
BT410 5.3.57: the crash is deterministic, and the real blocker is the load gate
The previous commit's attribution was wrong and is corrected in the roadmap. WRONG: 'the crash is the skeleton walk's' rested on 0 crashes in 2 runs with the walk disabled -- a 25% coin flip presented as evidence. The oldest preserved dump has no [skl] line and ends on the old 'couldn't figure out how to MakeEntityRenderables' fallback, so it predates the walk and faults identically. WRONG: 'it lands at different points each time'. Every dump carries the same numbers to the byte (cr2 7000FA64, EIP 66D9). What varies is how far the log gets, not where the fault is. Resolving the address through btl4opt.map names it exactly: EulerAngles::operator=(const LinearMatrix&)+0x19, a read through the matrix reference. A binary scan finds all three call sites of that operator pass a stack local, so the 1.79GB pointer still has no static explanation -- that is now its own open item rather than a guess. Two theories killed cleanly by the new BT_STACK_LOG probe and a binary scan: ESP drift (drift=0 over 2002 frames; exactly one callee-cleans function exists in the whole binary) and an undersized stack (our PE and the shipped one have identical 1MB/8K geometry). What the probe found matters more: the application is parked in state=2, which is LoadingMission, not WaitingForLaunch. Priority 0 is where the interest manager queues renderer events during load, the gate needs that priority empty, and it never empties -- so the mission never launches and the renderer holds a blank screen by design. The fault arrives ~30s into that wait. Runs that DO launch never print a single [launch] line. So 'crashes half the time' and 'hangs during load' are one event seen twice. A 15x disagreement between two clocks looked like a reconstruction slip -- BTL4.CPP passes GetTicksPerSecond() where ApplicationManager wants a frame rate. Checked against the shipped binary before touching it: same instruction sequence, same kind of static float pushed. Authentic. Documented so nobody 'fixes' it. Also swept every subsystem DefaultData against its real C++ base. Fifteen chain past their immediate parent, but fourteen skip only classes that add no handlers and no attributes, and no class's attribute-ID base disagrees with its index chain -- so there are no gap slots there. The one real defect: Generator is a HeatSink but chained to Subsystem::MessageHandlers, so it ignored every ToggleCooling message. Fixed (compiles next build). Tooling: podrun.sh stages the build over BTL4REC.EXE, exports the host-side VPX board env -- without which the run dies at the iserver handshake rather than merely rendering nothing -- and archives every run's log, marking it -CRASH when it faulted. Before this the only preserved dump was an accident, on a rig where each run costs four minutes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
4168f1ad4d |
BT410 5.3.47: the whole authored watcher set is published -- cockpit renders in the pod
Ladder rungs, each run-verified on the pod rig: ReportLeak (HeatSink), GeneratorOn (Generator -- member existed, publication missing), ConfigureActivePress (MechSubsystem -- likewise), AmmoState + FireCountdownStarted + the rest of the AmmoBin table. THE PINNED RANGE IS NOW THE AUTHENTIC SHAPE. Publishing ReportLeak on HeatSink and ConfigureActivePress on MechSubsystem shifts the chain down two, and MechWeapon's bridge to its binary-pinned PercentDone (0x12) collapses from THREE guessed pads to ONE -- which is exactly the arithmetic the shipped string pool predicts (MechSubsystem 1, HeatableSubsystem 3, HeatSink 6, PoweredSubsystem 5). Three pads of guesswork replaced by a real attribute and a real base-class row. HeatableSubsystem and Torso rebase onto MechSubsystem::AttributeIndex; MechControlsMapper does not (it derives from Subsystem directly). Types were chosen deliberately this time, per the AudioWatcher families the engine instantiates (Motion / Hinge / Scalar / StateIndicator): every *State name resolves to a StateIndicator, ReportLeak is a Scalar. RESULT: the pod run now gets past every authored watcher and DRAWS THE FULL COCKPIT -- sensor cluster, myomers, cooling, the weapon panels, kills/deaths -- with the board booted and audio running. It then exits without flushing its redirected stdout, so the exit reason is not yet known; next step is a run with the redirect removed so the console is readable. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
afb9e3f5d9 |
BT410 5.3.46: the Reservoir crash solved -- *State names must be StateIndicators
The linker map named the faulting function: the crash address minus the CODE base (0x410000) looked up in btl4opt.map's Publics-by-Value landed inside AudioStateWatcher::AudioStateWatcher +0x2D. AudioStateWatcher is AudioWatcherOf<StateIndicator> and its ctor immediately runs Cast_Object(StateIndicator*, attributePointer)->AddAudioWatcher(this). So every authored *State name must be published as a StateIndicator -- AlarmIndicator counts, it derives from one -- and pointing one at a plain int sends that member call through garbage. That explains both earlier failures: the AlarmIndicator attempt was the right type but was tested with other bugs still in the batch, and the plain-int attempt was simply the wrong type and crashed further along. Published as state objects: Reservoir/ReservoirState -> reservoirAlarm, Generator/GeneratorState -> stateAlarm, plus new StateIndicator members for Condenser/CondenserState and Torso/MotionState. StateIndicator has no Initialize(); the default ctor suffices because the watcher only needs the object to exist. Verified on the pod rig: no crash, ladder advanced to ReportLeak. Technique worth keeping: on an extender fault, subtract 0x410000 from the dumped address and look it up in btl4opt.map -- it names the engine function, and for this family of work that names the watcher class and hence the required member type. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
0d97d8c38b |
BT410 5.3.45: six more watcher names published; the Reservoir one CRASHES (bisected)
Published and verified green on the pod rig: Condenser/CondenserState, Generator/GeneratorState, Emitter/LaserOn, ControlsMapper/TargetRangeExponent, plus the Torso and Myomers tables from the previous pass. Reservoir/ReservoirState CRASHES the pod on the DOS extender, and a bisect pins it to exactly that change: revert it and the run returns to a clean Fail, re-apply it alone and the crash returns. It is reverted; the tree is green and the ladder is blocked there. The important lesson is general: AttributeWatcherOf<T> does currentValue = *(T*)attributePointer AT CONSTRUCTION, so a published name is read the moment its watcher is built. My earlier staging note claimed the provisional types could not matter because nothing drives the values yet -- that is wrong, and this is the counterexample. Ruled out by measurement and recorded so they are not retried: the AlarmIndicator-vs-int type (a plain int got further, 232 -> 749 bytes of log, but still crashed), static-init order (reservr.obj sorts last, after heat), an id gap (contiguous at HeatSink::NextAttributeID), and the gauge rig (same binary runs clean there -- only the pod/arena context faults). Crash signature for whoever picks it up: 0044B4AD, mov eax,[edx+0x18] then call [eax+4], EAX=0x15, fault at 0x19 -- a small integer called through as an object, i.e. the AttributeIndexSet::Build uninitialised-slot pattern. Condenser is the control: same base class, plain int, no crash. Also fixed on the way: staged members must be appended at the END of a class (offset-sensitive readers exist -- condenserNumber is reached as master+0x1d4) and never added to a resource struct, which is a wire format. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
3ecd88aaef |
BT410 5.3.44: read the whole watcher list out of the resource; Torso MotionState
BTL4.RES stores each watcher as a (SUBSYSTEM, ATTRIBUTE) string pair, so the complete list can be extracted directly instead of discovering one name per 6-minute run. Banked the extraction method and the full normalised table. Sixth rung climbed: Torso/MotionState (staged member, appended at the end of Torso's own range so no downstream id moves). LocalVelocity and LocalAcceleration turn out to need nothing -- the engine's Mover already publishes them. Also banked, and deliberately NOT acted on: ReportLeak and ConfigureActivePress are base-class attributes inside the pinned range, and chasing them turned up what looks like the authentic attribute layout. The shipped pool gives MechSubsystem 1, HeatableSubsystem 3, HeatSink 6, PoweredSubsystem 5 -- which counted from Subsystem::NextAttributeID=2 lands MechWeapon's real ids on the binary-pinned 0x12 with EXACTLY ONE pad, where our tree needs three. That arithmetic is strong evidence for the original layout, and reconciling to it would replace three guessed pads with the real table. But it moves ids underneath a cockpit currently verified at 98.9% pixel-identical, so it wants a deliberate session with the A/B rig open rather than a bulk edit at the end of a long one. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
14da9489c2 |
BT410 5.3.43: full pod rig -- geometry loads, ladder advances to the audio watchers
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
|
91b043778e |
BT410 5.3.42: the 3-D pipeline runs to the geometry load -- two rungs climbed
RUNG 1: BTL4VideoRenderer::LoadMissionImplementation, Fail -> bring-up no-op. Legal, not a cheat: the engine's own VideoRenderer version (VIDREND.CPP:259) is a bare Tell and our working GaugeRenderer ships the same, so the renderer comes up and runs its frame loop with an empty scene -- exactly what we want to measure before writing content. The authentic shape for the real body is pinned by the surviving sibling header CODE/RP/RP_L4/RPL4VID.HPP (walk the mission entities -> MakeEntityRenderables -> ReadSKLFile/RecurseSKLFile). RUNG 2: Mech::EyepointRotation published. The engine then Failed at SetupCull, which fetches that attribute BY NAME off the viewpoint entity and composes it with the siteeyepoint segment to build worldToEyeMatrix. The mech already HAD EulerAngles eyepointRotation with a getter -- only the publication was missing. One enum id, one table row. The run now reaches the full mech build, constructs the renderer, boots the board (~907K VPX wire transactions), loads the mission, runs the per-frame cull and enters geometry loading with ZERO Fails and zero exceptions. It stops at 'couldn't load object buttee.bgf' / 'NULL instance' -- and that is not a defect: the models are present and BTDPL.INI points at them, but .BGF loading goes through the board to the external GL render bridge that the VPX HLE tees over VPX_FIFOSOCK, and that bridge was not running. 'NULL instance' comes from the prebuilt LIBDPL.LIB refusing to instance an object that never loaded. Next rung is the documented full rig (render-bridge/launch_pod.ps1). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
6a3cf06ece |
BT410 5.3.36: the cooling-loop lamp goes live (OFF -> the loop digit)
CoolingLoopConnection::Update wrote a constant 0 -- the documented inert stub -- because HeatSink::coolantAvailable, HeatSink::linkedSinks and Condenser::condenserNumber are protected with no accessor, so every MFD panel showed OFF where the shipped cockpit shows the loop number. heat.hpp now publishes GetCoolantAvailable(), ResolveCoolingMaster() and GetCondenserNumber(), and the connection follows the binary: a sink with coolant reports the loop number of the Condenser it is plumbed to, otherwise frame 0. Same shape as PowerSourceConnection beside it, which was already live and already matched. The box now reads 4 / A against the shipped binary's 4 / A, pixel for pixel. head missing extra Mfd1 1331 -> 1107 1776 -> 1646 Mfd2 1908 -> 1616 2196 -> 1981 Mfd3 730 -> 584 1119 -> 1014 Cockpit: 96.6% identical / 96% coverage. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
30e4b5885d |
BT410 5.3.34: the weapon ammo readout goes live (0024)
BallisticWeaponCluster's two round counters pointed at UnboundIntegerSource because ProjectileWeapon::ammoBinLink is protected -- the documented inert gap in the ctor ledger. ProjectileWeapon now exposes GetAmmoCount() (the resolved bin's rounds, -1 with no bin) and the cluster copies it into a live cell each Execute, the same pattern it already uses for jammed and reloadSeconds. The binary pointed its NumericDisplayInteger straight at the resolved bin's count. The STREAK 6 panel now reads 0024 against the shipped binary's 0024, in the same font, stencilled into the fire-ready disc the same way. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
341a503641 |
BT410 5.3.33: MissileLauncher was wired to the wrong shared-data tables
MissileLauncher::DefaultData passed Subsystem::MessageHandlers and Subsystem::AttributeIndex where every sibling weapon passes MechWeapon's -- and a launcher publishes no tables of its own, so it must chain MechWeapon's exactly as ProjectileWeapon (its own base) does. Wired to Subsystem's, EVERY weapon attribute on a missile launcher resolved to nothing and the gauge read the unbound zero cell: PercentDone, TriggerState, WeaponState, DistanceToTarget, RearFiring. The cockpit is what found it. The shipped binary lights a fire-ready disc on the STREAK 6 panel (WeaponCluster gates it on PercentDone >= 0.99) and ours never did -- while the launcher itself reported state=Loaded recoil=0 level=1 bin=24. A healthy weapon behind a dead binding. head missing before -> after extra Mfd1 8807 -> 4991 4063 -> 4003 Mfd3 6935 -> 3174 2659 -> 2608 Mfd2 6882 -> 6870 (unchanged -- it hosts no missile panel) ~7.6K missing pixels recovered. The disc, its rays and the stencilled ammo cells now draw; the digits themselves stay blank pending the ammo feed, which is the documented inert gap in the BallisticWeaponCluster ledger. Traces added, all env-gated on BT_VIS_LOG and kept as tooling: [warn] (cluster percentDone/warn state) and [proj-state] (launcher state, recoil, recharge rate, bin count) -- the pair that separated "broken weapon" from "broken binding" in one run. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
740ef2b0a7 |
BT410 Phase 5.3.32: the per-head A/B -- three engineering heads now exact
The gauge framebuffer is PLANE-PACKED: L4GAUGE.CFG gives each port a bit
mask, not a rectangle, so all six heads share the same x/y and are separated
only by bit -- the packing the VDB splits into the pod's physical screens.
Comparing RGB was therefore measuring nothing useful; the "magenta artifact"
just meant the wrong heads were lit at that pixel.
New instruments (emulator/render-bridge/gauge-ab/, with a README):
planes.py per-head scoreboard -- shipped vs ours, missing vs extra, per
port mask, recovering the 16-bit word from DOSBox's RGB565
BT_VIS_LOG a complete cockpit widget map from the single dispatch every
gauge widget is built through (MethodDescription::Execute),
printing name + port + authored position
ab.sh stages the fresh build over BTL4REC.EXE and kills any running
DOSBox before launching -- see below
The fix: the Comm page's pilot roster is the POD roster (the viewpoint mech's
ControlsMapper pilot array, mapper attributes 15/16), not the mission's
player list. It is zero in a solo mission, so the shipped page draws empty;
ours resolved the local player and painted its icon in colour 0xff. The gate
belongs in the row source, not PilotList::Execute -- Execute's empty branch
still has to run, because erasing is what the shipped page draws.
head shipped ours missing extra (was)
Eng1 17981 17981 0 0 (0 / 1030)
Eng2 17981 17981 0 0
Eng3 17981 17981 0 0
Comm 15656 13557 2099 0 (2099 / 1253)
Heat 21374 20913 566 105 (566 / 990)
Title-band magenta 404 -> 0. The 2099 Comm pixels we are missing were
missing before the gate, so it is a strict improvement.
Method note, which cost more than the bug: the rig's confs run BTL4REC.EXE
out of the mount while the build writes build410/btl4opt.exe, and nothing
connected the two. Three measurements ran an hour-old binary, so a change
that "did nothing" three times had never been tested -- and the correct first
hypothesis was discarded on that evidence. ab.sh now re-stages every launch.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
24ea06574c |
BT410 Phase 5.3.28: the visual A/B pass -- 93% pixel-identical to the shipped cockpit
Ran the reconstructed exe and the shipped ALPHA_1 binary against the SAME GAUGE content, same mount, gauges on, and diffed the 640x480x16 framebuffers. OUR EXE DRAWS THE COCKPIT: 90.1% pixel-identical on the first run, and every difference traced to a single root cause. The authored aux-screen block (screen number / background placement / label) lives in the subsystem resource -- which is freed with the Mech ctor's stream buffer (the 5.3.24 use-after-free landmine). Both this tree and the BT411 port had stubbed it, which is why BT411's displays show the same artifacting. PoweredSubsystem now caches the block at ctor time with accessors, and btl4gau2 uses the AUTHORED screen instead of a roster-order stand-in and builds the placement strip art. Panels snapped onto their authored screens -- weapon dials now land on the same panels as the shipped exe, mech icons appear on the sensor/myomer panels, generator letters correct -- taking the match to 93.2% identical / 85% coverage. Remaining differences are donor-inherited stubs: the panel title art (now proven to come from the q-strip statusImage path, not auxScreenLabel -- the label blit is wired and guarded regardless), the pilot name bitmap, and some lamp frames. The A/B rig is banked at emulator/render-bridge/gauge-ab/ (both confs + the window-grab script) so the comparison is repeatable. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
d67f8d5eda |
BT410 Phase 5.3.27: the attribute wave -- 48/50 cockpit bindings go LIVE
The gauges now read the real simulation: heat/power/sensor/mech attribute tables published under the 1995 L4GAUGE.CFG spellings the widgets already bind by name. Temperatures, coolant mass/capacity/leak rate, condenser valve settings, generator voltages and numbers, radar percent, and the mech's radar/speed rows all resolve to live members. THE NUMBERING IS PINNED: the chain publishes 2..0x0E so PoweredSubsystem::NextAttributeID lands on the authentic 0x0F -- the surviving SENSOR.HPP numbers RadarPercent off it and MechWeapon's binary-pinned table starts at 0x12, so its pads shrank 16 -> 3 (0x0F..0x11) exactly as the 5.3.x header comment predicted. Sensor's authentic enum finally has its table defined; MechWeapon/Sensor rechain to PoweredSubsystem and Reservoir/AggregateHeatSink to HeatSink so the whole family is visible where the cfg expects it. Verified with BT_GAUGE_ATTR_LOG: 48 OK / 2 NULL (was 33/17, and 0/50 at the block's birth). The two remaining have no member to bind -- HeatSink/AmbientTemperature (a sim constant) and Searchlight/LightOn (a memberless subclass) -- and fall to the documented zero cell. Gauge fight (15/15 rounds, 127 zone hits), smoke and novice all clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
f65a3259ce |
BT410 Phase 5.3.25: scoring + the COMPLETE mission lifecycle -- egg to GAME-RC
Scoring roles bound (binary ctor tail @004c0bc8): the mission role dict -> Player::scenarioRole; TEST.EGG's Role::Default = the baked dfltrole (lives=1000, killBonus=500) -- authored data flowing. The three score handlers are live per the decomp derivations (@004c02e4 / @004c0200 / @004c02a8 + CalcInflictedScore @004c052c; tonnage/bias staged); the producers post damage scores per delivered hit and the kill credit from the death transition with the latched killing-blow magnitude. First live kill: award=3.43, kills=1, score=123.6. Out of lives -> the mission END: the binary's +10s review post sits in the one decomp gap, so the staged stand-in enters the engine's own cascade (StopMissionMessage +10s) -- EndingMission -> the 3s fade -> the second Stop -> Application::Stop -> RunMissions exits. The BTL4/L4 stop layers run authentically (plasma score display off, egress lamps). VERIFIED END-TO-END: a 2-lives egg (role-page return=2 override) -- death #1 debits and respawns healed; death #2 is OUT OF LIVES; +10s later the mission ends and BTL4OPT.EXE exits CLEANLY to DOS (GAME-RC prints). The full 1995 pod mission loop -- egg, boot, spawn, fight, score, die, respawn, die, mission end, exit -- now runs from reconstructed source. Zero faults; fight/smoke/novice regressions green. Dev knob: BT_PLAYER_PASSIVE=1 (piloted mechs hold force-fire). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
623c872c92 |
BT410 Phase 5.3.24: the death -> respawn cycle -- mechs DIE and COME BACK
The full circuit, workflow-researched (5 parallel dossiers over BT411 + the engine) and adversarially reviewed (3 lenses) before landing: Mech side: the once-per-death transition in Simulate (freeze, motion kill, DeathShutdown sweep, MASTER-only VehicleDead(-1) to the player link); Mech::Reset @0049fb74 (reposition + heal every hull zone + the roster DeathReset sweep + PreRun -- the reset-based respawn that REUSES the entity); dead-owner terms in both weapon hard gates (wrecks fall silent). Player side: the VehicleDead(-1) branch (deathPending dedup, deathCount bump+stamp, scenario-role life debit, +5s re-post -> the engine drop-zone hunt) and the DropZoneReply respawn branch (reset the dead mech at the replied drop zone; probes on a live mech are moot). Subsystem side: the engine base virtual DeathReset implemented across the family -- MechSubsystem (zone heal + DestroyedState clear), MechWeapon (full powered/thermal restore + fresh Loading cycle), AmmoBin (restock from the ctor-cached count), HeatSink/HeatWatcher/PowerWatcher/Generator/Sensor/ MissileLauncher. Review catches fixed before commit: AmmoBin restocked through the FREED padBuffer pointer (use-after-free -> initialAmmoCount; MechSubsystem:: resource is now documented as never-deref-post-ctor); died-hot weapons respawned at FailureHeat (now full thermal re-init); Generator tap counts desynced across reset (preserved); Sensor skipped the base heal; PowerWatcher inherited a statically-bound reset; cooling toggle + connect mode restored. Verified: kill -> wreck (0 shots while dead) -> +5s -> drop-zone hunt -> HEALED + placed at a real drop zone -> 134 shots after respawn incl. 12 SRM (restock proof); unowned enemy wreck settles silently; fight/smoke/novice regressions green, zero faults. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
2f0d3b6239 |
BT410 Phase 5.3.23: the cylinder hit-location table -- unaimed hits land WHERE THEY STRIKE
DMGTABLE born (type-29 streams, BT411 byte-verified format): the height x angle grid -- DamageLookupTable rows by height, PieSlice cells by angle (rotate-with-torso rows add the live twist), DamageZonePercentTable = the cumulative hit-distribution roll (first threshold above the roll -- the BattleTech dice scatter). Loaded in the Mech ctor by the DamageZoneStream member's NAME (mech+0x444, resident); Mech::TakeDamageMessageHandler resolves invalidDamageZone hits through it (binary @0x4a0264 tail). The missile fuse becomes the authentic unaimed producer: zone -1 + the round's world position as the impact point (ENTITY3.HPP: "damage zones are only valid via reticle based weapons"). Fight-verified on the authentic 7-row bhk1 table: flat-flying SRMs strike low -> row 0 -> FEET AND LEG zones, side-correct by impact angle (+x right, -x left), identical geometry spread across the cell distribution by the roll. 17/17 missile lifecycle, zero faults; smoke + novice green. Also fixed: the ctor's reservedState zero-loop counted past the shrunken array. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
bfff7fe874 |
BT410 Phase 5.3.22: the cockpit weapon-button column -- generator panel LIVE
The full per-receiver message chain, contiguous ids 3..0xb: PoweredSubsystem 4-8 (SelectGeneratorA-D + ToggleGeneratorMode, binary table @0x50F4EC) chained on HeatSink's ToggleCooling(3); MechWeapon 9/10 (config buttons, staged latch bodies); Emitter 0xb ToggleSeekVoltage (@0x511DB8). SelectGenerator = release the old tap -> roster walk by generatorNumber -> AttachToVoltageSource -> Connected; mode toggle cycles Manual->Auto-> (detach)->Manual; the seek dial steps the authored voltage ladder with wrap (a step up re-enters Loading, charge persists). All novice-locked. Generator::UntapVoltageSource + PoweredSubsystem::DetachFromVoltageSource added. Dev harness: BT_PRESS_GEN=1..4 / BT_PRESS_SEEK. Verified: PPC_1 retaps GeneratorB (tapped); seek index 2->3, target 9900V (authored fraction x rated); novice presses INERT; missile fight 14/14 and smoke green, zero faults. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
1a01aa6f43 |
BT410 Phase 5.3.21: the muzzle wave -- rounds leave FROM THE GUN
MechWeapon::GetMuzzlePoint (binary @004b9948): the mount segment's world frame via GetSegmentToWorld (segmentToEntity x localToWorld), translation extracted by transforming the segment-space origin. The missile spawn now launches from the rack mount -- verified live: SRM6_1/SRM6_2 leave from distinct world positions 4.0 units above the hull origin, laterally offset per rack and rotated through the mech's yaw, on BOTH mechs. 19/19 launch-detonate over 100s, zero faults; smoke green. (The authored MuzzleVelocity up-tilt composed in the mount frame + the mech velocity term remain with the beam/render wave -- the seeker converges from the aimed initial velocity either way.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
76acc516e4 |
BT410 Phase 5.3.20: missiles fly on the AUTHENTIC 'mslhit' family
The explosionModelFile decode: SRM6's streamed value 17 is a real resource
FAMILY id -- 'mslhit', 3 members: VideoModel(225), AudioStreamList(227) and
an 8-byte GameModel(228) = { int 498, maxTimeOfFlight 5.0 }. The round now
spawns on that family and reads the AUTHORED 5.0s lifetime (range 800 at
~160 u/s checks out); the owner-family fallback stays for content without a
projectile family (sanity band keeps the default there).
Two engine truths closed the wave: (1) collision volumes are the Mover
DEFAULT -- a projectile spawn MUST pass NoCollisionVolumeFlag or the ctor
demands a BoxedSolidStream member the family doesn't carry (SearchList
NULL -> Lock() page fault -- the crash that originally masqueraded as a
"model-list index"); (2) the @0x414938 SearchList crash is the
missing-MEMBER case (Check compiled out) -- probe families manually before
handing them to engine paths. Resource type numbering mapped and recorded
(15=GameModel, 10=VideoModel, 20=DamageZoneStream, ...). BT_MODEL_DUMP=1
keeps the raw family/record dump as a decode bench.
Verified: 20 launches -> 20 detonations on the mslhit family over 110s,
zero faults; smoke + novice green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
fdf26d6e55 |
BT410 Phase 5.3.19: teardown SOLVED -- flying missiles are the DEFAULT
The death-row page fault was the THIRD strike of the uninitialized zone-array trap: the staged spawn rides the mech family's resourceID, whose DamageZoneStream makes the Entity base ctor allocate the 20-pointer damageZones[] array with UNINITIALIZED slots -- the Missile never fills it, and ~Entity's teardown deleted 20 garbage pointers through trash vtables (the dtor-chain bisect showed every dtor completing, then EIP-in-heap). Fix: the Projectile ctor NULLs every inherited zone slot. RULE, now three-crashes-proven: any entity subclass that does not FILL the allocated zone array must NULL it -- the engine never initializes the slots, on construction OR destruction. Missiles are now the default SRM delivery (BT_MISSILE_INSTANT=1 = the 5.3.18a instant-hit as an A/B opt-out). Verified: 20 launches -> 20 detonations -> 20 clean death-row teardowns over a 110s mutual fight, zero faults; smoke + novice regressions green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
110ecec2ca |
BT410 Phase 5.3.18: flying missiles -- spawn/home/detonate LIVE, teardown open
The Missile entity family is reconstructed: Projectile : Mover gets a real make-path ctor; Missile hosts the Seeker + MissleThruster roster (the AUTHENTIC surviving SEEKER.HPP / MISTHRST.HPP interfaces -- the 1995 misspelling included) and flies the binary's guided integrator (@004bef78): age/lifetime, seeker re-lead with the decoded loft constants (200/50/300/0.1), thruster burn, steering (gain 4.0, deadband 1e-4), and the proximity fuse delivering the cluster damage ONCE with the launcher as inflictor. Live-verified end-to-end: LAUNCH -> flight telemetry (thruster visibly accelerating) -> DETONATE on the target ~0.9s out. OPEN: the first ~Missile off the death row completes, then the frame page-faults with EIP in the heap -- the first entity/subsystem teardown the reconstructed sim has ever run. The spawn path is therefore OPT-IN (BT_MISSILE_FLIGHT=1); default SRM delivery stays the 5.3.18a instant-hit cluster (verified 1:1, zero exceptions). Forensics + engine truths (SearchList crashes on non-directory ids; MakeMessages need FAMILY resource ids; explosionModelFile is a model-list INDEX) in MISSILE.NOTES.md. Also fixed on the way: the Subsystem NAME ctor left damageZone UNINITIALIZED (latent garbage for every name-built subsystem). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
f2424e9fdc |
BT410 Phase 5.3.18a: salvo economy corrected -- one cluster hit per trigger
BT411 task-#62 truth: the arcade fires ONE cluster Missile per salvo and its zone damage lands EXACTLY ONCE (burstCount feeds only the gyro bounce + splash falloff, never the zone armor formula). The 5.3.16 per-missile delivery loop was ~6x too lethal. MISLANCH now sends a single salvo-split damage message (verified 1:1 FIRED-to-damage in the mutual fight; zero exceptions). The cluster splash joins the Missile entity wave. Also: BT_FORCE_ZONE=n dev hook (pin every hit -- the cascade verification knob) landed with 5.3.17's runs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
d4f0aef6e1 |
BT410 Phase 5.3.17: the destruction cascade -- zone deaths DESTROY things
Mech::DamageZone::TakeDamage is the full binary cascade (@0049c690): LOD artifact router with same-attacker clustering (@0049c40c, hysteresis 0.33), artifact parent level = mean of children, Energy-hit generator shorts through the crit plug binding (novice-exempt), weighted CriticalHit (@0049ccc4), zone-death allotment push (SendSubsystemDamage @0049c9a8) and the segment-table destruction descent (RecurseSegmentTable @0049cad4 -- SIBS + DESCEND via the engine EntitySegment iterators). Supporting bricks: Mech's OWN handler table with the TakeDamage override (latches lastInflictingID @0x43c; gyro feed staged; cylinder table deferred); friend class Mech__DamageZone (authentic); subsystem private zones ARMED (structureReference + armorByFacing[5] normalized -- crits are measurable); ApplyDamageAndMeasure; ForceCriticalFailure sets DestroyedState so the weapon FSMs' GetSimulationState()==1 hard gate went live; Generator::ForceShort + PoweredSubsystem::ForceShortRecovery. Fight-verified (mutual BT_SPAWN_ENEMY + BT_FORCE_ZONE=8 concentrated fire): arm zone to 1.0 -> sibling searchlight zone dies (Searchlight2/ThermalSight crits destroyed, HUD degrading) -> DESCEND kills the gun zone -> PPC_2 + ERMLaser_2 + Condenser6 DESTROYED and FALL SILENT (0 shots after death; undamaged PPC_1 keeps firing); vital-zone hit = MECH KILL; PPC hit shorted GeneratorD. This art has zero artifact zones (redirect=0 across all 20 -- router verified dormant-correct). Smoke + novice regressions clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
76cfc64353 |
BT410 Phase 5.3.16: targeting + damage -- two-mech fights are LIVE
The simulation is now a FIGHT. Mech target slot (+0x388), authentic Loaded->Firing gate (viewFireEnable && HasActiveTarget), UpdateTargeting range refresh, and SendDamage via the engine TakeDamageMessage. MECHDMG.CPP is BORN against the AUTHENTIC surviving CODE/BT/BT/MECHDMG.HPP: the Mech ctor's Pass-3 hull zone fill constructs Mech__DamageZone per zone (the Entity base only allocates the raw pointer array -- unfilled slots were crash #1; a base-class fill parses each record short and skews the stream -- crash #2). Streamed ctor parses the full BT tail (flags / Scalar-weighted criticals with the Master+Dynamic plug gate / LOD redirect table) and normalizes the armor economy: scale[type]=1/(raw x armorPoints), legs halved -- BT411-verified @0049ce50. Live two-mech verification (BT_SPAWN_ENEMY harness in DropZoneReply): 20 named hull zones stream on both mechs; PPC lands 11.77/hit (12 x chargeRatio^2, type 4), ER-M laser 3.43 (type 3), SRM6 salvos 5.83 x 6 rounds on independent zones (type 2, one message per missile -- burstCount is NOT in the zone formula); repeat hits climb linearly, leg zones absorb at half scale, zones reach 1.0 Burning/Destroyed. No-target and novice regressions hold (weapons load but never fire without a target). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
b772e716fe |
BT410 Phase 5.3.15: the electrical charge model -- real charge, closed feedback loop
The emitter charge cycle is now the authentic electrical model end to end.
- WIRE-VERIFIED resource fix: the Emitter block is graphicLength /
dischargeTime / seekVoltage[5] (FRACTIONS of the generator's rated voltage,
-1 sentinel) / seekVoltageRecommendedIndex. The old two-field guess read
seekVoltage[3]=0.99 as "dischargeTime 0.99s" -- the true PPC discharge is
0.2s, and the calibration reads seekV={6000,7000,8000,9900} x rated 10000,
recommended gear 2: the documented curve exactly.
- Ctor calibration (@004bb120): energyTotal=(dmg+heat)x1e7; EC pins
E=0.5V^2EC to energyTotal at the recommended gear; voltageScale calibrates
the exponential charge to reach seekV[rec] in the authored RechargeRate
seconds cold; damageFraction = the damage share.
- TrackSeekVoltage (@004ba838) + ChargeTimeScale (@004b0d50): the charge
integrates from the generator through the heat-stretched time scale, and
the I2R loss heats the GENERATOR -- verified GeneratorA at 477.9K charging
its PPC (BT411 predicted ~+480K) while the avionics generator idles at 77.
Hot generators charge slower: the heat/firepower feedback loop is CLOSED.
- Emitter::ComputeOutputVoltage override (now virtual, as in the binary
vtable): dial = level/seekV[gear], 0.01 snap, over-1 clamp.
- Sub-stepped Loading (1/60s slices -- the BT411 weapon-brick fix) + the
documented-divergence overcharge rescue. VERIFIED: the PPC loads at level
~7920, inside the binary's exact [7920,8080] snap window.
- FireWeapon energy algebra (@004bace8): damage/heat = energy shares x
chargeRatio^2. VERIFIED dmg=11.78 / heat=1.079e8 at ratio 0.9906. The
heatCost x 1e7 partial is retired -- heat now comes from the energy.
Zero Fail; jams/shutdowns regressions stay live under spam.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
6451a0a38d |
BT410 Phase 5.3.14: AggregateHeatSink -- the bank + the ambient radiator (the heat EXIT)
The central heat bank is now its real class: the binary's 0x0BBE AggregateHeatSink (the value our VDATA enum named HeatSinkClassID -- there is no streamed plain HeatSink; the segment walk now builds the bank). - Ctor (@4ae8d0): heatSinkCount from res +0xFC (bhk1 = 6, matching its six condensers); thermalConductance x 0.1 x count (231000 -> 138600); ambient setpoint 300 (the mission [mission] temperature overwrite joins the Mech-PlayerLink wave). - RadiatorSimulation (@4ae73c) replaces the base heat step on the bank -- THE system's only heat exit: relax toward the ambient target with rate k = conductance x (1-damage) x (coolant/capacity) x flowScale / mass; tail tops the bank's coolant from the attached store via the DrawCoolant virtual (base 0 until the reservoir-attach wave). VERIFIED signed-correct: the bank warms 77 -> 300 from the cold start, then flips to actively radiating (-48K..-167K/step) once fired heat pushes it past ambient. Until now heat only ever POOLED in the central sink; the mech now genuinely sheds it. - Reservoir master path: capacity = 0.05 x bankCount x streamed = 6 (the authentic tank), refilled. Zero Fail; the expert economy regression stays green (202 heat events under forced spam). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
c01e57ab22 |
BT410 Phase 5.3.13: cockpit-button message layer -- valves, cooling, flush LIVE
The subsystem-family cockpit buttons now work through the authentic Receiver dispatch -> per-class handler-table path. The id space decodes cleanly: Receiver::NextMessageID == 3, so ToggleCooling = 3 on the HeatSink chain and the per-class id 4 is MoveValve on a Condenser / InjectCoolant on the Reservoir -- same number, different class, the binary's per-receiver-class convention. - HeatSink::ToggleCoolingMessageHandler (@004ad6f8, id 3): novice-locked, press-only; toggles coolantAvailable + coolantFlowScale together. - Condenser::MoveValveMessageHandler (@4ae464, id 4): novice-locked; cycles the valve 1->5->50->0->1 and calls Condenser::RecomputeValves (@0049f788): every condenser's coolantFlowScale = valve / sum-of-valves. The ctor now streams the AUTHENTIC flowScale=0; the Mech ctor seeds equal shares once at spawn -- the flowScale=1 interim is retired. - Reservoir::InjectCoolantMessageHandler (@4aee70, id 4): novice-locked; press arms the flush when the tank holds charge, release drops it. - MechSubsystem::NoviceLockout() (@4ac9c8): owner -> playerLink -> experience == novice; unlinked mechs read unlocked. - DEV harness BT_PRESS_VALVE / BT_PRESS_FLUSH: dispatch the REAL messages ~6s into the mission from Mech::Simulate. VERIFIED: spawn shares 6 x 0.166667; one MoveValve press -> Condenser1 valve=5 flow=0.5, others 0.1 (valve/sum exact); flush arms via the real button message; NOVICE locks both presses (valve lines stay spawn-only, zero flush). Zero Fail throughout. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
e1e5a9a6db |
BT410 Phase 5.3.12: experience gates + coolant system -- novice/expert modes REAL
The player-experience system now gates the entire heat/jam economy, verified in BOTH directions with a one-token egg edit (TESTNOV.EGG, experience=novice): NOVICE = 212 fire cycles all pinned at T=77, zero jams, zero shutdowns (the heat model authentically absent); EXPERT = the full economy (duty cycles, 119 shutdowns + 2 authentic jams under forced fire). Zero Fail in both. - BTPLAYER: the flag block renamed to its TRUE semantics (simLive @0x25c, heatModelOn @0x260 -- the FUN_004ad7d4 master switch, advancedDamageOn pair, levelFlag26c/270, experienceLevel); the ctor rows were already binary-accurate (nov 0000 / std 1011 / vet 1111 / exp 1101); accessors + [exp] sentinel. - HeatSink::HeatModelActive() + ProjectileWeapon::LiveFireEnabled(): owner mech -> Entity::GetPlayerLink() -> the BTPlayer flags, NULL-permissive. Gates: both HeatSinkSimulation phases, every weapon fire-heat dump, and CheckForJam is now the AUTHENTIC form (LiveFireEnabled + heatLoad<=0 early-outs + the minJamChance floor; the interim heat-degraded gate retired). - THE LOAD-BEARING FIX: Mech ctor SetValidFlag(). Every 1995 entity ctor tail marks itself valid; ours didn't -- Entity::Dispatch routes messages to an INVALID entity into the deferred event queue, so the PlayerLink bind (and every directly-dispatched mech message) silently never landed and the gates read a NULL player forever. - THE COOLANT SYSTEM (authentic bodies, byte-verified constants: HeatLoadScale 0.002 -> heatLoad now in [0,1]; equalize eps 1e-4; draw floor/ON 0.0025/0.003): UpdateCoolant (damage-scaled draw -- an undamaged mech leaks nothing), BalanceCoolant (full clamp chain from ConductHeat), DrawCoolant base=0 with the RESERVOIR override as THE SOURCE; Reservoir reconstructed (capacity overlays thermalCapacity, CoolantSimulation + the full InjectCoolant flush distribution, BT_FORCE_FLUSH dev hook); Condenser RefrigerationSimulation (massScale = (1-damage)*refrigerationFactor >= 1 -- the heat pump that chills the bank; valveState inits 1; digit-suffix number fix). Deferred: AggregateHeatSink family, cockpit-button handlers (MoveValve/ToggleCooling/InjectCoolant), TrackSeekVoltage charge model. Research driven by a 4-agent workflow dossier over the BT411 RE (verbatim bodies for every function above + the egg experience plumbing). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
b1cbbe1c9b |
BT410 Phase 5.3.11: weapon heat consequences -- jams + thermal shutdowns LIVE
The heat economy now bites back, verified under sustained fire: - Ballistic gate 1 (@4bbd36): destroyed-state or own-sink FailureHeat pins full recoil + the unavailable alarm (the NoAmmo roach-motel re-asserts). - CheckForJam (@4bbfcc): p = 0.41*T/failT clamped [minJamChance, 1.0], rolled per granted shot against the MUNGA uniform Random. Interim heat-degraded gate stands in for the deferred LiveFireEnabled novice switch (the exact spurious-cold-jam trap the BT411 port documented). VERIFIED: SRM6s jam at T~1200-1320 after riding past the authored 1000-degree threshold, and stay jammed (mission-reset recovery only) -- authentic. - Emitter hard gate (@4baab9): FailureHeat drops the beam state + charge each frame; SELF-RECOVERING once conduction cools the sink below failure. VERIFIED: the PPC settles into an emergent thermal duty cycle -- fire at ~1930K, spike to 2562K, shutdown, cool, refire -- firing exactly as fast as its sink sheds heat; the lasers oscillate around ~2200K. Zero Fail. Deferred: LiveFireEnabled/HeatModelOff experience gates, mech-disabled gate halves, coolant depletion, jam recovery via mission reset. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
57507cb15c |
BT410 Phase 5.3.10: power/heat wave -- the thermal + electrical economy is LIVE
Weapons dump firing heat into their own sinks, sinks conduct through the Condenser bank into the central HeatSink, temperatures drive the degradation/ failure alarms, and every powered subsystem tracks its generator through the electrical state machine. Verified: the authentic fire-discipline game -- a PPC spikes 77->709K per shot, relaxes to 441K across its 5s reload, and sustained fire climbs 441->674->838->960K, brushing the authored 1000K degradation threshold. All calibration values match the BT411 audit exactly (central bank 1.39e6, PPC sink 174000, thresholds 77/1000/2000). - HEAT: HeatSinkSimulation (@004ad924 absorb->T->load->conduct->alarm), ConductHeat/ComputeHeatFlow (@004ad8ac/@004ad9ec two-body equilibrium relaxation; flow==0 exactly at uniform T), UpdateHeatLoad (15-sample filter); heat-state enum + accessors; installed by the HeatSink ctor. - WIRE-VERIFIED: HeatSink resource gains linkedSinkIndex -- THE missing ancestry int that shifted every descendant block +1 (voltageSourceIndex had been reading the linked-sink index: "power sources" appeared to be Condensers). Conduction topology wired from it at construction: weapons->Condensers1-6->central; Generators->Condensers; Reservoir->central. - MECHWEAP resource: authentic pip tail (pipPosition int + pipColor 3 floats + pipExtendedRange int) per the BT411 verified overlay; with linkedSinkIndex this closes the whole +3 alignment mystery (ProjectileWeapon pad deleted). True bhk1 reads: PPC recharge 5.0s (not 1.0), discharge 0.99s, range 900. - POWERSUB: ctor resolves voltageSourceIndex -> GeneratorA-D (wire-verified), taps via Generator::TapVoltageSource (-1 when full); PoweredSubsystemSimulation (@004b0bd0) electrical FSM (Starting/NoVoltage/Shorted/GeneratorOff/Ready); GeneratorSimulation partial (start/short-recovery timers). - Weapons: power step at sim head; Loading recharge gated on electrical Ready (authentic @4bbdf5); FireWeapon dumps firing heat. HEAT UNITS: the chain is 1e7-native with TWO authoring conventions -- energy weapons store small (PPC=11, x1e7 from the energy algebra), ballistics store native (SRM6=5.06e7, dumped raw; double-scaling it was the bring-up runaway-temperature bug). - SENSOR: authentic gating (@004b1c4c) -- power step, electrical-Ready gate, heat-state switch (Degradation x0.5 / Failure 0). Verified Ready + 100%. Deferred: coolant depletion/venting, the novice HeatModelOff gate, the charge model (TrackSeekVoltage/voltage sag/I2R), weapon gate 1 + jam roll, the central sink's forward-linked drain. Zero Fail across fire + neutral runs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
ab7191dc38 |
BT410 Phase 5.3.9: ballistic fire path -- SRM launchers fire salvos + run dry
The SRM6 MissileLaunchers now run the authentic ballistic fire cycle against their linked AmmoBins, wire-verified end to end. - PROJWEAP ProjectileWeaponSimulation (PARTIAL, binary @004bbd04 -- fully recovered in the BT411 RE): one trigger-edge sample; the dry-bin gate pins NoAmmo(7) every frame; Loaded(2) -- the AMMO PULL LIVES IN THE CALLER (a denied shot does the 4->2 denial blip with NO ammo pulled -- early-returning gates from FireWeapon while the caller cycles the alarm is the 1995 "denied shot fakes a full firing cycle" defect class); granted -> Firing -> FireWeapon -> Loading (or NoAmmo on the emptying pull), recoil=rechargeRate; Loading bleeds recoil -> Loaded when a round is chambered, dial animates; Jammed(5) held; NoAmmo(7) = the roach-motel (re-asserts unconditionally). Deferred: electrical step, gate 1, eject, jam roll, HasActiveTarget. - AMMOBIN: FeedAmmo() + GetAmmoState() (1 round-ready / 2 EMPTY). - ammoBinLink wired from the resource's ammoBinIndex (the bin's roster slot). - WIRE-VERIFIED RESOURCE ALIGNMENT: a raw-stream dump pinned the ProjectileWeapon field block +3 ints past our staged struct (the MechWeapon resource ancestry runs 3 ints short -- the pip-family fields). Fixed with resourceAlignPad[3]; phantom muzzleVelocity/missileCount tail dropped. Confirmed on-wire: ammoBinIndex=27/29 (the exact bin slots), tracerInterval=1, minTOF=0.5, minVolt%=0.3, minJam=0.05, missileCount=6 (an SRM6!). - MECHWEAP: weapon-state enum extended to the full 1995 set (DryTrigger 1, Jammed 5, TriggerDuringJam 6, NoAmmo 7; count 8). - MISLANCH FireWeapon PARTIAL (@004bcc60: heat + salvo spawn only -- spawn needs the entity/targeting waves). VERIFIED headlessly (BT_FORCE_FIRE): bins resolve with the authored 24 rounds; SRM6s fire 6-missile salvos at the authored 1s cadence, rounds 24->0; after the 24th salvo the launcher goes DRY and stays silent across ~3,000 subsequent fire events while the energy weapons keep cycling. Zero Fail. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
896bbbed4d |
BT410 Phase 5.3.8: weapon fire path -- authentic attribute table + fire state machine
The energy weapons now run a live fire cycle, and the REAL trigger wiring is in place: the 1995 MechWeapon attribute table (binary @0x511890) is published with PINNED IDs, so the streamed per-mech fire-button mappings bind TriggerState (0x13) -> fireImpulse and the controls push writes the trigger into the weapon. - MECHWEAP: attribute enum + table (PercentDone 0x12, TriggerState 0x13, DistanceToTarget 0x14, TargetWithinRange 0x15, WeaponRange 0x16, EstimatedReadyTime 0x1A, RearFiring 0x1B, WeaponState 0x1C). Pads bridge the chain gap 2..0x11 -- LOAD-BEARING: AttributeIndexSet::Build leaves uncovered gap slots as uninitialized garbage, so every ID up to the max must be covered (they shrink to the authentic 0x0F..0x11 when the parent attribute waves land; SENSOR.HPP pins PoweredSubsystem::NextAttributeID at 0x0F). - MECHWEAP: fire-machine members (fireImpulse/previousFireImpulse, rechargeLevel, rangeToTarget, effectiveRange, estimatedReadyTime, recoil, weaponAlarm 0/2/3/4); CheckFireEdge (@004b9608, BIT-PATTERN int compare -- TriggerState carries raw ControlsButton ints whose release value is a float NaN; IEEE compare would latch the detector shut); ComputeOutputVoltage (@004b9c9c recharge dial). - EMITTER: EmitterSimulation (PARTIAL @004baa88) -- Firing/Loaded/Loading FSM on the weapon alarm, viewFireEnable gate at Loaded->Firing, recoil-decay recharge over the authored RechargeRate seconds; FireWeapon (PARTIAL @004bace8) discharge bookkeeping; ChargeLevel re-pinned to the authentic 0x1D; index re-chained to MechWeapon's. Deferred: electrical charge model (TrackSeekVoltage), heat dump, HasActiveTarget gate, beam/damage submission. - BT_FORCE_FIRE dev hook: trigger pulse whenever Loaded (auto-fire cadence). VERIFIED headlessly: forward view -- PPC_1/2 + ERMLaser_1 cycle FIRED->LOADED at the authored 0.6s/1s cadence, rear lasers silent; BT_FORCE_LOOK=3 -- ONLY the rear lasers (ERMLaser_2/3) fire. The view-fire x fire-FSM interlock holds both directions. Zero Fail. (SRM6 ballistic FSM = a later increment.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
d422dfffc0 |
BT410 Phase 5.3.7: weapon view-fire gating + build header-stamp hardening
Completes the weapon-side half of the look commit: - MECHWEAP: real rearFiring/viewFireEnable members (binary @0x334/@0x3E0) + accessors. Ctor resolves REAR-FIRING authentically (@004b99a8 tail): the mount SEGMENT site name is tested for the 'b' (back) marker -- only the back gun ports (sitelbgunport/siterbgunport) carry it. Spawn = forward-armed. - MECH CommitLookState: re-arms every roster weapon per view (forward = non-rear, LOOK-BACK = rear-mounted, side/down = none) and flips the HUD reticle pip group with the authentic Reticle::Front/RearFiringWeaponsOn flags (BT411's raw "bits 1/2" resolved to their 1995 names). - MECHWEAP: defined MechWeapon::MessageHandlers (0-entry set inheriting the Subsystem chain) -- it was declared-but-undefined, and the surviving CODE PPC.CPP binds the inherited name into PPC::DefaultData; the zero-filled common block was a latent NULL deref (same trap as Emitter::AttributeIndex). Discovery: the TEST.EGG mech genuinely mounts TWO REAR LASERS (ERMLaser_2/3 on the b-ports). Verified on a full-clean baseline (engine 181 + bt 42, 0 fail): look-behind arms exactly the rear lasers, disarms the other five, pipMask=0xfffffffe; neutral run holds forward-armed; zero Fail. build410.sh HARDENED against the stale-obj layout-skew trap this wave exposed: cc() skipped recompiles on obj-vs-.cpp timestamps only, so the MECHWEAP.HPP member additions left emitter.obj on the OLD MechWeapon layout -- its chargeLevel=0.0f write landed exactly on the new rearFiring (a silent cross-TU struct skew, heisenbug-grade). cc() now honors header stamps: a source410 engine-header edit invalidates every bucket, a BT/BT_L4 header edit additionally invalidates the game buckets. CODE/ is immutable, no stamp needed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |