monorepo: one repository for the decoders, the port and the corpus
Merges the Godot port into the reverse-engineering repository, preserving both
histories -- 1019 commits of corpus plus the port's 31, brought in by subtree
merge and then moved into place so git can follow each file across the rename.
The reason is not tidiness. The two-repo split forced the exporter to depend on
the decoders by pinned revision, and that created a whole class of failure that
now disappears: a sha reachable only from a topic branch, orphaned by a
squash-merge, breaking a fresh checkout silently at build time. It also forced a
live read-only mount of one agent's working tree into another's container, which
is why a contract file could move mid-iteration. With a path dependency, a
decoder change and the exporter change it requires land in the same commit or
not at all.
Canary stays separate: it is a fork tracking upstream.
New structure for the long term:
docs/game/ how the game is NAVIGATED -- menus, modals, prompts, alerts,
and in-game flight. Written so nobody rediscovers it. Mostly
open questions on purpose; the in-game tutorials are the
resource for the flight half.
docs/port/MODDING.md
modding as a constraint on the exporter TODAY, not a later
feature: one logical asset in one file (the disc splits nearly
everything, and resolving that is the exporter's job), names a
person recognises, PNG/OGG/OGV/JSON only, base-and-overrides so
re-exporting is always safe, provenance in every file.
data/base + data/mods
generated tree and drop-in overrides, both gitignored
exchange/ transient inter-agent files, deliberately outside history
docs/agents/ the team protocol
Both the README and the navigation doc lead with the correction that cost the
most: the oracle is the real game under Xenia Canary. Reborn's renderer is a
hypothesis under test, it has been wrong, and treating it as ground truth
propagated into three documents and both agents before a human caught it.
Scripted modding stays possible without being built: no screen name is hardcoded
in GDScript and there is no native code in port/, which is what Godot Mod Loader
needs to be able to substitute behaviour later.
This commit is contained in:
137
docs/game/navigation.md
Normal file
137
docs/game/navigation.md
Normal file
@@ -0,0 +1,137 @@
|
||||
# How the game is navigated
|
||||
|
||||
**Purpose:** so nobody has to rediscover this. Every screen, what reaches it,
|
||||
what input it takes, and every modal that can interrupt.
|
||||
|
||||
**Status:** skeleton, filled from what the corpus already knows. Most rows are
|
||||
❔ and are *meant* to be — this page exists to be completed from the oracle, not
|
||||
to look finished.
|
||||
|
||||
> ## ⚠️ The oracle is Xenia Canary running the real game
|
||||
>
|
||||
> Not `sylpheed-cli`, not the viewer, not any renderer of ours. Reborn is a tool
|
||||
> for *verifying our decoding*; it is a hypothesis under test and it has been
|
||||
> wrong. **Every row below is only as good as the capture behind it**, and a row
|
||||
> with no capture is a guess wearing a table cell.
|
||||
>
|
||||
> This is written here because the mistake has already been made once, by the
|
||||
> author of this file, and it propagated into three documents and both agents
|
||||
> before a human caught it.
|
||||
|
||||
Confidence: ✅ measured from a capture · 🟡 inferred from disc data · ❔ unknown.
|
||||
|
||||
## 1. The screen vocabulary ✅
|
||||
|
||||
The executable carries its own list — a `.rdata` pointer array at `0x820A1630`,
|
||||
29 entries, index = GamePart id, confirmed against the factory-registration
|
||||
strings in the image:
|
||||
|
||||
```
|
||||
0 GP_TITLE 10 GP_BUNK 20 GP_STAGE_CLEAR
|
||||
1 GP_ADVERTISE_DEMO 11 GP_READY_ROOM 21 GP_MISSION_LOG
|
||||
2 GP_SELECT_STORAGE 12 GP_HANGAR 22 GP_GAMEOVER
|
||||
3 GP_LOAD 13 GP_ARSENAL 23 GP_DEBRIEFING
|
||||
4 GP_SAVE 14 GP_PILOT_LOG 24 GP_DIALOG
|
||||
5 GP_EXTRAS 15 GP_SYSTEM 25 GP_TUTORIAL
|
||||
6 GP_MOVIE_THEATER 16 GP_DEMO *26 GP_CHALLENGE
|
||||
7 GP_MISSION_SELECT 17 GP_MAIN_GAME 27 GP_LEADERBOARD
|
||||
8 GP_OPTIONS 18 GP_SELECTOR 28 GP_TEST
|
||||
9 GP_MOVIE 19 GP_PAUSE_MENU
|
||||
```
|
||||
|
||||
This is the *vocabulary*, not the graph. **Which button reaches which id is
|
||||
not decoded** — that is the open question, and filling in §3 is what closes it.
|
||||
|
||||
`GP_TEST` is named here and is not on the disc.
|
||||
|
||||
## 2. Boot 🟡
|
||||
|
||||
```
|
||||
developer logo splash → intro video → title / PRESS Ⓐ → main menu
|
||||
```
|
||||
|
||||
* The splash is a **screen, not a video** ✅ — `logo1`–`logo4` are bound by the
|
||||
movie manifest and have no `.wmv` on the disc.
|
||||
* The intro is `dat/movie/ADV.wmv` ✅.
|
||||
* ❔ What *drives* the order. It is observable; the data or code behind it is not
|
||||
decoded.
|
||||
* ⚠️ **Two title states exist and look identical.** The title that ends the boot
|
||||
accepts a single Ⓐ; the title the attract loop returns to accepts nothing —
|
||||
Ⓐ, START, B, BACK, X, Y all ignored across dozens of delivered presses. They
|
||||
draw **13 identical quads**, so they differ only to the guest. Capture the
|
||||
first title after boot; do not tap during the boot.
|
||||
|
||||
## 3. Screens
|
||||
|
||||
One section per screen. Fill from a capture, and cite it.
|
||||
|
||||
### GP_TITLE — main menu 🟡
|
||||
|
||||
Five buttons, `ptbtn01`–`ptbtn05`, at x=542, y=162/242/322/401/482.
|
||||
|
||||
| button | label | reaches | confidence |
|
||||
|---|---|---|---|
|
||||
| `ptbtn01` | ❔ | ❔ | |
|
||||
| `ptbtn02` | ❔ | ❔ | |
|
||||
| `ptbtn03` | ❔ | ❔ | |
|
||||
| `ptbtn04` | ❔ | ❔ | |
|
||||
| `ptbtn05` | ❔ | ❔ | |
|
||||
|
||||
Labels are baked into the sprites — a human reads them in a minute, but **no
|
||||
decoded field says which GamePart a button opens.** If the labels are read by
|
||||
eye, say so; that is an authored mapping, not a disc fact.
|
||||
|
||||
❔ Initial focus · ❔ wrap-around at the ends · ❔ whether left/right does
|
||||
anything · ❔ what B does.
|
||||
|
||||
### GP_LOAD ❔ · GP_SAVE ❔ · GP_EXTRAS ❔ · GP_OPTIONS ❔ · GP_MISSION_SELECT ❔
|
||||
|
||||
❔ Not documented. Known fragment: the path
|
||||
`title → LOAD GAME → slot 01 → YES → READY ROOM → TAKE OFF` reaches flight, and
|
||||
**stage select would not move** — 16 d-pad presses never left Stage 01.
|
||||
|
||||
### GP_READY_ROOM ❔
|
||||
|
||||
The largest UI archive on the disc; only 6 of 1 106 names resolve, and it is
|
||||
ISL-scripted. A probe found the pak holds briefing/tactical-map content rather
|
||||
than the Ready Room menu itself. Out of scope for the menu milestone.
|
||||
|
||||
## 4. Modals, prompts and alerts
|
||||
|
||||
The interrupting layer, and the one most likely to break a scripted run.
|
||||
|
||||
| modal | seen at | default focus | notes |
|
||||
|---|---|---|---|
|
||||
| `Save game?` | after a mission | **YES** ✅ | cursor starts on YES |
|
||||
| `Do you want to develop this weapon?` | Arsenal | ❔ | |
|
||||
| ❔ overwrite / delete confirmations | Save/Load | ❔ | |
|
||||
| ❔ error and "not enough points" alerts | Arsenal | ❔ | |
|
||||
|
||||
⚠️ **A 60 ms d-pad tap is ignored inside a dialog.** It moves the cursor on a
|
||||
menu and does nothing in a modal, so a script that works on menus silently picks
|
||||
the default in every prompt. Confirm which side the cursor is on before Ⓐ.
|
||||
|
||||
## 5. In-game flight ❔
|
||||
|
||||
Not started. **The in-game tutorials are the resource** — they teach the control
|
||||
scheme in the game's own words, which is exactly the documentation we want, and
|
||||
they are `S18`–`S23` on disc.
|
||||
|
||||
To fill in: the control map (both stick modes if there are two), throttle,
|
||||
target select — Ⓐ pressed **twice**, not once, which a sweep that only ever
|
||||
tapped once "proved" did not exist — weapon cycling, the pause menu, and the
|
||||
HUD's readouts.
|
||||
|
||||
## 6. Input traps, all measured ✅
|
||||
|
||||
Real behaviours that read as bugs:
|
||||
|
||||
* **F10 opens the emulator menu bar**, and any Xenia UI makes
|
||||
`XamInputGetKeystrokeEx` return SUCCESS with an empty keystroke *before* any
|
||||
driver is asked. The pad looks dead and is not.
|
||||
* **A signed-in profile is required** — hence `--create_profile_if_none`.
|
||||
* **A FIFO trace consumer that exits stalls the emulator**, which also reads as
|
||||
a dead pad.
|
||||
* **The title is not input-ready for ~10 s** after it appears.
|
||||
* **Ⓐ on the first title succeeds about half the time**, and nothing measurable
|
||||
predicts which. Five explanations have been eliminated. Budget retries.
|
||||
Reference in New Issue
Block a user