Purpose & Player Value
Locks make exploration, vehicle recovery and persistent bases contestable without making every secured object use the same access method. The system distinguishes physical access, installed ownership locks and vehicle ignition authorization.
Design status: confirmed 2026-09-17. Runtime implementation and PIE verification are not claimed.
Scope
- Built-in lock state on vehicles, doors and windows.
- Lootable Lock items installed as an independent second lock layer on doors, windows, World Containers and Player-built Storage.
- Owner/Squad authorization for installed Lock items.
- Lockpick-skill and equipment-gated attempts on every lockable target.
- Vehicle-specific key discovery, inserted keys, cabin Lockpick and permanent Mechanics-skill Hotwire.
- Authoritative replication and later-phase durable state for all lock, key and bypass state.
Out of Scope
- Containers other than World Containers and Player-built Storage cannot accept a Lock item.
- Vehicle keys do not secure integrated Vehicle Storage.
- Lockpick does not bypass vehicle ignition; it unlocks cabin entry only.
- Exact skill names, equipment identities, action duration, success/failure rules, loot weights, damage rules and vehicle operational-readiness rules are not approved.
- No runtime implementation or asset existence is asserted by this design decision.
Terminology
| Term | Project meaning |
|---|---|
| Built-in lock | Lock capability owned by the door, window or vehicle object rather than an inventory item. |
| Installed Lock | A found inventory item attached to an eligible target. It is an independent second lock layer and does not replace a built-in lock. |
| Vehicle key | An item bound to one exact stable Vehicle ID. It authorizes ignition/driving, not Vehicle Storage. |
| Inserted key | The matching key left in the vehicle so the vehicle can use that key without a character carrying it. |
| Lockpick | A Lockpick-skill and equipment-gated action against a lock. On vehicles it unlocks cabin access but does not authorize ignition. |
| Hotwire | A Mechanics-skill vehicle action that permanently removes the ignition key requirement for everyone. |
| Vehicle spawn point | The vehicle's original spawn location used to select nearby key loot sources; moving the vehicle does not move that association. |
Functional Behavior
Target matrix
| Target | Initial / built-in rule | Installed Lock | Authorized access | Bypass |
|---|---|---|---|---|
| World-existing door or window | 30% chance to be locked on initial spawn. | Allowed as a second layer. | Built-in layer follows side rules. Installed layer requires owner or current Squad member. | Lockpick may defeat each applicable lock. |
| Player-built door or window | Starts unlocked. | Allowed as a second layer. | Built-in layer follows side rules. Installed layer requires owner or current Squad member. | Lockpick may defeat each applicable lock. |
| World Container | No built-in lock. | Allowed. | Installed-lock owner or current Squad member. | Lockpick. |
| Player-built Storage | No built-in lock. | Allowed. | Installed-lock owner or current Squad member. | Lockpick. |
| Other container types | No built-in lock. | Not allowed. | Normal container rules. | Not lockable through this system. |
| Vehicle | 90% chance to spawn locked; 10% spawn unlocked and may be driven without a key when operationally ready. | Not part of the confirmed vehicle rule. | Matching key or inserted matching key authorizes ignition. Squad membership alone grants no vehicle-key access. | Lockpick unlocks cabin access only. Hotwire permanently bypasses ignition for everyone. |
Door and window side rules
- A player outside cannot open a built-in-locked door or window.
- A player inside may command Lock or Unlock on the built-in layer.
- Attempting to open a built-in-locked door or window from the inside automatically unlocks that built-in layer before opening.
- An installed Lock remains an independent second layer: being inside does not bypass it; the actor must be its owner, a current member of the owner's Squad, or successfully Lockpick it.
Installed Lock lifecycle
- A Lock item is found in the world and installed on an eligible target.
- The installed Lock can be removed and returns the Lock item rather than destroying it.
- Exact removal authorization and interruption rules remain
TBD-LOCK-002.
Vehicle access and ignition
- A locked vehicle blocks cabin entry. Successful Lockpick opens cabin access only; starting/driving still requires the matching key, an inserted matching key, or permanent Hotwire.
- A vehicle that initially spawns in the confirmed 10% unlocked state may be driven without a key if its separate operational-readiness requirements are met.
- Matching keys may appear in nearby World Containers or as drops from zombies near the vehicle's original spawn point. The lookup uses the spawn point, never the vehicle's current location.
- Hotwire requires the Mechanics skill. Success is permanent, persists across restart/unload, has no cancellation condition and allows everyone to drive without a key.
- Vehicle Storage is not controlled by the vehicle key and is not eligible for the installed Lock item under the confirmed container list.
States & Flows
Initial world object
First spawn → perform the target's one-time confirmed lock roll → store the result under the stable object identity → restore the stored result without rerolling after unload or restart.
Installed Lock
Eligible target + Lock item → authoritative install → independent installed-lock layer active → owner/Squad access or Lockpick → authoritative removal returns the item.
Locked vehicle recovery
Find vehicle → obtain cabin access with matching key or Lockpick → satisfy ignition with matching/inserted key or permanent Hotwire → satisfy separate operational readiness → drive.
Vehicle key discovery
Stable Vehicle ID + original spawn point → eligible nearby World Container/zombie source → matching key item bound to that Vehicle ID. Moving the vehicle does not change eligible source proximity.
Rules & Edge Cases
- All random lock rolls occur on initial spawn only. Persisted objects must not reroll on restart, stream-in or rejoin.
- Every active lock layer is authoritative and independent. Passing one layer does not silently remove another layer.
- Installed-lock Squad access is evaluated from authoritative current membership; stale client membership cannot grant access.
- Vehicle Lockpick and Hotwire are distinct: Lockpick changes cabin accessibility, while Hotwire changes ignition authorization.
- An inserted key remains the same item instance bound to the exact Vehicle ID; duplication, loss and transfer must use inventory/persistence transactions.
- Lockpick, install, remove, key insertion/removal and Hotwire must reject stale state and simultaneous conflicting actions server-side.
Authority & Persistence
The dedicated server and embedded Single Player authority validate every lock mutation. This feature is later-phase persistent world state and is not part of the currently implemented P07 player/pickup record set.
| Record owner | Durable state required |
|---|---|
| Door / window / eligible container | Stable target ID, built-in lock state where applicable, installed Lock item instance/link, installed-lock owner identity, and state needed to restore the target without rerolling. |
| Vehicle | Stable Vehicle ID, original spawn point, initial lock outcome, current cabin lock state, ignition/key requirement, Hotwire state and inserted-key item link. |
| Vehicle key item | Exact bound Vehicle ID and its current authoritative location: character inventory, world/container inventory or inserted in the vehicle. |
Capture/restore must extend USaveSubsystem / ULambeerWorldPersistenceSubsystem through the later building/vehicle persistence phases; do not create an ad-hoc authoritative SaveGame path. See TECH-NETWORK-ARCH.
Dependencies
FEAT-BUILDING— doors, windows and Player-built Storage.FEAT-VEHICLES— vehicle identity, condition, storage and full-state persistence.FEAT-INVENTORY— Lock/key item instances and transactional transfer.FEAT-CLANS-SQUADS— current Squad membership used by installed locks.FEAT-PVP-RAIDING-TRADING— hostile Lockpick and raid access.FEAT-CRAFTING-PROGRESSION— Lockpick/Hotwire skill definitions remain to be selected.TECH-NETWORK-ARCH— authority and persistence.PIPE-ROADMAP— delivery mapping.DEC-BACKLOG— remaining TBDs.
Source of truth for the confirmed behavior is this document. Runtime item/class/asset paths are not yet verified.
Acceptance Criteria
AC-LOCK-DOC-001: canonical docs distinguish built-in and installed locks, cabin access and ignition, key and Hotwire, and eligible versus ineligible containers.AC-LOCK-SPAWN-001: after implementation, first-spawn sampling produces the confirmed 30% door/window and 90% vehicle locked chances; save/reload never rerolls an existing object.AC-LOCK-SIDE-001: an outside player cannot open a built-in-locked door/window; an inside player can unlock or auto-unlock-on-open; an installed second layer still requires owner/Squad or Lockpick.AC-LOCK-SQUAD-001: current Squad membership grants installed-lock access; leaving/removal revokes it without trusting stale client state.AC-LOCKPICK-001: Lockpick can target every lockable category; a vehicle Lockpick permits cabin access but never starts the vehicle.AC-VEHICLE-KEY-001: only the exact Vehicle-ID key, an inserted exact key or permanent Hotwire starts a secured vehicle; Squad membership alone does not.AC-VEHICLE-HOTWIRE-001: successful Hotwire survives unload/restart and permits every player to drive without a key.AC-VEHICLE-KEY-LOOT-001: key-source proximity uses the vehicle's original spawn point after the vehicle moves.AC-LOCK-SAVE-001: lock layers, ownership, key binding/location and Hotwire restore exactly once without duplication or state reset.
All runtime criteria require owner PIE evidence after implementation; none are marked passed here.
Open Questions
TBD-LOCK-001 — Skill actions and tuning
Approve Lockpick/Mechanics proficiency requirements, required equipment, duration, interruption, success/failure, equipment consumption/durability, feedback and authoritative anti-exploit rules.
TBD-LOCK-002 — Installed Lock content and lifecycle
Approve Lock item identity, loot frequency, installation/removal authorization, damage/destruction behavior, ownership transfer, Squad-change edge cases and presentation/audio assets.
TBD-LOCK-003 — Vehicle readiness and key population
Define the separate vehicle operational-readiness conditions and the numeric key-population rules for nearby World Containers and zombies. The source uses the original vehicle spawn point; radii, candidate counts, duplicate policy and loot probability are not approved.
Revision History
2026-09-17: Added the owner-confirmed Lock & Access design covering built-in and installed lock layers, spawn chances, side rules, Squad access, universal Lockpick targets, removable Lock items, Vehicle-ID keys, original-spawn-point key sources, inserted keys and permanent Hotwire.