Vehicle possession is a state handoff

845. Lesson identity

Module

2.12 — Navigation, maps, and vehicles

Lesson

Vehicle possession is a state handoff

Academic type

Guided Build

Schema type

practical

Order

2

Estimated time

35–45 minutes

This lesson models entering, exiting, and controlling a vehicle without creating two competing movement authorities.

846. Learning objective

After this lesson, you can produce and trace a five-state possession diagram that identifies legal transitions, the movement-input owner, interruption handling, unavailable conditions, and invalid-state prevention for a player and one vehicle.

847. Why this matters

Possessing a vehicle changes which entity interprets movement-control signals. If the player character and vehicle process those signals at the same time, the result can include duplicated movement, stuck controls, or an undefined exit. An explicit transition contract makes ownership, rejection, interruption, and recovery behavior reviewable before implementation.

848. Prior knowledge

You should already be able to distinguish a map representation from current world state, as covered in 2.12 L1 — A map is not the world state. You should also be comfortable describing behavior through states and transitions rather than treating presentation as authority. A finished vehicle implementation is not required.

849. Core concept

Vehicle possession is an authority handoff represented by five explicit states:

1. PlayerControlled: the player character receives movement-control signals.
2. Entering: an accepted vehicle-entry handoff is in progress. One transition coordinator decides the outcome, and movement is blocked.
3. VehicleControlled: the vehicle receives movement-control signals.
4. Exiting: an accepted vehicle-exit handoff is in progress. One transition coordinator decides the outcome, and movement is blocked.
5. Unavailable: neither ordinary stable state is currently a safe recovery target. No entity receives movement-control signals until the coordinator restores a verified stable state.

The central invariant is never two movement authorities at once. PlayerControlled and VehicleControlled each have exactly one movement-input owner. Entering and Exiting have one handoff decision authority but no active movement-input owner. Unavailable is exceptional: use it only when the system cannot safely restore either ordinary source state, such as when the required entity or possession context is missing or internally inconsistent.

Do not use Unavailable for an ordinary rejected request:

• an entry request rejected before the handoff starts remains PlayerControlled;
• an interrupted entry returns to PlayerControlled when the player remains a valid recovery target;
• an exit request with an invalid destination remains VehicleControlled;
• an interrupted exit returns to VehicleControlled when the vehicle possession context remains valid;
• only loss of both safe ordinary recovery choices enters Unavailable.

Keep these concerns separate:

• Possession state: which of the five states applies.
• World state: whether the player, vehicle, occupancy, and destination conditions are valid.
• Presentation state: animation, camera, visibility, prompts, and effects.
• Input routing: which entity receives movement-control signals, or whether movement is blocked.

Presentation reflects the authoritative possession state; it does not determine it.

850. Deterministic transition contract

Every arrow must name five fields: request or event, precondition, decision authority, movement-input rule, and failure or recovery route.

PlayerControlled --[enter request
  | player valid; vehicle exists, is available and unoccupied; player is in range
  | coordinator accepts
  | block movement
  | rejected request -> PlayerControlled]--> Entering

Entering --[entry commit
  | player, vehicle, attachment, and possession context remain valid
  | coordinator commits vehicle authority
  | remain blocked until commit; then vehicle receives movement signals
  | interrupted but player safe -> PlayerControlled;
    neither stable recovery safe -> Unavailable]--> VehicleControlled

VehicleControlled --[exit request
  | vehicle possession remains valid; exit destination is valid
  | coordinator accepts
  | block movement
  | invalid destination or rejected request -> VehicleControlled]--> Exiting

Exiting --[exit commit
  | player, vehicle, detachment, and destination remain valid
  | coordinator commits player authority
  | remain blocked until commit; then player receives movement signals
  | interrupted but vehicle possession safe -> VehicleControlled;
    neither stable recovery safe -> Unavailable]--> PlayerControlled

Unavailable --[recover player control
  | player exists in a verified safe controllable state and no vehicle authority is active
  | coordinator restores player authority
  | movement remains blocked until recovery commits
  | failed validation -> Unavailable]--> PlayerControlled

Unavailable --[recover vehicle control
  | vehicle and possession context are verified, the player remains validly possessed,
    and no player movement authority is active
  | coordinator restores vehicle authority
  | movement remains blocked until recovery commits
  | failed validation -> Unavailable]--> VehicleControlled

A renewed entry or exit request does not jump directly out of Unavailable. Recovery first establishes PlayerControlled or VehicleControlled; the normal entry or exit transition may then begin. This prevents a retry from silently bypassing a stable-state invariant.

851. How to classify failures

Use the current safe recovery target rather than the failed action to choose the result.

852. Concrete example

A player stands beside an available, unoccupied vehicle. The possession system validates proximity, availability, and occupancy before accepting the entry request. Acceptance enters Entering, where the coordinator blocks movement. If the attachment and possession context remain valid, the coordinator commits VehicleControlled; only then does the vehicle receive movement-control signals.

If the vehicle becomes occupied during the handoff but the player remains valid outside it, the coordinator cancels the handoff and restores PlayerControlled. This is not an Unavailable case because the source state is still safe.

While the vehicle is controlled, the player requests an exit. If the destination is blocked, the request is rejected and the model remains VehicleControlled. If the destination passes validation, the model enters Exiting. A successful detachment commits PlayerControlled. If the destination becomes invalid during the transition while vehicle possession remains intact, recovery returns to VehicleControlled.

Use Unavailable only if an interruption leaves the coordinator unable to verify either stable recovery. From there, movement remains blocked until an explicitly labeled recovery validates and commits exactly one stable authority.

853. Common mistakes

Using one boolean

A boolean such as isInVehicle cannot represent accepted-but-incomplete entry, accepted-but-incomplete exit, or exceptional recovery. Independent systems may interpret it at different times and accidentally enable both movement handlers.

Treating animation as authority

An animation event can be evidence that a presentation step finished, but it must not decide possession by itself. The transition coordinator commits the authoritative state only after its required conditions remain valid.

Sending every failure to Unavailable

An ordinary rejection should preserve its safe source state. Overusing Unavailable hides whether player or vehicle control could have been restored immediately.

Giving a retry an arbitrary destination

A retry from Unavailable must not automatically grant player control or start entry. It must validate one explicit recovery target and commit that stable state first.

854. Guided practice

Create a possession-state diagram and decision table for a player and one vehicle. Use paper, a text editor, or a diagramming tool; implementation code is not required.

Step 1: Define the five states

Include PlayerControlled, Entering, VehicleControlled, Exiting, and Unavailable. For each state, identify:

• who decides a transition;
• who receives movement-control signals;
• whether movement is blocked;
• the invariant that must hold.

Step 2: Draw the normal handoffs

Draw entry as PlayerControlled -> Entering -> VehicleControlled and exit as VehicleControlled -> Exiting -> PlayerControlled. Label every arrow with the request or event, precondition, authority, movement-input rule, and failure or recovery route.

Step 3: Add deterministic rejection and interruption paths

Show that:

• a rejected entry remains or returns to PlayerControlled when player control is safe;
• an invalid exit destination remains or returns to VehicleControlled when vehicle possession is safe;
• Unavailable is reached only when neither stable recovery can be verified;
• Unavailable has separate, validated recovery arrows to PlayerControlled and VehicleControlled.

Add at least three interruption cases, including one during entry and one during exit.

Step 4: Mark invalid states

Identify at least five invalid combinations and pair each with a prevention invariant. Include:

• player and vehicle both receiving movement-control signals;
• neither entity receiving signals after a stable transition has committed;
• presentation disagreeing with authoritative possession;
• exit committing without a valid destination;
• Unavailable granting movement authority;
• a recovery transition granting authority before validation.

Step 5: Complete two or more traces

At minimum, trace:

1. a successful entry followed by a successful exit;
2. a failed exit caused by a blocked destination.

For stronger coverage, also trace an interrupted entry that returns to PlayerControlled and an exceptional interruption that enters Unavailable before recovering to a verified stable state.

For every trace, record the starting state, event, precondition result, deciding authority, movement-input rule, destination state, and relevant invariant.

855. Validation and evidence

Submit the five-state diagram and decision table through the linked practical assessment. The work is complete when:

• all five canonical states are present;
• ordinary failed entry recovers to PlayerControlled when that state remains safe;
• an invalid or interrupted exit preserves VehicleControlled when possession remains safe;
• Unavailable has one precise meaning and blocks movement;
• both recovery arrows from Unavailable have explicit, distinct validation conditions;
• every transition includes all five required labels;
• interruption results are deterministic;
• at least five invalid combinations have prevention invariants;
• at least two traces can be followed without inventing an unstated arrow.

A reviewer should be able to answer at each transition: What happened? What had to be true? Who decided? Who receives movement-control signals? Where does rejection or interruption go?

856. Key takeaways

• Possession is an authority handoff, not merely a visual effect.
• Stable states have exactly one movement-control owner.
• Transitional and unavailable states block movement under one coordinator.
• Ordinary failure restores or preserves its safe source state.
• Unavailable is reserved for cases where neither ordinary stable recovery can be verified.
• Recovery from Unavailable must explicitly validate and commit one stable state before another request begins.

857. Next lesson

Continue to 2.12 L3 — Arrival is a contract, not a distance guess.

858. Knowledge check