Syplheed-Reborn/docs/re/boot-config-and-gamepart-registry.md

What the game reads at boot — config.ini, and which GameParts actually exist

Status: ✅ CONFIRMED and decoded for the language selection. ❔ a bounded negative for the boot order. 🟡 for what the registration strings imply about the attract loop.

Contributes to MISSION Q6, and firms up Q4's ids.

✅ config.ini — the disc's only config, and it selects the language

config.ini sits at the disc root, is 400 bytes, and is the only .ini, .cfg or .txt anywhere on the disc. Its own header comment (Shift-JIS) names it:

アプリケーション/ゲームパート初期設定テーブル — "Application / GamePart initial settings table"

SYSTEM セクションには、ゲーム及び各ゲームパートで共通にアクセスする情報を記述する — "the SYSTEM section describes information accessed in common by the game and each game part"

[SYSTEM]

[LANGUAGE]
        = eng   ; default
#0x01   = eng   ; XC_LANGUAGE_ENGLISH
#0x02   = jpn   ; XC_LANGUAGE_JAPANESE
#0x03   = deu   ; XC_LANGUAGE_GERMAN
#0x04   = fra   ; XC_LANGUAGE_FRENCH
#0x05   = esp   ; XC_LANGUAGE_SPANISH
#0x06   = ita   ; XC_LANGUAGE_ITALIAN

This is the mechanism behind the EN/JP screen pairs. The console's XC_LANGUAGE_* setting selects a three-letter code, and that code is what picks GP_TITLE's English or Japanese build (ui-title-build-map.md) and the <lang>.pak families. Default is eng, keyed by the empty line — an unlisted language falls back to English. ✅ decoded. The executable does read the file: the string config.ini is at .rdata 0x82062b44.

❔ But the boot ORDER is not in it — and this is the whole search space

[SYSTEM] — the section the file's own comment says holds what the game and every game part share — is empty. So the file the game itself calls the GamePart initial settings table says nothing about which part runs first or what follows what.

Reach of the negative: this is the only config file on the disc (one find over the whole extract). The boot order is therefore not in disc-side configuration at all; it is in code, or in a table inside the executable that has not been located.

🟡 GP_ADVERTISE_DEMO is never registered — the attract loop is not its own part

The executable carries one diagnostic string per GamePart registration site (silph::GamePartTask::RegisterToFactory<N, class silph::GamePart_X>::RegisterToFactory is failed!) — the same evidence the corpus used to pin the id table (challenge-mission-gate.md §3). Extracting all of them gives 24 of the 29 ids bound to a C++ class; full list in data/gamepart-class-ids.txt.

The five ids with no registration site are 1, 2, 16, 18, 28 — in the id table's naming, GP_ADVERTISE_DEMO, GP_SELECT_STORAGE, GP_DEMO, GP_SELECTOR, GP_TEST.

That GP_ADVERTISE_DEMO (1) is among them matters for Q6, and it agrees with what was measured: the attract loop is the title screen replaying ADV.wmv (movie-binding.md), not a transition into a separate advertise part. The id table names a part the shipped build never registers.

🟡 not ✅, because this is an argument from a diagnostic string: no error message for id 1 implies no registration site for id 1. That is how the corpus already reads these strings, and it is sound, but it is not the code.

Two bonuses for Q4

• 3 and 4 are the same class — GamePart_SaveLoad is registered twice. The id table's separate GP_LOAD / GP_SAVE names are two ids on one part.
• The ids behind the menu buttons now match the executable's own class names, not just a list of table names: GamePart_Options = 8, GamePart_Tutorial = 25, GamePart_Extras = 5, GamePart_MissionSelect = 7, GamePart_MovieTheater = 6, GamePart_Title = 0. Still a name match — screen title ↔ class name — but anchored one level closer to the code.

What is still missing for Q6

The transitions. Nothing found so far says "title, then movie, then title" — the manifest gives the boot-side assets in play order (movie-binding.md), config.ini gives the language, and the registry gives which parts exist. What decides to advance is in GamePart_Title's own code, and reading it is a static PPC job that has not been started.

❔ The transitions are code, not data — the reach of that negative

Q6's remaining half asked what the game reads to decide the boot order. The answer is: nothing. It is not data-driven. Four independent places were checked, and the sequence is in none of them.

looked in	result
disc configuration	config.ini is the only config file on the disc, its [SYSTEM] section is empty (above)
the movie manifest	carries the boot-side assets in play order, and no transitions — movie-binding.md
a persistent part-id field	already refuted: the requested GamePart id exists only as a stack argument in flight, with no literal store anywhere — challenge-mission-gate.md §5
the id table's attract entry	the string GP_ADVERTISE_DEMO at 0x820a1fe8 has zero xrefs of any kind; nothing in the code reads it

So a transition is a call with an id argument, chosen by code. There is no table to read and nothing to poke.

Where that code is, as far as it was traced. The RegisterToFactory<0, class silph::GamePart_Title> diagnostic string at 0x820a3d60 is referenced from exactly one place, sub_8280E148 — the registration site — which also takes the address of sub_821C7D98 (addi), the position a factory template puts its creator. 🟡 That identification is by position and convention, not proven; sub_821C7D98 itself has 0 .rdata references, consistent with a small new+ctor thunk rather than the state machine. The substantial function in the same class neighbourhood is sub_821C6458 (4 460 bytes, has EH, 15 .rdata refs), and reading it has not been attempted.

What this means for the port

The boot sequence is authored, not transcribed — and that is fine, because the sequence itself is measured end to end:

developer splash (a RATC screen, not a video)
  → ADV.wmv
  → title + PRESS Ⓐ  ──idle ~8–10 s──> fade to black → ADV.wmv in full → title
  → Ⓐ → main menu

with the fade-through-black timings in screen-transitions.md and Ⓑ from the main menu returning to the title.