Type-12 beacons and radar coverage

The small red-topped, beeping type-12 beacons form a radar coverage grid in Delphi. This interpretation is supported by a shared position lookup, native map-state checks, and contact-display filtering. It has been verified by isolated execution of the original routines, but not yet by destroying a beacon during a live game.

Why the regular placement matters

All sixteen occupy the Cartesian product of cell coordinates 13, 49, 85, 121: a 36-cell spacing along both axes. Routine 3AFD–3B19 selects the local grid point from integer listener coordinates at 2701 and 271C. For either coordinate c, its in-map result is:

beacon_coordinate = c - ((c + 77) % 36 - 18)

The regions change at cell coordinates 31, 67 and 103. For example, beacon (49,49) serves columns 31–66 and rows 31–66, inclusive. This is a square grid partition, rather than a circular distance/range test. The regions of edge beacons are clipped by the map boundary.

Two direct call sites were found for this entry point: the sound callback 3685 and cockpit coverage setup 5A75. This is not a claim that all indirect references or all uses of these coordinates have been exhausted.

Contact display depends on beacon state

5A75–5AB8 selects the local beacon and constructs a coverage mask from a three-by-three neighbourhood of grid positions. 5B56–5B75 reads the corresponding map state bytes, with 36-cell steps in both directions. Each region is enabled when its state byte is less than 20h. There is no type-12 test: the code relies on the map placing the appropriate objects on that grid.

An intact interior neighbourhood produces mask 0777. Disabling the central beacon changes it to 0776; disabling each of the eight neighbours clears a different bit. Edge handling removes regions outside the map. Map mode byte 6202 == 2 bypasses the state checks and supplies 0777 (the underground mode); do not generalise Delphi's network to every map.

59A3–59CA classifies a target coordinate into the mask and returns its coverage bit in carry. The object-display loop calls this at 5B1D and skips its drawing path when carry is clear (5B21). A separate energy-tower display loop uses the same predicate at 58E9. Thus the network affects displayed information, rather than merely making a sound. The nearby path 5941–59A2 draws radar interference in uncovered areas, matching the grey static observed both outside the city and within radio outages.

Damage and beeping

The base type-12 geometry at bank-30 pool offset 09BF has a damage link to 0B2D. The previously traced generic destruction path increments a cell's state by 20h. That crosses this coverage threshold. A full collision/weapon/destruction sequence for this particular model has not yet been executed in-game.

Its 37A6 beep uses the same grid selector, but checks state bits E0. For all byte values this agrees with the coverage test: states 00–1F remain enabled; 20–FF disable both. Only the selected nearby beacon feeds this sound record.

Suggested live check: find a visible radar contact near a type-12 beacon, destroy the beacon, and observe whether its beep stops and contacts in its 36-cell square disappear or give way to interference. Moving between network regions should let you compare the effect. Mission setup or combat damage may also change the state; the campaign distinctions are described below.

The extracted mission text mentions faults in the radio network and says radar originally tracked the shuttle system; archive 04_001, record 1, offsets 05EB–0770 also describes recalibration for high-altitude Stalkers. This is useful narrative context, not independent proof of the exact type-12 mechanic or its altitude rules.

Charging is separate

The traced charging source routine 8450 explicitly accepts type 1 at the energy-tower lookup position; it does not accept type 12. No charging role for these small beacons was found in that path. This does not settle the separate observation about type-11 streetlights, or rule out other contributions elsewhere in the engine.

Scenario-map outage overlays

The scenario browser draws radar outages in purple and no-charging regions in amber, with independent visibility controls. Hovering over a cell identifies its selected radio mast and energy tower. Boundaries follow the original selectors: 36-cell radar partitions and the startup-generated charging lookup on the nine-cell tower grid, clipped at the map edges. An extinguished selected tower provides no charging; a neighbouring working tower is not used as a fallback. A powered region does not promise full charge strength, which still depends on distance and altitude.

The Mission start view accumulates earlier missions' exit failure queues and authored setup flags. Including queued / scripted outage areas also marks the selected mission's queued failures and possible scripted dimming footprints, including the shared blackout sequence where applicable. These footprints are not a claim that all failures occur simultaneously. Conditional blackouts and combat destruction (by either side) from earlier missions cannot be reconstructed without an actual playthrough or save and are not assumed. The controls apply to Delphi; Halon and underground power and radar systems use different rules.

tools/verify_mission_coverage.js checks partition boundaries, cumulative failure queues, overlay visibility and switching between map modes in the generated browser.

Reproduction

PYTHONPATH=/tmp/darker-python python3 tools/verify_beacon_radar.py executes 252 assertions covering nine single-beacon outages, state thresholds, region boundaries, mode bypass, independence from the tile type, and all 128 in-map coordinates in the shared lookup.

• Verification results
• Relevant native disassembly
• Ambient sound locations

The fixtures test the original lookup/mask/filter routines with synthetic map state, not an entire game frame, cockpit rendering, or mission logic.

Grey interference in uncovered regions

Retail observation confirms grey sparkles appearing and disappearing in the uncovered portion of the radar. Native 5941–59A2 attempts 17 random points per normal surface-radar frame unless all nine coverage bits are enabled (0777h). It tests each candidate with 59A3, rejects covered positions, then rotates the remaining offsets into radar space. The ordinary radius-21 dot routine 5C04 clips the result and chooses palette index 22 - (squared_radius >> 5), so the speckles fade towards the rim. The background is restored each frame.

This is a dedicated radar path, sharing the energy-beacon dot drawing routine; it is not a general particle or snow renderer. It runs after normal contacts. Underground radar bypasses it, and the enlarged display has no separate snow loop. Losing a radio mast or leaving the covered city therefore affects both contact visibility and the static pattern.

The routine consumes the shared 92D2 random sequence once for each of its 17 candidates, including rejected points. Full coverage consumes none. Faithful reconstruction must preserve that consumption as well as the visible dots. 512 isolated native cases now match reconstructed pixel buffers and final random states for full, partial and absent coverage, headings and off-map coordinates. The fixture supplies the original startup sine-table extension; only the final VGA pixel write is substituted.

Why most mission overlays have no predetermined radar outage

Radio coverage does not inherit the nearest energy beacon's output or a power-station network state. Native 5B56 tests the radio mast cell itself: state 00h–1Fh supplies coverage, 20h–FFh does not. The additional native checks extinguish or vary all 225 charging towers while holding radio states fixed; the radar mask is unchanged. Charging outages and radar outages must therefore be represented independently.

A successful destructive hit advances a radio mast's state by 20h, disabling its regional coverage and beep. Such damage can persist in a campaign save. The scenario browser has no particular save or combat history: its fixed-state overlay cannot show which masts were lost during a previous playthrough. The all-mast setup damage in level 115 is the only ordinary campaign setup list that directly marks these sixteen radio-grid cells. This is why that mission appears very differently from earlier missions in the overlay.

Earlier briefings describe several distinct situations:

• Level 8: reports disappearing contacts and suspected radio faults. Level 10 attributes these reports to high-altitude Stalkers and describes recalibration. These are briefing statements, not authored regional outage flags; no altitude-dependent radar filter or recalibration change has been established by this investigation.
• Levels 41–42: warn of attacks on radio towers. Aircraft placements include mast cells (49,13) and (13,49) in 41, and (49,13) and (49,49) in 42. However, native setup 3C4F clears the building-attack switch at 8B13, and neither record contains opcode 32h to enable it. The warning alone is not proof that the intended direct building attacks occur. Incidental projectile impacts remain a separate possibility.
• Level 61: does enable building attacks (32h 19h) and initially places a definition-23 Terrablitz at radio mast (49,49). Its default cell target and bombing behaviour provide a concrete combat-dependent outage route. Whether the tower is actually lost depends on combat and interception.

Consequently, earlier local grey-static patches indicate lost radio coverage, not automatic loss of power from a nearby energy tower. Exact patches from a particular retail campaign require its saved mast states; a selected mission number alone does not determine them.

Explicit scripted radio-mast attacks

A broader mission audit distinguishes direct state writes from scripts that order enemy aircraft to destroy a mast. The latter were missing from the scenario browser's initial potential-outage overlay. These four Delphi missions contain attack-enabled cell orders (00h, clearing the attacker’s no-building- attack flag) aimed at radio-grid positions, together with a nonzero global building-attack command (32h):

These are conditional combat outcomes: the player may intercept the aircraft, and aim, movement, projectile allocation and collisions determine whether a mast is actually destroyed. Approach orders using 01h set flag 02 and do not by themselves permit attacking the building. Several earlier missions place Stalkers near masts or direct them there with this non-attacking form; these must not be labelled as guaranteed tower attacks.

For concrete references, mission 61 enables attacks at resource offset 2676h (decimal 9846) and its aircraft scripts issue mast targets at offsets 9866, 9875, 9887 and 9902. Mission 87 uses offsets 13935, 13948, 13955 and 13968; mission 96 uses 13838 and 13850; mission 97 uses 717 and 728. These are resource offsets, not executable addresses.

The type-12 base model has an ordinary category-zero collision volume and a valid damage link. tools/verify_radio_mast_impact.py executes the original CDB9 impact routine using that real model/category: an unmarked mast rejects player Brent Ground (definition 5), but accepts hostile ground missile 11 and bomb 14. Successful impact writes state 20h; executing 5A75 afterwards changes the interior coverage mask from 0777h to 0776h. This proves the impact-to-outage connection without requiring a player ground-target marker. The probe supplies an admitted collision and omits visual effect spawning; it does not simulate the aircraft's entire flight or projectile trajectory.

The reconstruction connects the same script enable, actor target/flag, hostile projectile, world-impact and radar-state paths. No new gameplay toggle is needed for these losses to occur. The scenario browser now includes these regions in its potential scripted/attack outage view, without assuming they were destroyed at mission start or carrying hypothetical losses into later missions. Full natural-play timing remains subject to playtesting.