re: the S16 boss's frames and motions; attackC is a cut attack

sub_823BDAA8, the next boss piece.  The subsystem is a linear chain, one call site
each: sub_82385D48 -> sub_823AE908 (collision pairs) -> sub_823BDAA8 (frames +
motions) -> sub_823C0260 (hull part list).

r11, 33 names = the attach-frame roster, partitioning exactly: 15 hull frames + 9
muzzles (GN_MainGun_01_MuzC and GN_MainGun_02_Muz01..08 -- one gun with a centre
muzzle, one with eight) + 1 shield + 3 gear + 5 model ids = 33.  The 15 hull
frames are the same 15 the collision table pairs, and rou_e901_body_01 is present
here -- the one whose _c mesh the collision list did not carry.

r10, 25 names = a SUBSET of the disc's motion set.  The disc object is DefTables
2ef95cdd: 58 records = 3 structural + 55 motions; all 25 code names are in it
(25/25); 30 disc motions are not in the code block.

A reading I nearly published, refuted by checking the other population: in the
code block Motion_guard_start stands alone while every other stem carries _b1/_b2,
which looks like the exception.  It is not -- the disc has guard_start_b1/_b2 plus
guard_keep and guard_end with their variants.  The asymmetry is in the code's
list, not the data.

attackC is a third boss attack the executable never names.  Most of the 30 omitted
motions do exist as strings elsewhere (Motion_guard_keep, Motion_dead,
Motion_break, Motion_damage01 -- one row each), but the whole
Motion_attackC_{start,keep,end,charge} x {,_b1,_b2} family, 12 names, has 0 string
rows, against two identically-shaped controls at 3/3 (attackA_charge,
attackB_charge).  The boss ships with an animated third attack pattern no code
path can select by name.

Not settled: whether attackC is reachable by index rather than name, and what
eff_s900_e_Charge attaches to.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Claude (auto)
2026-08-27 23:45:28 +00:00
parent e548db693e
commit 24c3168768
2 changed files with 97 additions and 0 deletions

View File

@@ -5418,3 +5418,45 @@ positionally or are dead data is not settled.
🟡 Not settled: the other four shortlisted rows (`sub_823BDAA8` r11/r10 muzzle
frames + motion names, `sub_8219E560` leaderboard keys, `sub_825F2CF0`/
`sub_825F2F88` post-processing) are still unopened.
---
## ✅ 2026-08-27 — the S16 boss's frames and motions; `attackC` is a cut attack
Item (a): `sub_823BDAA8`, the next boss piece. Written into `stage16-boss.md`.
Static only; no artefact changed.
**The boss subsystem is a linear chain**, one call site each:
`sub_82385D48``sub_823AE908` (collision pairs) → `sub_823BDAA8` (frames +
motions) → `sub_823C0260` (hull part list).
**`r11`, 33 names = the attach-frame roster**, partitioning exactly:
**15** hull frames + **9** muzzles (`GN_MainGun_01_MuzC` and
`GN_MainGun_02_Muz01…08` — one gun with a centre muzzle, one with eight) + 1
shield + 3 gear + 5 model ids = 33. The 15 hull frames are the same 15 the
collision table pairs, and **`rou_e901_body_01` is present here** — the one whose
`_c` mesh the collision list did not carry.
**`r10`, 25 names = a SUBSET of the disc's motion set.** The disc object is
`DefTables` `2ef95cdd`: **58 records = 3 structural + 55 motions**; all 25 code
names are in it (25/25); **30 disc motions are not in the code block.**
⚠️ **A reading I nearly published, refuted by checking the other population.** In
the code block `Motion_guard_start` stands alone while every other stem carries
`_b1`/`_b2`, which looks like *the* exception. **It is not** — the disc has
`guard_start_b1`/`_b2`, plus `guard_keep` and `guard_end` with their variants.
The asymmetry is in the code's list, not the data.
🔑 **`attackC` is a third boss attack the executable never names.** Most of the 30
omitted motions *do* exist as strings elsewhere (`Motion_guard_keep`,
`Motion_dead`, `Motion_break`, `Motion_damage01` — one row each), but the whole
**`Motion_attackC_{start,keep,end,charge}` × `{,_b1,_b2}` family — 12 names — has
0 string rows**, against **two identically-shaped controls at 3/3**
(`attackA_charge`, `attackB_charge`). The boss ships with an animated third
attack pattern no code path can select by name — the same
disc-carries-what-code-never-names shape as `InitHight`, but a whole behaviour
rather than five parameters.
🟡 Not settled: whether `attackC` is reachable by index rather than by name; what
`eff_s900_e_Charge` attaches to; and the other three shortlisted rows
(`sub_8219E560` leaderboard, `sub_825F2CF0`/`sub_825F2F88` post-processing).

View File

@@ -56,3 +56,58 @@ this is not an extraction artefact. **The disc carries fields no code names**
the mirror image of the usual trap (a loader naming a field the disc never
values). 🟡 Whether they are read positionally, or are simply dead data the
designers left in, is not settled.
## ✅ The frame roster and the motion set — `sub_823BDAA8` (2026-08-27)
1 442 instructions, **one** call site, and it sits in a linear chain:
```
sub_82385D48 → sub_823AE908 (collision pairs) → sub_823BDAA8 (frames + motions)
→ sub_823C0260 (hull part list)
```
**`r11`, 33 names — the attach-frame roster**, and it partitions exactly:
| | |
|---|---:|
| hull frames `rou_e901_{body_01..03, tail_L/R, wing_01_L..05_R}` | **15** |
| muzzles `GN_MainGun_01_MuzC` + `GN_MainGun_02_Muz01…08` | **9** |
| `GN_Shield_01` | 1 |
| `GN_CollisionGear_01…03` | 3 |
| model ids `rou_e901`, `rou_e910_core`, `mob_n900`, `eff_s900_e_Charge`, `Default` | 5 |
`15+9+1+3+5 = 33`. The 15 hull frames are the same 15 the collision table pairs,
and **`rou_e901_body_01` is here** — the one whose `_c` mesh the collision list
did not carry. One main gun with a single centre muzzle, a second with **eight**.
**`r10`, 25 names — a SUBSET of the disc's motion set.** The disc object is
`DefTables` `2ef95cdd`: **58 records = 3 structural (`Generic`, `EnumMotions`,
`ReferenceFrames`) + 55 motions.** All 25 code names are present in it (25/25),
and **30 disc motions are not in the code block**.
⚠️ **A reading I nearly published, refuted by looking at the other population.**
In the code block `Motion_guard_start` stands alone while every other stem has
its `_b1`/`_b2` damage variants — that looks like the exception. **It is not:**
the disc has `Motion_guard_start_b1`/`_b2` (and `guard_keep`, `guard_end` with
their variants). The asymmetry is in the *code's list*, not the data.
### 🔑 `attackC` is a third boss attack the executable never names
Of the 30 disc motions the block omits, most **do** exist as strings elsewhere in
the image (`Motion_guard_keep`, `Motion_guard_start_b1`, `Motion_dead`,
`Motion_break`, `Motion_damage01` — one row each). But:
| family | names | string rows |
|---|---:|---:|
| `Motion_attackC_{start,keep,end,charge}` × `{,_b1,_b2}` | 12 | **0** |
| **control** `Motion_attackA_charge` × 3 | 3 | 3 |
| **control** `Motion_attackB_charge` × 3 | 3 | 3 |
**The whole `attackC` family is animated on the disc and named nowhere in the
executable**, with two identically-shaped families as controls. The boss ships
with a third attack pattern that no code path can select by name — the same
disc-carries-what-code-never-names shape as `InitHight` above, but here it is a
whole behaviour rather than five parameters.
🟡 Not settled: whether `attackC` is reachable by index rather than name, and
what `eff_s900_e_Charge` (the only effect id in the roster) attaches to.