ef17c624ce
TextIndex in sylpheed-formats::localization already indexes per-phase objective text under S<NN>_P<n>_Objective_<i>, with hints and lose conditions alongside. Querying it settles what the wave work spent many iterations circling, and a disc test now pins it. Stage 02 phase 1 is "Shoot down all invading enemy fighters while watching out for attacks on the ACROPOLIS", losing if the ACROPOLIS is sunk. Phase 2 is "Protect the Admiral's ship the CALIBAN until it has entered the safe zone", losing if the CALIBAN is sunk. Phase 3 is "Destroy the interstellar cruise missiles headed for Schlos Base", matching phase 3's roster of exactly nine ISCMissile and SUBOBJ_013. That explains the phase advances and shows they are not all the same kind. Phase 1 is a kill-all-marked-fighters gate -- fighters, not the turrets every run killed almost exclusively. Phase 2 is positional and ends when the CALIBAN reaches a safe zone, so "what advances a phase" never had a single answer. It also closes a loop to the first session. The hints say red mission markers [OB] indicate your targets, so REMAINING OB -- the HUD counter hunted in the earliest iterations and located at 0xbdb59668 -- is the count of remaining marked objective targets, which is phase-1 progress itself. The old reframing that the counter is not a roster was right, and this names what it is. It is also the correct signal to watch for an advance: not deployed, which only changes once the next phase deploys, but REMAINING OB reaching zero, which is the cause. Method lesson recorded because the reflex will recur: localization.rs has had objectives, hints and lose_conditions for some time, and several iterations were spent reconstructing the same information by hand from SUBObjective strings and the guide script. The reconstruction was not wasted -- it produced the IXUD UTF-16BE and language\ prefix findings independently -- but the corpus should have been searched before the disc was, and grep -rl TextIndex crates/ would have saved the detour. Minor discrepancy noted, not investigated: ixud.rs documents the string pool as UTF-16BE and localization.rs as UTF-16LE.
3.5 KiB
What each phase asks for — from the game's own objective text
Status: ✅ pinned by a disc test (crates/sylpheed-formats/tests/phase_objectives_disc.rs).
TextIndex in sylpheed-formats::localization already indexes per-phase objective
text under S<NN>_P<n>_Objective_<i>, with hints and lose conditions alongside.
Querying it settles what the wave work spent many iterations circling.
Stage 02
| phase | objective | lose condition |
|---|---|---|
| 1 | "Shoot down all invading enemy fighters while watching out for attacks on the ACROPOLIS." | The ACROPOLIS is sunk |
| 2 | "Protect the Admiral's ship the CALIBAN until it has entered the safe zone." | The CALIBAN is sunk |
| 3 | "Destroy the interstellar cruise missiles headed for Schlos Base." | Schlos Base is destroyed |
Stage 01 phase 1 is "Repel the enemy's surprise attack.", phase 2 "Cooperate with your allies to repel the enemy units."
✅ This explains the phase advances, and they are not all the same kind
- Phase 1 is a kill-all-marked-fighters gate. Not turrets — fighters. Every run in mission-arrival-watch.md killed turrets almost exclusively, so no run came close to satisfying it.
- Phase 2 is positional, not a kill count — it ends when the CALIBAN reaches a safe zone. That is a completely different trigger type, and it means "what advances a phase" never had one answer.
- Phase 3 is destroy-the-missiles, matching phase 3's roster of exactly nine
UN_e201_ADAN_ISCMissileandSUBOBJ_013.
✅ [OB] is the objective marker — closing a loop to the first session
The hints name the mechanic outright:
"Red mission markers [OB] indicate your targets." "Take out these enemy units."
REMAINING OB — the HUD counter hunted in the earliest iterations of this
work and located at 0xbdb59668 — is therefore the count of remaining marked
objective targets, i.e. phase-1 progress itself. The reframing recorded back
then ("the counter is not a roster") was right, and this names what it is.
That also makes it the correct signal to watch for a phase advance: not
deployed, which only changes when the next phase deploys, but REMAINING OB
reaching zero, which is the cause.
🔴 Method lesson: the crate already knew this
localization.rs has had objectives(stage, phase), hints and
lose_conditions for some time. Several iterations were spent reconstructing
the same information the hard way — decoding SUBObjective_local_string.tbl by
hand, reading the guide script, inferring the phase-1 goal from
"the attackers with the orange markers".
The reconstruction was not wrong, and it produced the IXUD/UTF-16BE and
language\ prefix findings independently. But the corpus should have been
searched before the disc was: grep -rl TextIndex crates/ would have saved
the detour. Recorded because the same reflex will apply to the next unknown.
Note also a discrepancy worth resolving: ixud.rs documents the pool as
UTF-16BE and localization.rs as UTF-16LE. Both work on their own
inputs, so one comment is wrong, or the two consumers genuinely differ. Not
investigated.
What is still not observed
The phase-1 advance itself. The objective is now known exactly, and mission-objectives-text.md quantifies the cost: the marked fighters are ~16 craft and the pilot manages about two per five minutes. Nothing here changes that arithmetic — it only means the target list is now certain rather than guessed.