mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-26 21:36:06 -04:00
10dc6d3635
S1's head family (0x8014032C, 183 ins ×137 = 25,071 templatable ins) gate-failed on its probe sibling. Diagnosis (the §132 ladder, one build): the object emits FOUR tables — BOTH functions in it are multi-switch (8+5 entries each) — while the carve derived THREE starts. The missing start belongs to the ALREADY-MATCHED owner func_8013FFD8, and neither oracle can see it: its stub .s is pruned by extract, and its second table abuts its first with NO pad (8 entries = 32 B = 0 mod 8, so `.align 3` emits nothing) — precisely the honest limit §132's payload zero-word recovery documents. Note the true pads [0,0,4,0] are exactly what natural alignment produces; the build breaks only because a SHORT spec gets written. Fix: thread the documented `--span-tables` escape through the sweep as `--span-rel` — offsets relative to the FIRST NEW table, which func_jtbls reads from the sibling's own .s. Byte-verified family-invariant before use (identical relative offsets on 3 sampled siblings; same code, same entry counts, only the base moves). Empty by default => every other family untouched. Also clears my own §132a guard of suspicion (R14): the --like transfer was inert here regardless (exemplar subseg `ov_SC01_077` vs sibling `_jr_8013FFD8` — roles never matched).