d8dcc1fc295c0e0a404b86f73b2fe3ce84416908
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Sylpheed RE agent
|
302cc9dda9 |
re: the 95 BASE_INFO screens partitioned - BASE_INFO discriminates screen-config from table-read
Item (a): mine the screen population found last iteration. Resolving every one's key list via the string-xref join over its own body gives 298 distinct keys and a three-way split: 95 = 9 corpus-known + 48 new with a readable key list + 38 bare, where "bare" means BASE_INFO and nothing else. The bare 38 are the honest limit of the instrument - a screen whose only catalogued string is BASE_INFO cannot be named this way. The control turned the finding into a law. Only 9 of the 19 loaders the corpus documents appear among the 95, and which nine is not arbitrary. The nine that reference BASE_INFO all read a SCREEN's own configuration: debriefing, career, save, medals, evaluation list, gamma, POINT_RANKING, CLEAR_TIME_RANKING, hangar. The ten that do not all read a DATA TABLE: unit definitions, weapon datasheet, AIParams, stage settings, chatter, PlayerParams, ControlTweak, the PG* HUD roster, material slots, and the leaderboard. 9/9 and 10/10, both off-diagonals empty. The leaderboard falling on the table side is a check rather than an exception - its own doc records that all 18 of its names are tables.pak names, so it is a table reader that happens to paint a screen. That exclusion is what last commit's "universal screen marker" claim was missing. 48 new screens are named by their most distinctive keys, including the title screen (sub_821C4EB0: TITLE_SCREEN/TITLE_MENU/LOADING), the ready room (sub_821D6D28: SCRIPT_ID/SCRIPT_PATH, confirmed independently by its own error string silph::GamePart_ReadyRoom::Impl::PrepareScript), movie subtitles, the three menu modes STANDARD/EXTRA/TUTORIAL, the speaker window, loadout and gallery views, mission select, and an equip screen carrying the game's own typo EQUIIP_LIMITATION. One caution worth recording: a high key count is not a rich screen. The two 27-key entries sub_82297550 and sub_822A2F00 resolve to pure coordinate pairs (1080,163 / 734,502 / 1164,403) - a layout table, not configuration. Read the values before trusting the rank. Still open: the 38 bare screens, and whether the EX_ in EX_MENU_DISABLE_SKIP and EX_LETTERS is the same EXTRA mode word as +184. All seventeen artefacts byte-identical. |
||
|
Sylpheed RE agent
|
03820ec2bd |
re: the RTTI route is dead - BASE_INFO enumerates 95 screens instead
Item (a): can the vtable scan name the corpus's anonymous classes? The route I proposed last turn - "the RTTI behind those two anon classes" - does not exist. Of all 1150 catalogued vtables, 1150 carry an ANON_ class name, 0 have rtti_present set, and 0 have a non-empty base_classes_json. Not one named class, not one RTTI flag, not one base-class edge in the whole table. Withdrawn as unrunnable; the ANON_Class_XXXXXXXX labels are synthesised, not recovered. The sibling methods cannot name a class either: slots 0, 2, 3 and 4 of both EX_ classes reference zero strings. Every naming datum sits in slot 1, the method the corpus already had. Re-verified at the true addresses (0x820A9760 and 0x820A9350) that sub_822814D8 and sub_8227A3A0 are each slot 1 uniquely, and sub_82286BC8 is in no vtable. What the shape DID give: both classes are 5-slot with an exactly-88-byte slot 0. 83 vtables have 5 slots, 16 also have the 88-byte slot 0, 13 of those have a catalogued slot 1, and 10 build a key list. Ranked by key count the two known screens sit at the top and the rest name themselves - a medals screen (MEDALS/ACHIEVED_MEDALS/NEW_MEDAL), an evaluation list (EVALUATION_LIST plus eval_%02d_eval / eval_%02d_points), the gamma screen (GAMMA_RGB/GAMMA_WB), POINT_RANKING, CLEAR_TIME_RANKING, and three bare ones. POINT_RANKING and CLEAR_TIME_RANKING being two separate screens is a direct lead for the open item "which challenge stage is which leaderboard mode": the leaderboard is ranked two ways and each way has its own class. But the obvious follow-on claim - that BASE_INFO marks this family - is false, and the control says so. BASE_INFO is a single string at 0x820A20EC referenced by 95 functions: 10 inside the family, 85 outside, including sub_82286BC8 (the save screen, in no vtable at all) and sub_822AE628 (the hangar loader). So the direction inverts: BASE_INFO is the universal first key of every screen key list, a 95-function population, while the 5-slot/88-byte shape is only a weak filter that catches 10 of them plus 6 non-screens. Enumerate screens by BASE_INFO, not by vtable shape. All seventeen artefacts byte-identical. |
||
|
Sylpheed RE agent
|
e23eea36f7 |
re: the ind_call damage is bounded - no corpus claim was contaminated
The protective sweep after last commit's refutation. The question was which existing claims the ind_call cross product voids. Answer: none of the ones the corpus makes. Every caller-count claim in the corpus verifies against call edges, with zero ind_call contamination: title-crash-stl-tree sub_82457780 "one caller" call=1 ind_call=0 isl-trigger-queue sub_8226EAB8 "16 callers" call=16 ind_call=0 isl-coroutine-spawner sub_822737C8 "seven callers" call=7 ind_call=0 challenge-mission-gate 0x82175110 "22 callers" call=22 ind_call=0 4 of 4 exact, and not one of the four carries a single ind_call edge. There is a structural reason for that rather than luck. Partitioning the two target populations: 1710 targets have ind_call edges, 12170 have call edges, 103 have BOTH, 1607 are ind_call-only, 12067 are call-only. And all 1710 ind_call targets are vtable entries - 1710 of 1710, zero partials - against a control where only 273 of the 12170 call targets are. So ind_call fires only on virtual methods, and 1607 of them have no direct caller at all, which is exactly why the two EX_ screens came back empty on call and flooded on ind_call. The residual risk is narrow and nameable: the 103 targets carrying both kinds, where a caller count taken without a kind filter would be inflated by about 633. Everywhere else the two populations are disjoint, so a call-based count is safe and an ind_call-based one is meaningless. Rule for future work: always filter kind='call'; and when a function has no call edges, that is a fact about it - it is a virtual method - not a gap to be filled from ind_call. All seventeen artefacts byte-identical. |
||
|
Sylpheed RE agent
|
6736786b66 |
re: the +184 writer is blocked - and xrefs.ind_call is a CROSS PRODUCT, not a call graph
Chasing what supplies the EX_ mode word. Two routes, both measured to have no power, plus one structural fact that did come out. The offset route is dead. stw ..., 184(rN) occurs 301 times in the image, lwz from +184 occurs 351 times, and 115 functions touch both +144 and +184. +184 is an ordinary small offset shared by many unrelated classes - the same shape the corpus already recorded as failing three times. Nothing narrows to a writer. The bigger result is an instrument refutation with corpus-wide reach. Asking xrefs for the callers of the two screens returns 633 sources for EACH, and the two lists are IDENTICAL, which cannot be right. Measuring the relation itself: ind_call rows 1827297 distinct targets 1710 distinct sources 6992 targets with EXACTLY 633 sources 236 236 different functions sharing an identical source count is the signature of an unresolved-indirect-call cross product, not of a call graph. Any reading that treats an ind_call edge as "X calls Y" is void, here and anywhere else in the corpus it may have been used. The control shows the other kinds are sound: sub_82286BC8 has exactly one caller, kind call. And both EX_ screens have ZERO non-ind_call edges - they are reached only through function pointers, which is why the direct graph is empty for them. What did come out: scanning the entries of all 1150 catalogued vtables in the flat .pe, both EX_ screens are slot 1 of their own class - sub_822814D8 in ANON_Class_271D5F25 and sub_8227A3A0 in ANON_Class_CAA8AD62 - while sub_82286BC8 is in no catalogued vtable at all. So the 2/0/0/1 partition from the previous commit reflects a structural difference rather than a coincidence: the two screens that select on the mode word are vtable methods of their own classes and the one that does not select is not a vtable method. Still not settled: what writes +184. Both the offset sweep and the call graph are exhausted for it. A route with actual power would be the RTTI behind those two anonymous classes, or a runtime watch on the field - not another static offset search. All seventeen artefacts byte-identical. |
||
|
Sylpheed RE agent
|
d391130577 |
re: the EX_ selection is shown - a mode word at +184 tested against 3
result-screens.md left this explicitly open: "the selection has not been shown".
It is shown now. Both screens that reference EX_ names carry the same
five-instruction idiom immediately before the choice - sub_822814D8 at 0x822815b4
and sub_8227A3A0 at 0x8227a408:
lwz r11, 4(rX) the owning object
lwz r11, 184(r11) a mode word at +184
addi r11, r11, -3
cntlzw r11, r11
rlwinm r11, r11, 27, 31, 31 r11 = 1 iff [+184] == 3
cmpli cr6, 0, r11, 0x0
bc 12, 4*cr6+eq, <plain> not 3 -> STAGE_RESULT / OVERVIEW
else -> EX_STAGE_RESULT / EX_OVERVIEW
cntlzw of zero is 32, and rotating left 27 lifts bit 5 into bit 31, so the
sequence is a branchless equals-3 test. The equal-to-zero branch takes the plain
name, so EX_ is chosen exactly when the word is 3.
A partition over the three key-list loaders the corpus already names:
loads +184 does not
references EX_ names 2 0
does not 0 1
sub_822814D8 and sub_8227A3A0 both load it; sub_82286BC8, which references no EX_
name, has no +184 access at all. Both off-diagonal cells are empty.
3 is the game's own EXTRA. challenge-mission-gate already established the
vocabulary for this constant at a three-way switch: == 3 is EXTRA, == 5 or 6 is
CHALLENGE, otherwise FILE. So the prefix reads literally - EX_ is the EXTRA
variant.
That REFINES the doc's tentative reading rather than confirming it. The section
proposed "EX_ = the challenge-mission debriefing" by analogy with _EXn on asset
names; the measured constant is EXTRA, which in the game's own three-way
vocabulary is a DIFFERENT kind from CHALLENGE (5/6).
Boundary of what was measured: the EXTRA = 3 constant is established at +144 of
the stage-loader class, while the word tested here is at +184 of [object + 4].
Same constant and the same EX/EXTRA naming, but two different offsets in what may
be two different objects - that the two fields are the same field is NOT shown,
only that both compare a mode word against 3.
All seventeen artefacts byte-identical.
|
||
|
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. |
||
|
Claude (auto)
|
67b04a945e |
re: the debriefing and pilot-record screens; the save-screen block was already owned
Read-before-claiming caught one of the three. savegame-format.md already documents the shape AND this exact list -- the LOAD/SAVE screen's config key list is compiled into the executable as a pointer array of key strings, run starting 0x820A0074. sub_82286BC8's 18 names are that list (17/18 are a tables.pak field or record). Nothing new; residual PLAYER_AMMO_LESS_10, not a tables.pak name. The other two are new screens of the same shape and they close exactly. All names resolve into tables.pak: sub_822814D8 24/24, sub_8227A3A0 21/21. sub_822814D8 = the debriefing screen. 24 = 2 screen ids (STAGE_RESULT, EX_STAGE_RESULT) + 21 stage_* fields + one sound cue (SE_BOSS_CORE_CHARGE); the tables.pak STAGE_RESULT record has exactly 21 fields. sub_8227A3A0 = the pilot record / career screen. 21 = 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+21+1 = 24 and 5+7+9 = 21, with 21/7/9 measured independently off the pak. The debriefing readout is nine num/points pairs plus three points-only lines: kills by class, objectives, clear time, shoot-down ratio and both damage categories carry a raw count and its score contribution, while friendly_fire, shoot_down_others and weight have no counter column -- the same partition mission-scoring.md measures on the settings side. OVERVIEW is the seven EX_OVERVIEW fields plus overview_rank and overview_medals. Not settled: what EX_ means (its ids have no record of that name), and PLAYER_AMMO_LESS_10. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE |