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>
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