fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

55
docs/re/structures/stage16-boss.md
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.