# Partial failures, shared blackout and final-mission beacon choreography The [blackout viewer](../analysis/missions/blackouts.html) separates a native timed replay of supplementary record 04_015/7 from static inventories of other mission commands. [blackouts.json](../analysis/missions/blackouts.json) retains coordinates, commands, messages and native changes. ## Shared power-grid failure Five world records select supplementary record 7 and contain owner-registration commands that can activate it: 04_003/2, 04_003/7, 04_005/2, 04_007/3 and 04_010/2. This is distinct from the Nightmare challenge's script. Activation still depends on their runtime conditions; merely loading one of those missions does not prove it reaches a full grid failure. Starting with all 225 Delphi towers at FF, the original script and fade updater extinguish **224**, leaving **(72,126)** untouched. The last source-byte change occurs at tick **12,512**, approximately **25.024 seconds** after the fixture's script entry. Pre-existing failures may change the final count in actual play. The script then remains in its delay loop. Its nine English messages, consumed natively, read: 1. Power is dropping throughout the city. 2. Beacon power is failing. 3. Our scanners 4. are failing. 5. Fortunately, 6. commun- 7. -ications 8. are still 9. oper--- All 32 configured fade runs target actual type-1 lattice cells. The replay executes C510 before the player interpreter, as the main loop does, at fixed 16-tick steps. Each fade changes output through intermediate values; the previously verified 8450 charging calculation uses that state byte, so the change affects charge capability as well as appearance. ## Correction: the mission header's coordinate list is a queue, not necessarily initial darkness The historical JSON field `initial_beacon_sequence` is retained for compatibility, now with an explicit semantic note. BD98–BDA2 sets C449 to F004 and skips to the FF terminator before parsing object setup. It does **not** darken those towers there. Opcode 11 at C442 consumes the next byte through C449, advances the pointer, sets dimming mode and configures one beacon. This identifies the source previously left unresolved: it is mission data, not a random or executable-byte sequence. C569 separately reads the entire list and sets those tower state bytes to zero. Its direct call at **3ECB** lies in the mission-exit path reached when 3E9A is nonzero, before subsequent outcome/save/continuation handling. Thus calling it an initial-outage loader was incorrect. The full persistence and save/reload consequences still require tracing; the call occurs before the later success/failure branches, not exclusively on successful completion. Native tests check setup pointer binding, all 118 listed coordinate consumptions across nine records, and C569's exact resulting cells. They force the reads for verification and do not claim each live script necessarily consumes its whole queue. | Record | Queued coordinates | Decoded individual-failure commands | |---|---:|---:| | 04_005/2 | 4 | 4 | | 04_006/7 | 2 | 0 | | 04_007/5 | 5 | 5 | | 04_008/4 | 4 | 4 | | 04_009/2 | 5 | 5 | | 04_010/4 | 2 | 0 | | 04_011/5 | 9 | 9 | | 04_012/0 | 64 | 0 | | 04_015/0 | 23 | 3 | ## Nightmare challenge (04_015/0) The [scenario explorer](../analysis/missions/index.html) now provides a **Beacon sequence** panel when Nightmare is selected. Enable **Show ordered changes on map**, then use Previous/Next, the slider, the event selector or Play. Yellow beacons are powered, dark beacons are off, and white rings identify the current fade. Charging-zone overlays and hover details follow the selected step. This is a completed-fade walkthrough, not a clock-accurate playback: combat waits are assumed satisfied and delays are listed beside the next event. `tools/mission_beacons.py` follows the decoded player script from its entry, repeats the checkpoint loop until its world-state condition is satisfied, and consumes all 23 queued coordinates. Single-beacon commands reset the direction to dimming, as in `C442`; later row/column restorations are therefore tracked independently of the static inventory's direction assumptions. The 85 steps include 80 fades, direction changes and the two altitude-control changes. All 80 fade footprints match the independent full mission-script replay in order. The final step restores all 225 towers. Other records retain their existing outage inventory overlays; the separate blackout page retains its timed shared blackout replay. The final beacon pursuit includes an intentional flight-control change: immediately before the queued beacon at **(18,18)** is extinguished, opcode `38 00 02` enables scripted altitude hold at height **512**. This causes a persistent nose-down steering demand above the requested height, independently of the ordinary low-speed response to losing beacon power. It can feel like successive outages are accumulating a downward force, but the script explicitly changes the controller at this point. The release is gated by two groups of three moving ground objectives: equipment carriers, then cargo trucks. This section selects weapon 10 (key **0**, Brent Hunter); Brent Ground targets static map objects instead. The accompanying Assassin (object 22) is explicitly uncounted and does not need to be destroyed. After both objective waits finish, script delays total 22,650 ticks and three beacon-command delays add 900 ticks: roughly 47 seconds at the nominal 500 Hz clock, plus frame scheduling, before the forced hold is released. The native handler `C194` toggles bit 7 of `7ED2`, consuming the height word into `80AC` when enabling it. `8067` selects height control for any nonzero altitude flag; `80A4` applies the height error plus the pitch-control reference. The A key only toggles bit 0 and therefore cannot cancel the scripted bit. A later opcode `38` disables the scripted mode before the grid-restoration sequence. In the controlled retail-script replay, the mode starts at tick 124056, the (18,18) beacon fade starts at 124456, and the mode ends at 151056. These are replay checkpoints, not fixed playthrough timings: earlier waits depend on objectives. The [native selection path](city-retry-and-selection.md) identifies 04_015/0 as the special Nightmare challenge, not the final campaign mission. It has its own substantial sequence of row/column fades, objective waits, reserve activations and direction reversals. Its row/column command inventory covers all 225 tower positions, but this is **not** evidence that all are simultaneously off: later commands restore power, and waits separate phases. The viewer marks this as static coverage, with direction derived assuming initial dimming mode, rather than presenting an invented uninterrupted playthrough. This supports keeping three concepts separate: local scripted failures, the shared power-grid failure triggered by certain mission paths, and the Nightmare challenge's staged beacon choreography. Displayed mission numbering and exact in-game outcomes should not be inferred solely from resource numbering. ## Reproduction and limits ``` PYTHONPATH=/tmp/darker-python python3 tools/trace_blackouts.py PYTHONPATH=/tmp/darker-python python3 tools/verify_blackout_queues.py ``` The shared-script replay uses real map type bytes and real English message bytes; sound notification is intercepted. It does not simulate the combat/conditions that trigger the shared script, or prior persistent darkness. Other records are inventoried rather than run to completion. The Nightmare challenge needs explicit objective/event inputs for a faithful controlled timeline.