Files

Sylpheed RE agent 4b676fc2e9 re: _EXn is the n-th challenge stage; the Extra0n join is refuted

Reading the docs first paid: unit-substructure-records already had
UN_e001_ADAN_Elan_EX4 and arsenal-item-weapon-chain already had _T_EX5_el, so
last pass's "the only two _EX5 names on the disc" was too narrow. Withdrawn and
replaced by a census.

Every name ENDING in _EX<digit> across all 41 archives, taken from parsed IDXD
record names, field names and string values (never a raw byte scan): 26 names,
two digits only - _EX4 (7 units, 6 ADAN + 1 TCAF) and _EX5 (4 TCAF units + 1
weapon), each with a UnitName_/WeaponCannonName_ twin.

The stage join is exact. _EX4 appears only in tables S27 declares
(EnumUnit_S27.tbl, UnitGroup_S27.tbl); _EX5 only in S28's (EnumUnit_S28.tbl,
UnitGroup_S28.tbl, EnumWeapon_EX5.tbl); the other 20 stages have neither. The
challenge missions are S24-S29 in order, so S27 is challenge #4 and S28 is
challenge #5: _EXn names the n-th challenge ("EXtra") mission's bespoke
variants. S28 declares both schemes at once - EnumUnit_S28.tbl by stage number,
EnumWeapon_EX5.tbl by challenge index, for the same mission.

Refuted: _EXn is not the Extra0n numbering. There are four Extra slots but _EX5
exists, and under that reading Extra04 would be S29, which has no _EX assets.

Makes available but does not settle result-screens' open "what does EX_ mean":
"the challenge-mission debriefing" fits its evidence that the EX_ twin drops
overview_rank/overview_medals. Recorded there as a reading, not adopted.

All fifteen artefacts byte-identical.

2026-08-28 04:34:11 +00:00

4.3 KiB

Raw Blame History

✅ The debriefing and pilot-record screens — `STAGE_RESULT`, `OVERVIEW`, `EX_OVERVIEW`

Where: tables.pak (the menu config pak), records STAGE_RESULT, OVERVIEW, EX_OVERVIEW; key lists compiled into the executable at sub_822814D8 and sub_8227A3A0 (found by the base-solver, player-tuning-tables).
Related: mission-scoring owns the rules (Score_* in the stage settings); this is the readout. savegame-format documents the same compiled-key-list shape for the LOAD/SAVE screen.

The shape was already known — for other screens

savegame-format establishes it: "the LOAD/SAVE screen's config key list is compiled into the executable, as a pointer array of key strings — the same shape as the Arsenal's (whose keys sit a few hundred bytes earlier and match the pak record exactly)", run starting 0x820A0074. sub_82286BC8's 18-name block is exactly that list — 17 of its 18 are a tables.pak field or record name, so it is the documented save-screen list and nothing new. Its lone residual is PLAYER_AMMO_LESS_10, which is not a tables.pak name at all.

✅ Two more screens, and the key lists match their records exactly

block	names	all present in `tables.pak`?
`sub_822814D8`	24	24 / 24
`sub_8227A3A0`	21	21 / 21

And the arithmetic closes against the records themselves:

sub_822814D8 = the debriefing screen. 24 names = 2 screen ids (STAGE_RESULT, EX_STAGE_RESULT) + 21 stage_* fields + one sound cue (SE_BOSS_CORE_CHARGE). The tables.pak record STAGE_RESULT has exactly 21 fields (2 objects, both 21).
sub_8227A3A0 = the pilot record / career screen. 21 names = 5 screen ids (LAST_RESULT, EX_BASE, EX_MAIN, EX_OVERVIEW, OVERVIEW) + 7 ex_overview_* + 9 overview_*. The records EX_OVERVIEW and OVERVIEW have exactly 7 and 9 fields (2 objects each).

2+21+1 = 24 and 5+7+9 = 21, with 21/7/9 measured independently off the pak.

The debriefing readout, in full

stage_num_shoot_down_aircrafts   stage_points_shoot_down_aircrafts
stage_num_shoot_down_ships       stage_points_shoot_down_ships
                                 stage_points_shoot_down_others
stage_weight_shoot_down
stage_num_main_objectives        stage_points_main_objectives
stage_num_sub_objectives         stage_points_sub_objectives
stage_clear_time                 stage_points_clear_time
stage_shoot_down_ratio           stage_points_shoot_down_ratio
stage_damages_friendly_ships     stage_points_damages_friendly_ships
stage_damages_wingman            stage_points_damages_wingman
                                 stage_points_friendly_fire
stage_total_points               stage_rank

🔑 Nine num/points pairs plus three points-only lines — the screen shows a raw count and its score contribution for kills by class, objectives, time, ratio and both damage categories; friendly_fire, shoot_down_others and weight have no counter column. That is the same partition mission-scoring measures on the settings side.

The career readout

overview_points, _total_play_time, _clear_stages, _retry_times, _shoot_down_aircrafts, _shoot_down_ships, _shoot_down_weight — seven, and OVERVIEW adds overview_rank and overview_medals. The EX_ twin has the seven and neither of the two, which is what makes EX_ the reduced variant rather than a different screen.

🟡 Not settled: what EX_ means (a second profile? the online/leaderboard variant?) — but see stage-numbering-and-player-craft: _EXn on an asset name is measured to mean "the n-th challenge mission", which makes "EX_ = the challenge-mission debriefing" a consistent reading of why this twin drops overview_rank and overview_medals. Not adopted — the selection has not been shown — EX_BASE, EX_MAIN, EX_STAGE_RESULT and EX_FONT are keys with no record of that name, so the prefix is a screen-id convention, not a table. And PLAYER_AMMO_LESS_10 is unexplained.

Reproduce: parse tables.pak with tools/re-capture/unitgroup.py and count the fields of the three records; take the key lists from the sub_822814D8 / sub_8227A3A0 / sub_82286BC8 sections of ../data/name-block-bases.txt.

4.3 KiB Raw Blame History

✅ The debriefing and pilot-record screens — STAGE_RESULT, OVERVIEW, EX_OVERVIEW