df51101faf83648bd87c02f99f79be36ff37583d
15 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Sylpheed RE agent
|
2a731aa8b7 |
re: the Time/Points record is not on the debriefing path - and a ring drainer matches the message bus
Read 0x821A0AD0, the debriefing, end to end, resolving every call and string in code order. The word-B bit-setter sub_8219F2E8 is its FIRST call, before anything else; the function makes 44 calls and references exactly two strings, DEBRIEFING and BASE_INFO. No Time and no Points anywhere on this path - not in the debriefing, not in the bit-setter. Section 5.3's expectation that clearing a challenge stage records its metric alongside the bit is not supported by the code that clears it. The reach of that negative: the debriefing function and its directly-called bit-setter, both read whole; it does not rule out a store deeper inside one of the other 43 callees. 0x8219F670 turns out to be an online-state predicate: 88 bytes, no strings, reads the singleton, tests bit 1 of [0]+60, and if set passes [0]+64 to 0x824A9C90 and returns whether the result is 2. A connection or sign-in check, not a record store. The useful find is 0x8219F460, 368 bytes and self-recursive, which drains a ring based at r29+320 with element base +4, capacity +8, head +12 and count +16. Those are the corpus's documented message-bus offsets exactly - BACKLOG records sub_82175C20(bus+4, &msg) as a ring-buffer append with capacity +8, head +12, count +16 - and sub_82175C20 is the very notifier section 5.6 found the word-B writer calling with bit + 64. So the open question "ring-buffer PUSH, no handler" now has a candidate drainer with a byte-for-byte matching field layout, reached from the debriefing. What is NOT shown is that these are the same ring instance. The push targets bus+4, this drain targets r29+320. Matching offsets prove a shared container shape, not a shared object, and the identity needs the two base pointers tied together. All seventeen artefacts byte-identical. |
||
|
Sylpheed RE agent
|
bae2fcf623 |
re: progress word B's writer is sub_8219F2E8 - it sets bit (stage - 24)
Section 5.5 narrowed the search to 21 functions but could not name one, because the scan assumed the copy destination was an r1-relative stack local. It is not. Reading the known word-A writer instead of guessing its shape shows a frame register: bl singleton, addi r3,r31,96 (dest), addi r4,r11,80 (src = obj+80), bl copier, stw r10,96(r31). That one wrong assumption made the first scan return 0 for all 21, the known-good included - the third filter this week killed by its own control. With the real shape - addi r3,rF,K before the copier, then stores at K+d on rF - word B sits at d = 1956-80 = 1876, and exactly one of the 21 hits: sub_8219F2E8, copy dest r31+560, storing 2436(r31), and 560+1876 = 2436. Control: the word-A writer 0x821C1630 stores at relative +0, i.e. word A. The proof is the bias. Word B's writer computes addi r11,r11,-24 then 1 << (index-24) before or-ing into the copy; word A's writer shifts by the raw stage number with no bias. That reproduces section 5.1's read-side rule - n >= 24 means bit (n-24) of word B - on the write side, so word B's bits 0-5 are challenge stages 24-29, the same six that 5.4's MISSION_ID names. The two writers are exact complements. It has exactly one real caller, 0x821A0B1C inside 0x821A0AD0, whose strings are BASE_INFO and DEBRIEFING - so clearing a challenge mission is recorded from the debriefing screen. A second bitfield falls out of the same function: it reads the copy at +1880 (2440(r31) = obj+1960, the word after B), re-reads obj+1960 after the setter, xors old against new, and loops the 32 result bits calling 0x82175C20 with bit + 64. So obj+1960 is a second 32-bit progress bitfield with ids 64-95, whose newly-set bits are announced one at a time - an unlock-notification loop. Against 5.3's own prediction: neither sub_8219F2E8 nor its caller references Time or Points, 0 for both. 5.3 expected word B's writer to also store the stage's Time/Points record. It does not - this is the bit-setter only, and the record store is still unlocated. All seventeen artefacts byte-identical. |
||
|
Sylpheed RE agent
|
5d44b52b07 |
re: progress word B - search space closed at 21 functions, the field itself still unwritten
Section 5.3 left word B (+1956) with no known writer. Three routes ran this turn: one produced a population, two were refuted, and the field is still unwritten. The offset route has power here, unlike +184. +1956 is a large unusual offset with 9 stores and 28 loads image-wide, against +80's 5403 and 6923. Control: the known reader 0x821898C4 sits in the gate's list-builder 0x82189870, exactly where 5.1 puts it. But none of the 9 stores turns out to be a progress write - filtering by whether the storing function reaches the progress object gives 0 of 8 distinct functions, and the 9th stores through r1, the stack pointer, so it is a local. +1956 is simply an offset several unrelated structures also use. The obvious filter is dead, and it fails its own control. Testing "does the function reference the singleton global 0x828F48B0 or call 0x821707C0" against the KNOWN word-A writer returns no contact, because that path reaches the progress object through the copier and never through the global. A filter that rejects the known-good answer proves nothing about the others. What did work: progress is only ever changed copy-modify-store, so every writer must call both the copier 0x82175110 and the setter 0x8216FF70. Measured, 21 functions call the setter, 21 call the copier, and 21 call both - the two caller sets are the same set. That is the complete progress-write population and it is small enough to read exhaustively. Control: the word-A writer is among them as 0x821C1630 (BASE_INFO + DIFFICULTY), and 5.2's store 0x821C1820 lies inside it - the doc's 0x821C09D8-0x821C29F0 is the enclosing method, 0x821C1630 the function. No member of the 21 stores to +1956 directly. Their only large store offsets are into this - 1004, 1980, 2040, 2100, 2199, 2436 - with 1004 being 5.2's own this+1004 & 0x20000 guard. So word B is written through the stack copy, at localbase + 1876, which no offset scan can pick out. One false friend worth recording: two of the 21 reference Points, which looks exactly like the challenge record-storing path 5.3 predicts. It is not - their full string sets are Dependency, MissionObjective, Points, WEAPON, WEAPONS, i.e. the arsenal development economy, and neither references Time. There are two Points vocabularies, development points and the leaderboard metric. Next candidate, not yet checked: 0x8218EFE0 is the one progress writer whose strings are BASE_EXTRA and DIFFICULTY - the only member of the 21 carrying the EXTRA vocabulary. All seventeen artefacts byte-identical. |
||
|
Sylpheed RE agent
|
64ea85ee7f |
re: which challenge stage is which leaderboard mode - CLOSED from the record's own fields
challenge-mission-gate.md section 5.3 left a marked 🟡 on the exact pairing and named
the right route: read the record's binary index section rather than the string pool.
Running that with the corpus's own reader settles all six missions at once.
TimeAttack MISSION_ID 24 REQUIREMENT 16 RECORD_TYPE Time
ScoreAttack MISSION_ID 25 REQUIREMENT 24 RECORD_TYPE Points
Extra01 MISSION_ID 26 REQUIREMENT 25 RECORD_TYPE Points
Extra02 MISSION_ID 27 REQUIREMENT 26 RECORD_TYPE Time
Extra03 MISSION_ID 28 REQUIREMENT 27 RECORD_TYPE Time
Extra04 MISSION_ID 29 REQUIREMENT 28 RECORD_TYPE Points
Control: the table appears in 6 pak entries, all in tables.pak, and all six are the
same table byte for byte - one per language, i.e. one user under the per-pak copy
rule. Zero variants.
Three things fall out, none of them assumed. MISSION_ID is the stage number: the six
IDs are 24-29 in slot order, exactly the six challenge stages S24-S29, bijectively -
so the "four Extra0n modes against five _EXn stages" worry dissolves, because _EXn is
a unit-variant suffix that indexes nothing here. REQUIREMENT is a strict chain, 16,
24, 25, 26, 27, 28, each mission requiring the previous one's stage with TimeAttack
anchored on stage 16, the final story mission; 5.3 inferred a chain from the shape of
the string pool, and it is now exact and branchless. RECORD_TYPE is the leaderboard
metric and it is per-stage, not per-name: 3 Time (S24, S27, S28) and 3 Points (S25,
S26, S29), so the tempting reading that the Extra0n family shares one metric is
wrong - Extra01 and Extra04 are Points while Extra02 and Extra03 are Time.
Withdrawn from 5.3: the string-pool reading listed the numeric tokens as 16, 25, 26,
27, 29 with 24 and 28 deduped away. The real REQUIREMENT set is 16, 24, 25, 26, 27,
28 - 29 is a MISSION_ID, never a requirement. A value pulled from a deduped pool by
adjacency got one member wrong; the indexed read has no such failure mode.
Left as an association rather than a proof: RECORD_TYPE takes exactly the two values
Points and Time, and result-screens names two ranking screens POINT_RANKING and
CLEAR_TIME_RANKING, but no code path has been shown selecting one screen from that
field.
All seventeen artefacts byte-identical.
|
||
| 4c8be12796 |
re(challenge): the part id is never persisted -- differential search says stack only
No literal 26 exists anywhere, so the GamePart id is computed. That does not stop it being found: the id is KNOWN at each screen from the GamePart table (EXTRAS = 5, MISSION SELECT = 7), so snapshot both and intersect. New tool diff_words.py does the classic differential search over the sparse guest image, and find_partslot.sh drives the two screens and runs it. Result: 171 MB scanned, exactly 4 addresses read 5 then 7 -- 0x708FFBEC, 0x708FFCBC, 0x708FFDAC, 0x708FFE20 -- and all four are guest STACK (the same run's log puts thread stacks at 0x709...). So the requested part id exists only as a stack argument in flight; there is no persistent field, which is consistent with finding no literal store, and means there is nothing stable to poke. That closes the last memory-and-menu route to the challenge missions. Reaching them needs either the genuine in-game unlock (an in-mission attainment, per AVSCRIPT_COMMAND_ATTAINMENT_CHALLENGE_MISSION_CARGO_SCORE) or an emulator-side hook that forces the transition -- a code change, not a poke. diff_words.py is worth keeping well beyond this question: it locates any field whose address is unknown but whose value is known at two moments. |
|||
| 6c332b4038 |
re(challenge): withdraw the kind-field constructor attribution -- snapshot refutes it
Section 4 claimed the mission-kind field at obj+144 "is initialised to 0 in the
constructor sub_821783D8, alongside +148 = 0, +132 = 2, +136/+140 = -1". That
linked two code regions on nothing more than both touching +144/+148, and an
in-flight snapshot refutes it:
sub_821783D8 initialises the STATIC at 0x828F3EC0 -- its first act is
InitializeCriticalSection(obj, 256) -- and in the snapshot that object holds
0x000B1C8B at +144 and a float at +592. Not a kind, not flags. So the object that
owns the kind field is UNIDENTIFIED. Scanning the snapshot for it (kind in
{0,3,5,6} at +144, stage 10 at +148, pointers at +0/+52/+604) returns only
matches inside the executable's own static data; the value 10 at +148 is far too
common to discriminate.
The switch itself stands -- it is direct disassembly at two independent sites
(0x82184df0, 0x82185ed0) plus two grouping tests. Only the attribution was wrong,
and the wrong half is the half I inferred rather than read.
Confirmed on screen instead: launching a story stage from MISSION SELECT reaches
a READY ROOM carrying an "EXTRA" watermark -- the EXTRA config section, kind 3,
visible in the UI. Independent evidence the field means what section 4 says even
though its owning object is not pinned.
|
|||
| b691841d5a |
re(challenge): poking unlocks the whole story campaign; MISSION SELECT is story-only
Two results from the running game, one positive and one a clean negative. POSITIVE: with word A = 0x0001FFFE (stages 1-16) every entry Stage01..Stage16 is selectable, where the control run had only Stage01 and the rest greyed. Stage16 reads "Lonely Blue Planet - NO RECORD". So any story stage can be launched from the menu by poking one word, with no save editing at all -- a simpler lever than the GHAD stage-field patch used until now. NEGATIVE: with word B = 0x3F (challenge stages 24-29 marked cleared) the list still saturates at Stage16 -- the cursor stops there and further presses do nothing. That matches the disc: the debriefing config declares exactly px_deb_stage01..16, so the list is capped by data, not by the mask. The challenge missions are NOT reachable through MISSION SELECT, and word B does not feed it. Also mapped, without finding the caller: the GP_DIALOG registry (tables.pak #41) gives DLG_GO_CHALLENGE_MISSION_MENU = 41 and DLG_CHALLENGE_MISSION_AVAILABLE = 42 (0-based, in config order). No raw immediate 41/39/37 appears anywhere in the GamePart code region, so dialogs are raised through a computed index and the entry point to GamePart 26 is still unknown. New probe: examples/screen_configs.rs dumps any tables.pak screen config by substring. |
|||
| cada72c9a4 |
re(challenge): MISSION SELECT renders the cleared-stage mask, and a control run
With word A = 2 the screen lists Stage01 SELECTABLE, carrying a High Score and a
Best Time, and Stage02-Stage08 GREYED OUT. One cleared stage, one selectable
entry, at the bit index that names it -- the mask's meaning is now visible on
screen rather than inferred from disassembly.
Two runs, identical navigation, fresh boot each:
control word A 0x00000002 -> MISSION SELECT opens normally
poked word A 0xFFFFFFFF -> MmAllocatePhysicalMemoryEx fails on 128 MB,
guest throws, Xenia shows "Disc Read Error"
So last commit's heap failure was caused by the poke, and by a careless one:
0xFFFFFFFF claims stages that do not exist (0, 17, 24-31 in word A). Poking only
real story ids (0x0001FFFE = stages 1-16) does not blow the heap. That the list
screen changes behaviour with the mask is itself evidence word A feeds it.
Getting a trustworthy control took three tries, and every failure produced a
plausible wrong answer rather than an error:
1. the title-glyph oracle fired during the ATTRACT MOVIE, so A was pressed at
nothing and the run "reported 0 failures" for a screen it never reached;
2. Xvfb keeps the previous instance's framebuffer until the new one draws, so
a screenshot seconds after launch showed the OLD run -- "MAIN MENU reached
after 1s", against a process that no longer existed;
3. a single-pixel "is NEW GAME white?" test matched a white LOADING FLASH.
Fixes, all in challenge_probe.sh: blank the root and refuse screen oracles for
the first 40 s; identify a screen by a PATTERN of sampled points (white text AND
the dark panel behind it), not one pixel; require two consecutive samples. The
new oracle was validated offline against all six saved screenshots and accepts
exactly the one real main menu.
General lesson worth the words: a navigation oracle that can only fail by
returning the wrong screen will happily produce a whole run of confident,
meaningless results.
|
|||
| 9d8898382e |
re(challenge): the cleared-stage mask is CONFIRMED on the running game
Booted the title and read the two gate words live:
0x828F40C0 = 0x00000002 word A
0x828F4814 = 0x00000000 word B
Word A = 2 = bit 1. The profile's save is Stage 02 "At Standby" -- stage 01
cleared -- so the mask is exactly one bit, at the index of the one cleared
stage, 1-BASED. Reproduced across two cold boots. That confirms against a known
progress state, on the real game:
- the singleton is the static object at 0x828F4070, as derived statically;
- word A is a cleared-stage bitmask (not achievements, not a stage number);
- bit index = stage id, 1-based, so TimeAttack's REQUIREMENT 16 means "clear
stage 16" -- the last story mission;
- word B is the challenge half and is 0 on a story-only profile.
New tools: gpoke.py (live guest-memory WRITE, companion to gmem.py, prints
before/after for every word), pad.py (drives the new --hid=file pad; replaces
vgamepad, which leaked to the host through /dev/uinput), challenge_probe.sh
(one blocking session: boot, wait for title, drive in, poke, screenshot).
Poking both words did NOT surface a challenge entry in EXTRAS -- and that menu
was built 26 s after the poke, so it is not staleness. Entering MISSION SELECT
then failed, but the log names the real cause and it is not the gate:
MmAllocatePhysicalMemoryEx could not satisfy a 128 MB request (parent free
30633/131072 pages), the guest threw a C++ exception, and Xenia surfaced its
generic "Disc Read Error". It is preceded by "BaseHeap::Release failed because
address is not a region start" -- a failed release leaking the range. Recorded
as an emulator heap problem, with the control run (same navigation, no poke)
named as the next step.
|
|||
| 6ea3f60979 |
re(challenge): both gate words are one ~1880-byte record, and it is not the save
Two results, one of which kills an operational hope I had been carrying. THE RECORD IS MUCH BIGGER THAN I MEASURED. Reading 0x82175110 to the end: after the two words, the 8-byte pair, the 184-byte memcpy and the 8 words at +200, it copies 816 bytes at +232, 816 more at +1048, a sub-object at +1864 and a final word at +1876. So the record spans +0..~+1880 = singleton +80..+1960, which means word A is record +0 AND WORD B IS RECORD +1876. That retires last commit's "word B has no known writer": there is no separate store because the whole record is copied out, modified and assigned back as a unit (0x8216FF70 -> compare 0x822C3708, assign 0x82170650, then a worker 0x821700A8 -- note 168 decimal, not hex, which I misread first time -- retrying a commit 0x822C33B8 up to five times). IT IS NOT THE SAVEGAME, by two independent checks: - size: every real save on disk is a 276-byte container deflating to 545 bytes; the record is ~1880. It does not fit. - files: after many sessions the content tree holds only game0N/savedata and game0N/__thumbnail.png per slot plus three Headers/*.header. No second data file exists anywhere under the title id. Also negative: the savegame object is *(*(this+4)) + 304, and the singleton's holder address 0x828F48B0 is referenced NOWHERE outside the accessor, so this+4 is a different holder -- the save block is not a window into this record. => Hand-editing a save cannot unlock the challenge missions. The earlier savegame-editing win does not extend here. WHAT WOULD WORK. The singleton is a static object at 0x828F4070 (0x8216F650: addis 0x828F + addi 16496), so the gate words sit at fixed guest addresses with no scanning: word A = 0x828F40C0, word B = 0x828F4814. Canary maps guest RAM into /dev/shm and the project already reads it live, so writing 0xFFFF / 0x3F there while the title sits on a menu should open all six challenge missions without playing the campaign -- the route to the last 42 EX units. Untested; needs a run. |
|||
| cb677fe34f |
re(challenge): the gate is CLEARED STAGES -- my achievement reading was wrong
Third revision of this claim, and this one has the writer.
Word A (singleton +80) has exactly ONE writer in the image. Scanning all 22
callers of the +80 struct copier (0x82175110) for one that stores to the copy's
word 0 gives a single hit, 0x821C1820, inside GamePart_StageClear:
if (this+1004 & 0x20000) skip ; already recorded
copy local = singleton->progress ; src = obj+80
local.word0 |= 1 << (this+84)
if changed: singleton->set(local) ; assign + async persist
and this+84 is the STAGE NUMBER, by two independent uses: 0x821C1760 indexes a
20-byte per-stage record array with it (this + (x+7)*20, three words plus an
8-byte timestamp -- the savegame's 16x20 SHAB shape), and 0x821C1EEC/0x821C1924
pass it as the index into the config key "STAGE" (0x820A2540), the debriefing's
px_deb_stage01..16 sprite list.
So a challenge mission's REQUIREMENT n means "stage n has been cleared", and the
<24 / >=24 split is the disc's own stage numbering: story 1-16 and tutorial 18-23
in word A, challenge 24-29 as word B bits 0-5. TimeAttack needs stage 16 -- the
last story mission -- and the other five chain off challenge stages 25-29. That
is what the raw numbers suggested in the first place.
REFUTED: "the bit space is the game's 24 achievements". ACHIEVEMENTS_REQUIREMENTS
having 24 entries and the gate splitting at 24 is a COINCIDENCE -- 24 is also the
first challenge stage's id. Nothing copies the Debriefing's masks (+208/+736/+740)
into +80, which is the check that should have preceded the claim.
The achievement work itself stands and is kept, retitled and rescoped in
structures/achievements.md: the XACH table (.pe 0x8FBCBC, 36-byte records,
1000G self-check), the 24 names/descriptions, the on-disc ACHIEVEMENTS_REQUIREMENTS
list, and the XACHIEVEMENT_DETAILS/XAM read path. It just does not gate the
challenge missions.
Still open: word B (+1956) has no known writer -- GamePart_StageClear's
unconditional 1 << x would land a challenge stage on word A bits 24-29, not word
B, so clearing a challenge mission must be recorded by another path (presumably
the one that also stores its Time/Points record).
|
|||
| 047ad995a0 |
re(achievements): earned state comes from XAM, and my bit numbering was wrong
Two findings, one of them a correction to the previous commit. FOUND: GamePart_Debriefing enumerates XACHIEVEMENT_DETAILS from XAM (0x8218F888). The records are 36 bytes -- confirmed by the arithmetic, not by eye: the count is a byte count divided by 36 through the 0x38E38E39 multiply-high magic plus srawi 3. Field +0 is used as a shift amount, field +32 is tested for 0x00020000, and the buffer sits behind a handle that is waited on (0x824AA330 with -1) then closed (0x824AA3E0). That is the XDK struct exactly, with XACHIEVEMENT_DETAILS_ACHIEVED == 0x20000, via the XamUserCreateAchievementEnumerator / XEnumerate pattern. So the title does NOT persist earned achievements itself -- it asks the console. The lever for achievement-gated content is the emulator's PROFILE data, not the savegame. Independently, the singleton the challenge gate reads is not the object holding the save block: re-scanning all 202 accessor call sites WITH function- boundary stops touches only +80/+1956/+1960/+1964 and none of the known save offsets (+304/+316/+320/+336/+380/+440). The earlier scan that seemed to find them had register tracking bleeding into the next function -- a false positive I am recording rather than quietly dropping. CORRECTED: the previous commit claimed "bit n <-> achievement n+1" and treated the Debriefing award pass and the challenge gate as the same bit space, both as confirmed. Neither holds up: - the only place the image is observed turning an achievement into a bit does 1 << dwId with 1-based ids, so bit = the id and bit 0 is unused; - the "list index is the bit index" step assumed 0x82448338's out-parameter is the loop ordinal. It is the child entry's first word out of a 12-byte array, and whether that is an ordinal, an id or a name hash is not pinned; - the Debriefing's masks are its own fields (+208/+736/+740). Nothing observed copies them into the singleton's +80, and no writer of that bitmask has been found at all. The requirement-type/id agreement still stands, but it confirms the LIST ORDER, not the bit numbering. Consequence: if the join holds, TimeAttack's REQUIREMENT 16 is achievement 16 (Night Ravens Patch), not 17 (Solar System Defense Award). Both read plausibly as a first-challenge gate, which is exactly why it needs evidence and not the better story. Also noted: +1960 is a third bitfield on the same singleton, and a what-changed pass at 0x8219F3A4 diffs it and reports each newly set bit as bit + 64 -- so there is a wider flag-id space whose bases are not yet worked out. |
|||
| 90da38bb2b |
re(challenge): the gate's bit space is the game's 24 ACHIEVEMENTS
Static only. Last commit left "REQUIREMENT is a bit index into a progress bitfield" with the space unidentified. It is the achievement space, and both halves are now readable off the disc and the executable. - GamePart_Debriefing (0x8218CF38-0x82191B18) awards them: sub_8218F9A8 walks the on-disc ACHIEVEMENTS_REQUIREMENTS list (tables.pak #16, schema 744c0519), and for entry index n tests bit n, evaluates the entry when clear, and sets the bit when satisfied. The list is literally ACHIEVEMENT01..ACHIEVEMENT24 -- 24 entries, which is exactly where the challenge gate splits word A from word B. - The XEX carries the definitions: XACH at .pe 0x8FBCBC, 36-byte records {id, name_id, unlocked_desc_id, locked_desc_id, image_id u32, gamerscore u16, pad, flags u32, 16 zero bytes}, strings from one XSTR per language (English is table #5). tools/xach_dump.py parses it. SELF-CHECK: the 24 gamerscores sum to exactly 1000, the retail total -- a wrong stride does not land on a round 1000. - The two sources agree on ORDER independently: the requirement types ShootDownAircrafts 1000/10000, ShootDownShips 100, ShootDownWeight MegaTons, GetAllWeapons and GetAllAchievements line up with ids 19-24 exactly as XACH names them. So bit n <-> achievement n+1 is evidence, not inference. (Those last two are requirement TYPES, not debug cheats, despite how they read.) - Corollary: TimeAttack's REQUIREMENT 16 -- the one value that sits in direct value-before-key adjacency, so it survives IDXD dedup -- is bit 16 = achievement 17, "Solar System Defense Award", i.e. finish the story campaign. The other five values (25-29) are >= 24 and so index word B, a second flag space, plausibly a challenge-clear chain. Still 🟡. REFUTED, from the last commit: the stores to +1956 in 0x822AF278 / sub_822C8748 are NOT this singleton. That object comes from 0x822CEB30, checks a +2652 flag and stores string POINTERS at +1956/+2024 -- and a pointer ANDed with 1<<n is meaningless as a gate. So nothing in the image writes this singleton's +1956 field-wise, and where the mask persists (save vs Xbox profile) is open. XEX imports are by ordinal, so absent XamUser* strings are not evidence either way. |
|||
| 57baa7fc78 |
re(challenge): the unlock is a bit test, and the mission table is on disc
Static only. Bounding each GamePart's code block by its factory creator thunk (id -> creator recovered for 22 of 24 registrations at 0x8280C000-0x8280F800) puts GamePart_ChallengeMission at 0x82187E60-0x8218CF10. Resolving every string that block references gives the screen's config schema, and the record itself is on disc -- tables.pak schema 54a10697, one copy per language, English entry #64. Six missions: TimeAttack (record Time), ScoreAttack (record Points) and Extra01..Extra04, each with MISSION_ID / REQUIREMENT / REQUIREMENT_DESC / THUMBNAIL / STAGE_DESC / NEW_STAGE and a NORMAL_BUTTON / GRAY_BUTTON pair -- so the screen always lists all six and greys out what is not earned. THE GATE (0x82189970-0x821899D8), read off the code: REQUIREMENT absent -> available REQUIREMENT == "Always" -> available else n = atoi(REQUIREMENT) n == 0 -> locked n < 24 -> test bit n of the word at singleton+80 n >= 24 -> test bit (n-24) of the word at singleton+1956 The singleton is 0x821707C0 (lazy, global 0x828F48BC). So availability is one bit in a progress bitfield and REQUIREMENT is a bit INDEX -- not a stage number, score or difficulty. Values per mission are 🟡: the pool's numeric tokens are 16/25/26/27/29 and 24/28 already appear earlier as font metrics, so they would be deduped -- which fits 24..29 but IDXD dedup makes positional pairing unsound here, so it is recorded as a hypothesis, not a table. Negative: the requirement TEXT is not in GP_CHALLENGE.pak (TextIndex over it = 0 entries; its only prose is embedded font copyright). Its PATH is a per-language branch the loader does not currently reproduce. Next: three stores to +1956 sit in 0x822C7DD0 / 0x822C8748, the same region as the save serializer 0x822C00E8 -- if the bits are save-backed, a hand-written save unlocks all six challenge missions and the last 42 units become one run. |
|||
| da869a518c |
re(challenge): the EX missions are a MODE, not a stage number
Static-only (no emulator, no pad input). Three findings, each with its own
evidence:
- The disc holds exactly 29 StageResource records in three families --
S01-S16 story, S18-S23 tutorial (all bg=Original), S24-S29 challenge, plus
Test. That is 16 + 6 + 6 + 1, matching weapon.tbl's stage01..16 /
tutorial01..06 / challenge01..06 key set exactly. S17 does not exist.
GP_CHALLENGE.pak has 0 IDXD objects -- it is the menu screen; challenge
missions reuse GP_MAIN_GAME_E.pak's records.
- The GamePart id table is at 0x820A1630 (29 ids). Indices are confirmed by
the image's own RegisterToFactory<N, class silph::GamePart_*> text, not by
position: GP_CHALLENGE = 26, GP_TUTORIAL = 25, GP_BUNK = 10.
- The stage loader selects its config section from a mission-KIND field at
object+144: 3 -> EXTRA, 5|6 -> CHALLENGE, else FILE (two independent sites,
0x82184df0 and 0x82185ed0; two more classify {3,5,6} as one group). The
constructor sets it to 0 and every write inside the class only clears it,
and no immediate 3/5/6 store to it exists image-wide -- so the kind is
supplied by the launching GamePart, never derived from the stage number.
That last point is a mechanism (unproven) for why patching the save's stage
field to 27 kills the load: the record is a challenge stage but the kind stays
FILE. Names an untried, zero-cost discriminator -- try stage 18-23.
Also flagged, not resolved: roster_target says S10 (a STORY stage) still
fields an unharvested unit, which contradicts the "story campaign complete"
claim by one unit.
|
