Files
EscapistsReintroduced/docs/vehicle-security.md
T

7.0 KiB

Supply vehicle interaction lock

The optional Western supply cache 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 changes one replicated boolean. 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.

An alarm is deferred. No audible/visible alarm, silent HQ alert, target knowledge or new tactical timer is emitted. A later alarm requires a verified physical cue and the existing observer/radio delivery path.

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

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

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.