Real selection, failure/reload and city persistence

Record lookup is not validation

090B uses byte 084D to calculate SS:0FB0 + selection * 0671h, sets ES=SS, and subtracts 19C4h from the multiplication result. The zero flag therefore identifies selection 4, not a missing or corrupt save. Earlier fixtures called these branches “valid/invalid”; that terminology has been corrected.

Normal records are 0671h (1,649) bytes apart. This establishes the in-memory layout only; it is not a complete disk-save format.

Special selection is the Nightmare challenge

The native startup path 3C76–3C93 uses BB12 to map a normal slot's one-based stage into archive resource/record. Special selection 4 bypasses that conversion and selects 04_015 / 0 directly. Completion text in 04_015 / 4 explicitly congratulates the player on overcoming the Nightmare challenge.

Thus earlier references to 04_015/0 as the “final mission” were misleading: it is a separate challenge entry. Its elaborate beacon choreography must not be conflated with the final Delphi campaign mission or the conditional shared blackout script.

Seventeen native startup checks cover each normal selection at stages 1,8,9,99 and special selection 4. For example, internal stage 99 maps to 04_012/2; this does not by itself establish the mission number shown on screen.

Commit, failure and explicit reload

The new fixture runs this chain using the real 090B lookup and actual city resources/descriptors:

1. Load the original city through BB59.
2. Commit one damaged real cell through BC2D/BB90.
3. Change that cell further and damage a second real cell during a simulated attempt.
4. Execute 3EC8's exit path with outcome 1, 2 or 3.
5. Explicitly reload the original city and restore through BC2D/BBC6, including low-variant regeneration.

All four normal selections and both cities produce the same result:

For outcomes 2/3 the entire 1,649-byte selected record remains unchanged by the tested exit path. The subsequent explicit reload therefore discards damage from the failed attempt but retains earlier committed damage. The real outcome presentations support the interpretation: record 2 contains the funeral text; record 3 says that Halon craft remain underground and “Mission aborted. Try again.”

This is stronger than separately checking a serializer and a branch, but is still not an interactive playthrough: the outer menu/outcome loop is omitted and the reload is explicitly invoked. It does not establish every path after failure, nor whether a separate repair operation exists elsewhere.

First-stage bypass

BBC6 begins by checking whether the selected record's stage byte equals 1. If it does, restoration returns immediately. Twenty-four additional checks set this byte to 1, reload the base map, and confirm that old packed building damage is not reapplied. This is a restoration bypass, not proof that the packed bytes were erased. It also does not mean “first Halon mission”: the predicate is the overall record stage byte.

Reproduction

PYTHONPATH=/tmp/darker-python python3 tools/verify_mission_selection.py
PYTHONPATH=/tmp/darker-python python3 tools/verify_city_retry.py

Selection results: 17 native startup mappings. Reload results: five real lookup cases, 24 exit/reload chains and 24 first-stage bypass checks. Audio/time/UI helpers remain intercepted. Resource I/O is replaced with the extracted bytes, but original expansion, commit and restoration execute. No disk writes or disk-save parser are tested.

Returning before the objectives are complete

Automatic docking finishes at 7D63–7D6F. It calls C84E, which checks both the current building-objective list byte and the outstanding-object counter. Only an FF terminator and a zero counter produce outcome 1 (success). An FE list boundary or any remaining objects produce outcome 3 instead.

For an early underground return, outcome 3 plays 04_015/3: the warning that Halon craft remain underground and “Mission aborted. Try again.” It does not advance the mission or commit the attempt's world changes. Retrying uses the normal load briefing, whereas successful tunnel continuation uses its seamless entry path. This presentation is distinct from both the death committal and an ordinary Escape-to-menu exit.