EscapistsReintroduced/docs/vehicle-security.md

Supply vehicle interaction lock

The optional normal Southern-cache UAZ and historical Western-fixture UAZ uses the successor-owned SupplyUAZ.et and SupplyUAZRearSeats.et prefabs. Its driver-door Force vehicle lock action has four seconds of native held progress. Ordinary entry and door-opening actions remain blocked until one successful breach. This is newly authored gameplay using vanilla vehicle systems; it does not reproduce predecessor parameters or import original Escapists code.

ERR_SiteService.CreateTransport configures the component during mission preparation and rejects failed configuration. The interaction lock starts closed before configuration reaches replicas. Configuration never resets a breached vehicle. Five entry actions (two front and three attached rear seats) and four door-opening actions have scoped guards; after breach they delegate to the original native rules. Exit, seat switching and door closing retain vanilla behavior. Other vehicles are unaffected.

At completion, the server rechecks the active mission and currently admitted player body, alive/conscious/on foot, a living and empty vehicle, speed at most 0.25 m/s and angular speed at most 0.1 rad/s, distance at most two metres from the authored driver-door anchor, and clear native trace reach. Success unlocks the replicated interaction state and starts the one-shot horn alarm. Duplicate requests cannot reset or repeat the transition. The feature creates no actors or vehicles, forces no boarding and changes no inventory or supplies.

Scope and limits

The entry and door guards wrap vanilla local-effect actions on the executing client. They are not an authoritative barrier around engine, Game Master or scripted boarding APIs. Breach itself requests server-first nonlocal execution, disables broadcast and independently rejects replica mutation and stale player bodies. Native action duration supplies held progress/cancellation; the component does not independently attest four elapsed server seconds or continuous server-side proximity. This is an interaction lock, not an anti-cheat system.

A successful server breach now starts an eight-second horn alarm. Replicated state advances from unused to active to completed; completed replicas never restart playback on a duplicate active callback. The authority applies its state locally, while clients wait for an active mission within their own fixed eight-second cap. Once bound, mission inactivity or replacement ends the local alarm immediately. Late joiners can hear an ongoing alarm only until its stop update or local cap, and completed state cannot replay it.

One component-owned AudioSystem.PlayEvent handle uses the vanilla UAZ horn ACP with explicit HornState=1, following the vehicle's local horn point 0 1 1.2. No driver input or shared vehicle sound signal is changed. Audio submission is attempted once, including failure. Dedicated servers skip audio. Timeout, destruction, mission stop and component deletion clear callbacks, unsubscribe and terminate only that owned handle. Deletion does not publish replication updates from a dying component.

The historical audio checkpoint below proves only scoped sound state and cleanup. Current source also emits tagged local native alarm evidence for the existing radio/HQ path, described in the later alarm-evidence section. Actual hearing/event delivery, audible waveform, spatial presentation and real remote/late-join behavior remain qualification work.

Vanilla provenance

Only vanilla inheritance references and the component, compartment and action identities needed for minimal scoped overrides were used. New resource identities belong to the successor. The source prefab text below was read from the installed vanilla resources; SHA-256 values identify the exact inspected bytes.

Vanilla resource	SHA-256
Prefabs/Vehicles/Wheeled/UAZ469/UAZ469.et	e87d85770ebca2730d642ef326df59a4e7ce64835596f49e229c432f27438fa6
Prefabs/Vehicles/Wheeled/UAZ469/UAZ469_base.et	e5df2bd070b156a12921152484a5c3b0d66f089c4535ecc4fea95a2acd02ea40
Prefabs/Vehicles/Wheeled/UAZ469/VehParts/Seats/UAZ469_seats_rear.et	1655869b65546781788b96cad770ce577483f2dd2247ab1185005babd939f1aa
Sounds/Vehicles/Wheeled/UAZ469/Vehicles_UAZ469_Horn.acp	6d04ff2c0d40c8455edd83dd2f24ce8e59f2f50719fac2c7a490b67886b5aafe

The root inherits {259EE7B78C51B624}Prefabs/Vehicles/Wheeled/UAZ469/UAZ469.et; rear seats inherit {780AAF0A51AEE61A}Prefabs/Vehicles/Wheeled/UAZ469/VehParts/Seats/UAZ469_seats_rear.et. The native SDK references are SCR_GetInUserAction, SCR_CompartmentUserAction, SCR_OpenVehicleDoorUserAction, ScriptedUserAction, SCR_BaseLockComponent, the all-compartments query, coordinate conversion and camera-layer trace APIs.

Validation

tests/test_vehicle_security.py executes the actual eligibility, final server mutation and scoped action methods with native API doubles. It covers stale/absent bodies, replica/direct requests, actor life state, motion, occupied compartments, reach/LOS, repeated completion, and preservation of native rejection/delegation. Resource checks cover all five seat and four door overrides and the shared held-action anchor.

The controlled native checkpoint below verifies prefab action substitution, five-compartment aggregation and the authored lock reach at this site. Ordinary playtesting must still verify actual held-input cancellation and menu-driven boarding/driving after breach, including different terrain conditions. Multiplayer testing must verify server-first callback execution, remote and late-join replication, simultaneous completions, disconnect/body replacement during the hold, and consistent entry blocking on other clients. Policy tests alone do not qualify those engine behaviors.

Native diagnostic checkpoints

The 30 September alarm checkpoint completes 135 assertions and one round with zero script/runtime failures and thirteen installed-resource errors. It observes one valid unfinished native horn handle after breach, clears both alarm state and handle at the fixed deadline, rejects replay, then completes the existing boarding, engine, finite-fuel and vehicle-loss checks. This is the historical Western transport fixture, not normal human input or remote audio proof. Source/external inputs remain unchanged and hidden/muted cleanup is confirmed.

The initial attempt remains failed: the diagnostic incorrectly treated AudioSystem.IsSoundPlayed as currently playing. Three vanilla callers use it to retire finished sources; the getter and test double now use that completion meaning. Playback submission/lifecycle were unchanged by this correction. All 240 repository programs pass, with final focused getter/ownership regressions separately recorded here. No waveform was captured, and muted native handle evidence does not establish perceived audio or AI hearing.

05:20:53 compiled the Core changes but stopped on an old fixture assumption that the depot used the raw vanilla UAZ. The physical identity assertion now expects the exact successor SupplyUAZ resource; vanilla faction catalog contents are unchanged.

05:22:47 passes 100 assertions before refusing the post-unlock driver-availability check. It confirms the actual five entry actions (two root, three attached rear), four guarded door actions, initially rejected callbacks, real stationary vehicle and driver-lock trace/distance, one successful server unlock, duplicate refusal and disappearance of the breach action. It does not qualify native menu-held input or multiplayer. The direct driver-availability call's inherited refusal still needs its actual door-context/reason diagnosed; production faction or boarding rules have not been bypassed to force a pass. Both failed runs and cleanup/source evidence are retained.

05:29:15 native checkpoint completes one round with 124 assertions and zero captured script/runtime or engine errors. It confirms the lock checks above, then executes the existing native driver/passenger seating, engine start, finite fuel depletion, vehicle loss and no-replacement checks. Original test-body damage handling and location are restored by the security prelude; private process cleanup and unchanged source are confirmed.

The earlier entry refusal was a missing diagnostic door context: actual native state reported a neutral empty vehicle, no faction hostility, no base lock, an empty/unreserved driver seat, and stored/resolved door -1. The seat's own declared door was 0 and its native access query succeeded. Only for that missing-context case, the WORKBENCH probe now temporarily supplies the unique declared driver door through the stock action setter, runs the unchanged availability chain, and restores the previous index. Availability then succeeds. No production faction change or entry-rule bypass was necessary. This is direct diagnostic API use, not proof of actual menu selection, held input or network delivery.

The full companion integration recheck subsequently compiles all current addon sources and completes 56 HQ-memory assertions without script/runtime failures. The four known RHS/WCS localization errors remain; the successful Core vehicle run is the direct security evidence.

Local alarm evidence for HQ (30 September 2026)

A successful authoritative alarm now emits one tagged native vehicle-horn danger event carrying its original mission, time and position. A receiving soldier reads only its own native danger queue before vanilla threat processing clears it. The receiver must be a living, conscious, non-player member of the current enemy group, within 50 metres of the original sound. Work is capped at 32 queue entries. Ordinary horn events and old-mission/stale events are ignored; native processing still runs normally. There is no global listener lookup or synthetic gunfire.

The group's existing bound perception cache keeps alarm evidence separately from visual sightings and gunfire. Position is rounded to the existing 150-metre sound area, callbacks cannot refresh an old timestamp, and queueing spends a separate 30-second cooldown. The ordinary radio route must deliver before HQ remembers it. ALARM memory starts at confidence 0.25, halves every 45 seconds, and keeps a 150-metre uncertainty radius growing by two metres per second. Memory retains only source, time, approximate position and message identity; alarm reports cannot supply a target, movement, weapons, headcount or casualty claim.

HQ may assign at most one existing mobile search group across all alarm beliefs, including pending radio orders. Home guards cannot be selected. Planning and order delivery enforce search-only behavior, and alarm reports stay outside the sighting-only fire-support/contact path. A delivered negative sweep reduces the belief. The journal labels alarm reports and investigation orders distinctly.

Actual-method tests cover emitter identity/time, receiver caps/range/ownership, local deduplication and priority, detached sanitization, confidence/uncertainty, global response reservation and delivery-time policy. Native compilation initially rejected the reserved local identifier event; that failure is preserved and the identifier is corrected. Actual engine danger-event distribution, subclass retention, audibility/attenuation, radio receipt from a heard alarm and remote clients remain unqualified. Native mounted-reporting checks compile this code but do not exercise alarm hearing.

Native alarm-hearing fixture (1 October 2026)

The explicit WORKBENCH-only alarm-hearing fixture uses an existing original on-foot radio soldier, its naturally bound awareness cache and an existing site UAZ. It reserves an idle group through the normal logistics token, saves and relocates only that witness into a checked clear hearing area, and permits one production emitter call. It observes local evidence, a pending ordinary radio route before HQ knowledge, and eventual matching memory; it does not insert a perception/report or advance radio delivery. Cleanup restores the original body transform when ownership and consciousness still agree, releases its exact token, and restores the observer's saved damage setting. Its fixed deadline is 120 seconds.

The first attempt passes 35 assertions, emits once, then expires without a local alarm or delivered alarm report. It also observes unrelated natural status delivery from the reserved group, but this does not demonstrate alarm hearing. The failed result is retained.

The instrumented retry passes 34 assertions and diagnoses its arrangement: after relocation, the selected witness is inactive at native LOD 10 (permanent LOD -1), even though danger events are enabled, group/faction eligibility and perception binding agree, and distance is 20.0157 metres. The new post-relocation guard refuses before emission. Queue counters therefore remain zero; this is not evidence that native distribution loses the custom event subclass. Selected-witness diagnostics read at most 32 native queue entries before normal processing and never consume or add events.

Both attempts retain two fixture failures and thirteen installed-resource errors, with unchanged source/external inputs and verified hidden/muted cleanup. The next arrangement should keep the existing witness and alarm vehicle in a naturally active player area, restoring any arranged observer movement afterward. Do not force AI activation/LOD or add global listener lookup to make the test pass. Native distribution, custom-event retention, actual alarm radio delivery, human breach input, audible presentation and remote clients remain unqualified.

Native alarm delivery and memory lifetime correction

The arrangement now retains the exact canonical player observer as well as the original radio witness. Both destination volumes must be clear before either body moves. The observer is placed 300 metres from the existing UAZ and the witness 20 metres away; the fixture waits for normal native activation within the same fixed deadline. It never changes AI activation or permanent LOD. Cleanup restores each original body independently while its current identity, life, on-foot and ownership checks still hold. A replaced/dead/aboard observer is not moved. These fixture paths have actual-method regression coverage.

The first active-scene attempt reached native LOD 3, heard the event and observed the pending ordinary alarm radio frame. It then reproduced a VM null-pointer exception at delivered-memory intake: a block-local sanitized report was assigned to a weak parameter and lost its strong owner before later field access. The fix retains a function-scope strong reference until the track copies it, preserving detached sanitization and leaving the caller unchanged. The raw-pointer C++ adapter cannot prove Enforce lifetime; its explicit source-scope guard supplements existing value/isolation regressions.

The native retained-owner retry completes 55 scripted checks and one round with zero script/runtime failures. It proves native event delivery into the selected witness's queue, ordinary pending radio state before HQ knowledge, and a completed matching route delivering the original time, coarse area and anonymous alarm into production memory. Repeated route-wait checks contribute to that assertion count. Both attempts retain thirteen installed-resource errors, exact launch source/seven external inputs and confirmed hidden/muted process cleanup. The strict resource qualifier remains failed.

This is an arranged existing-body/event test. It does not prove human breach input, audible/spatial presentation, a dispatched patrol's physical arrival, remote/late-join clients or general multiplayer behavior. Earlier failed inactive- witness and lifetime attempts remain preserved; none is relabeled successful.