Add configurable main-road checkpoints and reconnect replacements; record Workshop 0.0.136

docs/configuration.md

@@ -39,18 +39,21 @@ and `/esc mission startammo set N` (also `show` and `help`).
 
 ## Roadblocks
 
-The admin menu **Settings → Roadblocks next round** sets `mission.roadblockCount`
-in `Escapists.json`: **0–30**, default **4**; **0 disables** them. The chat equivalent
-is `/esc mission roadblocks set N` (also `show` and `help`). Changes apply on the
-next round/restart, leaving current units and cover in place.
+Under **Forces → Checkpoints**, configure two independent next-round quotas:
 
-Each compact checkpoint has four sandbag walls, two approach barriers and two
-stop signs. The props span about 9 m across a 6 m road and 17.8 m along it;
-four guard positions sit immediately behind the sandbags. Four soldiers come
-from the selected enemy faction. They use normal equipment rules and physical
-radio reporting to VirtualHQ; HQ can send their squad to respond to contacts.
-They do not reveal player locations to HQ merely by being created. Soldiers and
-cover are owned by the round; killed guards are not replaced.
+| Setting | Range | Default | Chat command |
+| --- | --- | --- | --- |
+| Small checkpoints (`mission.roadblockCount`) | 0–30 | 4 | `/esc mission roadblocks set N` |
+| Large checkpoints (`mission.largeRoadblockCount`) | 0–30 | 4 | `/esc mission largeroadblocks set N` |
+| Main-road minimum width (`mission.mainRoadWidthMetres`) | 5–12 m | 6 m | `/esc mission mainroadwidth set N` |
+
+Both counts can be disabled separately with zero; set both to zero to disable all checkpoints. The existing `roadblockCount` value now controls only small roads. Old configurations retain that value and receive the new defaults. Changes save in `Escapists.json` and apply next round; existing units and cover stay in place. `show` and `help` also work for each chat command.
+
+Roads at or above the width cutoff get large checkpoints; roads below it get compact posts. This is a width classification from the terrain's road network, not a guaranteed asphalt/dirt or forest distinction. An exhausted or disabled quota cannot consume the other type's allowance. Both types share the existing minimum spacing, so they cannot overlap each other.
+
+Small checkpoints retain four guards, four sandbag walls, two approach barriers and two signs (about 17.8 m long). Large checkpoints have eight guards, eight sandbag walls, four approach barriers and two signs (about 42.8 m long), with four protected guard bays on each shoulder. Large candidates require at least 60 m of road and a straight clear approach. Both preserve a straight vehicle passage at least four metres wide.
+
+Soldiers come from the selected enemy faction, use normal equipment and physical radio reporting, and register with VirtualHQ at their actual four- or eight-soldier strength. They do not reveal player locations simply by spawning. Guards are not replaced after death. Every post is constructed one actor, prop or waypoint per callback; a failed or interrupted build rolls back without consuming either quota. At maximum settings the two types can create up to 360 guards and 660 replicated props; their default combined count is eight posts and 48 guards. The Status page reports placed/requested counts separately.
 
 Placement uses the loaded terrain's road network and Soldiers navmesh after
 terrain/site preparation. The initial search yields after 12 seconds; unfinished
@@ -64,6 +67,10 @@ requested totals instead of preventing mission startup. The admin Status page
 also shows these totals. This is an interim checkpoint system, independent of the
 existing HQ-directed road interceptions.
 
+The [1 November native checkpoint test](evidence/large-checkpoints-2026-11-01/native-checks.log) placed one small and one large post on Everon: 12 living guards, 22 replicated props, correct HQ strength, model footprints outside the centre passage, and separate completed quotas. The [menu/settings fixture](evidence/large-checkpoints-2026-11-01/menu/native-checks.log) saved and reloaded distinct counts and width, and measured the new controls’ native text bounds. It instantiates the generated layout directly; it does not claim human input, remote RPC delivery or screenshot acceptance. Both completed with unchanged inputs and cleanup; strict runners retain 13 existing resource/world errors and no script errors. Earlier failed iterations are recorded alongside the evidence. Full-load performance and multiplayer acceptance remain unmeasured.
+
+Fresh settings now initialize both drone keys, including the valid 300-second cooldown; the missing cooldown previously prevented a fresh settings document from passing save/readback validation.
+
 ## Šárka special-forces hunters
 
 Under **Forces → Šárka hunters**, set **Anger points per Šárka** from 1 to 30.
@@ -124,9 +131,12 @@ for at least 15 minutes after a disconnect, including a client crash. A longer
 native `operating.slotReservationTimeout` is respected, as is its unlimited
 setting. Rejoining with the same authenticated account returns control of that
 body, keeping its inventory, injuries and vehicle seat. It stays vulnerable while
-the player is away. Expiry, death or a different round does not grant a replacement
-life or duplicate equipment. This is recovery within the running mission, not
-saved characters across server restarts. Reconnect reservation, rejection and
+the player is away. If the reservation is missing, expired or its body has died,
+reconnecting grants a fresh soldier through normal admission before extraction
+begins. The new soldier uses the normal loadout, without copying old equipment.
+A valid reservation whose handoff fails remains reserved instead of granting a
+second soldier. New rounds start with fresh admission records; characters are
+not saved across server restarts. Reconnect reservation, rejection and
 successful handoff are logged without account identifiers.
 
 The root has `"configVersion": 1`. Missing legacy files get defaults. Existing