c27bdee021
**navigation.md rewritten from the player's chair.** It was written from the inside out -- GamePart ids, pak names, sprite names -- which is how WE find things, not what the game shows anyone. Now it describes what is on screen, what you press and what happens, with internals as footnotes. Most rows are open on purpose: it exists to be filled in by playing, and the in-game tutorials are the resource for the flight half. **tools/share** gives transient files provenance without giving them history. Three kinds of thing were travelling down one channel with opposite needs: code and decoded knowledge want permanence, cited evidence wants permanence, and "look at this PNG" wants no history at all. The third kind bloats a repository forever; passing it by message is worse, because the receiver gets bytes with no idea which build produced them. `share put` records who, when, what, the sender's commit, and whether their tree was dirty -- because a capture taken from a modified tree cannot be reproduced from the sha, and the receiver deserves to know that before building an argument on it. **docs/agents/PROTOCOL.md** is the contract. The parts that matter: Dynamic RE stays with the Decoder -- most of what is open is behavioural and cannot be answered from the file. What the planned Referee adds is different: bias enters at what you CHOOSE to capture, so a corpus captured to a fixed protocol by someone with no hypothesis is worth more than one captured to settle an argument. A message may point, ask, prioritise and challenge. It may not change scope, redefine ground truth, or carry a finding instead of writing it down -- including a message claiming to relay the human, because a relayed instruction has no evidence attached and this project has watched a wrong belief travel further and faster than its correction. Adversarial duty is explicit: every iteration, try to refute one claim of another agent and record the attempt either way. Run your own instrument through a control first. Disagreements go to the human with both positions, not to whoever is more certain. And no agent may verify its way out of its own role: the Port has no oracle, the Decoder builds nothing, the Referee interprets nothing.
150 lines
5.9 KiB
Markdown
150 lines
5.9 KiB
Markdown
# Playing the game: every screen, and how you move through it
|
||
|
||
**Written from the player's chair.** What is on screen, what you press, what
|
||
happens. This is the document you would hand someone who has never seen the game
|
||
and wants to reach a mission — or who needs to script that journey.
|
||
|
||
Internal names (`ptbtn03`, `GP_LOAD`, build numbers) appear only as footnotes,
|
||
because they are how *we* find things, not what the game shows anyone.
|
||
|
||
**Status:** skeleton. Most of it is ❔ and is *meant* to be — this page exists to
|
||
be filled in by playing, not to look finished.
|
||
|
||
> ## ⚠️ Fill this in from the real game
|
||
>
|
||
> The oracle is **Xenia Canary running the actual title**, captured. Not
|
||
> `sylpheed-cli`, not the Explorer, not any renderer of ours — those are tools
|
||
> for verifying our decoding, they are hypotheses under test, and they have been
|
||
> wrong. A row here with no capture behind it is a guess wearing a table cell.
|
||
>
|
||
> Describe what you *saw*. "The cursor starts on the second item" is worth more
|
||
> than any amount of reasoning about the layout data.
|
||
|
||
Confidence: ✅ seen in a capture · 🟡 inferred · ❔ unknown.
|
||
|
||
---
|
||
|
||
## 1. From power-on to the main menu
|
||
|
||
| # | What you see | What you do | What happens |
|
||
|---|---|---|---|
|
||
| 1 | Publisher and developer logos on black | nothing | plays through 🟡 |
|
||
| 2 | The opening cinematic | ❔ can it be skipped, and with which button? | ends into the title 🟡 |
|
||
| 3 | **Title screen** — the wordmark animates in, then a prompt | press **Ⓐ** | goes to the main menu ✅ |
|
||
| 4 | **Main menu** | — | see §2 |
|
||
|
||
⚠️ **The title screen has two states that look identical.** The one that ends
|
||
the boot accepts Ⓐ. The one the attract loop returns to, after the game has sat
|
||
untouched and looped back, **accepts nothing** — Ⓐ, START, B, BACK, X, Y, dozens
|
||
of presses, no response. Nothing on screen distinguishes them ✅. If you are
|
||
scripting: use the *first* title after boot, and do not press anything during the
|
||
boot.
|
||
|
||
⚠️ **The title is not input-ready for about ten seconds** after it appears ✅.
|
||
And even then Ⓐ registers roughly half the time, with nothing yet found that
|
||
predicts which ✅ — budget retries.
|
||
|
||
---
|
||
|
||
## 2. Main menu
|
||
|
||
Five options in a vertical stack, roughly centred, with a highlighted state on
|
||
the focused one.
|
||
|
||
| position | label | what it opens |
|
||
|---|---|---|
|
||
| 1 | ❔ | ❔ |
|
||
| 2 | ❔ | ❔ |
|
||
| 3 | ❔ | ❔ |
|
||
| 4 | ❔ | ❔ |
|
||
| 5 | ❔ | ❔ |
|
||
|
||
**To fill in, by looking:** read the five labels off the screen and say what each
|
||
one leads to. ❔ Which item is focused when the menu opens · ❔ does the cursor
|
||
wrap from the last item back to the first · ❔ does left/right do anything ·
|
||
❔ what B does here — back to the title, or nothing.
|
||
|
||
*Internals: `GP_TITLE.pak` build 5; buttons `ptbtn01`–`ptbtn05` top to bottom.*
|
||
|
||
---
|
||
|
||
## 3. The rest of the menus
|
||
|
||
One section each, in the shape of §2: what is on screen, what the cursor does,
|
||
what each choice leads to, and what a wrong choice shows you.
|
||
|
||
### Continue / Load ❔
|
||
❔ How saves are listed · ❔ what an empty slot looks like · ❔ the confirmation
|
||
prompt and where the cursor starts.
|
||
|
||
Known: `title → LOAD GAME → slot 01 → YES → READY ROOM → TAKE OFF` reaches
|
||
flight ✅.
|
||
|
||
### Options ❔
|
||
❔ Which settings exist, what each ranges over, how a change is applied and
|
||
whether it needs confirming.
|
||
|
||
### Extras ❔
|
||
❔ What is in it — a movie theatre, a gallery, records? ❔ what is locked at the
|
||
start and what unlocks it.
|
||
|
||
### Mission select ❔
|
||
⚠️ **Stage select would not move**: sixteen d-pad presses never left Stage 01 ✅.
|
||
Whether that is because only one stage was unlocked, or because the list is
|
||
driven some other way, is unknown — worth settling early, since a scripted run
|
||
has to get past it.
|
||
|
||
### Briefing and Ready Room ❔
|
||
❔ What you read, what you choose, and what finally launches the mission.
|
||
|
||
### Hangar / Arsenal ❔
|
||
❔ How a weapon is fitted, how one is bought, what a purchase prompt says.
|
||
|
||
---
|
||
|
||
## 4. Prompts, confirmations and alerts
|
||
|
||
The interrupting layer — and the thing most likely to break a scripted run,
|
||
because it looks like a menu and does not behave like one.
|
||
|
||
| prompt | when | where the cursor starts | notes |
|
||
|---|---|---|---|
|
||
| `Save game?` | after a mission | **YES** ✅ | |
|
||
| `Do you want to develop this weapon?` | Arsenal, on purchase | ❔ | |
|
||
| overwrite / delete confirmation | saving, loading | ❔ | |
|
||
| "not enough points" or similar refusal | Arsenal | ❔ | ❔ does it need dismissing |
|
||
|
||
⚠️ **A short d-pad tap is ignored inside a prompt.** Sixty milliseconds moves the
|
||
cursor on a menu and does *nothing* in a dialog ✅. So a script that works
|
||
through the menus will silently accept the default in every prompt it meets —
|
||
which is how you end up overwriting a save you meant to keep. **Confirm which
|
||
side the cursor is on before pressing Ⓐ.**
|
||
|
||
---
|
||
|
||
## 5. Flying
|
||
|
||
Not started, and the game teaches it better than we could: **play the in-game
|
||
tutorials and write down what they say.** They are the game's own explanation of
|
||
its controls, which is exactly the document we want.
|
||
|
||
To fill in: the control map, and whether there is more than one scheme · throttle
|
||
and boost · targeting — ⚠️ target select is Ⓐ pressed **twice**; a sweep that
|
||
only ever tapped once concluded targeting was automatic, and was wrong ✅ ·
|
||
switching weapons · the pause menu and what it offers · what the HUD tells you,
|
||
element by element · how a mission ends, win or lose, and what you see next.
|
||
|
||
---
|
||
|
||
## 6. If you are scripting this
|
||
|
||
Traps that read as bugs but are not, all measured ✅:
|
||
|
||
* **F10 opens Xenia's own menu bar**, and while any emulator UI is up the game
|
||
is handed an empty keystroke before any pad driver is asked. The controller
|
||
looks dead and is not.
|
||
* **A signed-in profile is required** — `--create_profile_if_none`.
|
||
* **A trace consumer that exits stalls the emulator**, which also reads as a dead
|
||
pad.
|
||
* Cold boot is slow; ~25 s once the shader and code caches are warm.
|