Vehicle Driving in UE5: Seat Reservations, Driver Handover, and Command Arbitration

In the previous article, City Traffic in UE5: Continuous Cruising, Car Following, Lane Changes, and Junction Access, we followed vehicles along their routes. This article examines changes around one vehicle: the current driver leaving, another character taking over, a script temporarily controlling the vehicle, and the cleanup of seats and commands after an exit.

During a handover, the applicant, actual occupant, driver, and command source have separate states. A character can request entry while the original driver still occupies the driver seat. A script can take control without changing the driver. Collapsing these roles into a single “current controller” loses the intermediate relationships.

This implementation follows the division of responsibilities described in Vehicle Driving Runtime, Part 1: Persistent Driving Intelligence, Seat Relationships, and Driving Authority. The article distinguishes the reference mechanisms, the UE implementation, and the demonstration setup. Simplified character motion makes the prototype observable; complete entry and exit tasks remain to be integrated.

The seven videos are separate recordings from one validation map, each organized around one vehicle. They cover passenger entry, cancellation and retry, driver handover, scripted control, exit restrictions, retrying input after exit, and repair of inconsistent records. We begin with the structures and interface layers that own the state, follow each relationship operation, and then connect logical commits to UE physics feedback. Code explanations sit beside the relevant operations, and the videos retain their original order.

What relationships does a vehicle need to store?

Ped means the logical character entity, which stores the character’s runtime state. Vehicle means the logical vehicle entity, including its seats. The physical body is the UE physics object that supplies measured position, velocity, and orientation. An Actor is a UE scene object; “showcase Actor” below specifically means the object that orchestrates the cases, camera, and presentation. “Vehicle” in ordinary prose can also refer to the vehicle in the scene. Character and vehicle models present these states; overlapping their positions does not establish seat occupancy. Driving eligibility here means passing the current command-acceptance checks. It does not include network ownership, server authorization, or client prediction authority.

The Vehicle owns a seat table. Each seat stores an actual occupant and a reservation independently. The Ped stores its current vehicle, seat index, and driver flag. A separate command-ownership record identifies the character, seat, and, where applicable, task session that submitted the accepted control command.

Contents

• What relationships does a vehicle need to store?
• How the relationship interfaces are layered
• Reservations and actual entry are separate commits
• Request identity isolates cancellation from retry
• Driver handover can contain an interval with no eligible driver
• Driver identity and command source are arbitrated separately
• Rejected exits preserve relationships; successful exits clear eligibility
• Repairing inconsistent occupancy records
• Connecting UE update phases to physical execution
• Following one handover through state, results, and next actions
• What the seven videos establish
• Notes on AI-assisted development

The reciprocal records let a Vehicle query its driver-seat occupant and a Ped query its current vehicle and seat. Both results should describe the same relationship. If the driver seat names B while B’s own record points to another vehicle, that seat entry is insufficient grounds for accepting B’s driving command.

Key operations check entity handles, vehicle identity, and seat identity together. An existing character and a valid seat index establish basic object conditions, but the occupancy relationship may already have changed. Eligibility is queried from current state rather than retained from an earlier successful check.

In the reference mechanism, driving intelligence and driving tasks belong to the vehicle side; the character supplies driver identity and related behavior. The UE implementation keeps this division: logical entities maintain seat and task relationships, while scene Actors and physics components present and execute them. This avoids separate, unrelated “current driver” records in the character, vehicle, and showcase Actor.

Reading the state boundaries from the structures

Ped occupancy, vehicle seats, reservations, and command ownership use separate structures. The following C++ excerpts use neutral type names and retain the field semantics of the current UE implementation. Export macros, constructors, diagnostic fields, and project dependencies are omitted; these are not drop-in headers.

struct SeatReservation {
    bool reserved = false;
    EntityHandle ped, vehicle;
    int32 seat = INDEX_NONE;
    EntityHandle requestedBy;
    FName taskTag = NAME_None;
    int32 requestSerial = 0;
};

struct VehicleSeat {
    int32 index = INDEX_NONE;
    EntityHandle occupant;
    SeatReservation reservation;
    bool occupied = false;
    bool driverSeat = false;
};

struct PedOccupancy {
    EntityHandle vehicle;
    int32 seat = INDEX_NONE;
    bool inVehicle = false;
    bool driver = false;
    int32 occupancySerial = 0;
};

VehicleSeat contains both occupancy and a reservation, allowing A to remain the actual occupant while B holds a reservation. Writing the applicant directly into occupant would overwrite the original driver before departure. Conversely, using only the occupied flag to decide whether a request is allowed cannot express a handover that waits for the existing occupant to leave.

PedOccupancy stores an established relationship; the reservation structure stores the requested destination. Its existence check combines inVehicle, the vehicle handle, and the seat index. The current HasVehicleOccupancy requires all three: the in-vehicle flag is true, the vehicle handle is nonempty, and the seat index is nonnegative. One true Boolean is insufficient to establish a structurally present occupancy record.

This check does not yet verify that the vehicle seat points back to the Ped. It answers whether the character side has a structurally present record; later checks establish reciprocal consistency. If all Ped fields are present but the vehicle seat is empty, direct entry still returns “already in vehicle.” The final repair case demonstrates that stale record.

The current handle type stores an integer, and IsValid accepts any nonzero value. It does not query the world registry or visibly validate an entity generation. A structurally valid handle does not prove that the entity still exists. Showcase callers resolve Ped and Vehicle objects through runtime queries before invoking relationship interfaces. Object resolution and lifetime safety cannot rely solely on nonzero IDs in seat records.

Three serials track three different changes

The implementation has separate reservation-request, Ped-occupancy, and command-ownership serials. They track request identity, character relationship changes, and command-owner changes respectively.

Setting the same vehicle, seat, and driver flag returns success without advancing the occupancy serial. Moving to another seat or changing the driver flag advances it. Clearing existing occupancy preserves the incremented serial rather than resetting it to zero.

For example, B might have occupancy serial 8 in seat 1, advance to 9 after moving to seat 2, and reach 10 after exiting. Clearing an already absent record returns no modification and leaves the serial at 10. These are teaching values, not video-log IDs. Interface-call counts and state-change counts are separate measurements.

Command ownership follows a similar rule. Repeated submissions by the same Ped in the same driver seat with the same task identity can change throttle while leaving the ownership serial unchanged. A new task session, or cleanup after the owner leaves, changes ownership state. Logs can therefore distinguish continuous control from a new handover.

Why relationship results contain more than a Boolean

Relationship interfaces return a status, before/after values, and modification flags. Entry, exit, and seat-change results include Ped and Vehicle handles, the target seat, previous occupant, occupancy serials before and after the call, and whether vehicle occupancy, Ped occupancy, or driving commands changed.

Each result identifies the outcome and changed fields so the caller can decide whether to continue. Specific failure reasons distinguish an occupied target from a Ped that already has another occupancy relationship. A single false result would force the caller to rescan state, potentially at a different stage of the operation.

Modification flags still need to be read against the implementation. Some interfaces fill their complete summary only at the end of a successful path; helpers may already have changed reservations or commands earlier. A failure does not guarantee that every byte remains unchanged, and success does not require every modification flag to be true. The entry section follows the actual write order.

How the relationship interfaces are layered

The code separates local vehicle writes, Ped–Vehicle relationship operations, policy checks, and scene orchestration. These layers cooperate but have different preconditions and side effects.

The low-level vehicle seat setter can expand its array when an index exceeds its current size. The relationship manager first checks index validity, so ordinary entry does not use that expansion to create new seats. The former is a local data operation; the latter is an entry point with admission checks.

Clearing a vehicle seat directly resets its occupant and occupied flag. It does not automatically clear the Ped record or remove the seat’s driver designation. Relationship-level exit clears both sides and checks old command ownership. Calling only one low-level method can create the one-sided residue shown in the final video.

Why the policy layer checks its scope first

Reservation policy receives an operation and permissions to reserve, confirm, release, or release a conflicting reservation. It also checks whether the decision requires entity-lifetime handling, world scanning, physical movement, task-lifetime handling, or resolver involvement. When the caller indicates that these external capabilities are required, this layer returns the corresponding blocked status rather than performing them inside the reservation function.

The policy operates on the supplied Ped, Vehicle, and seat records, producing an operation decision and a next reservation record. The task layer can arrange waiting, cancellation, or another entry point from that result. Policy evaluation does not move a character to a door, load an entry animation, or create or delete vehicles.

The relationship manager maps these detailed decisions into a smaller public status set. Reserved, confirmation passed, released, missing reservation, conflict, and identity mismatch retain distinct names. Unmapped lower-level rejection reasons become a general rejection. Internal diagnostics can therefore be more precise than the public enum; a complex failure needs its lower-level result, because Rejected alone does not identify one unique cause.

Inspection is separate from repair

Ordinary reciprocal checks can find a wrong vehicle reference, an empty seat, or a different occupant without deleting anything. Repair receives a separate action that selects Ped-side or Vehicle-side cleanup and whether invalid command ownership may be handled.

Inspection preserves the fault; an explicit action then changes state. If B points to V2 while a caller is handling V1, clearing B merely because the records do not match could destroy a valid relationship with V2. The check first reports a target/source mismatch, allowing a caller with enough context to choose the next action. The current repair branches limit their writes on that basis.

Reservations and actual entry are separate commits

In the first case, A continues driving while B requests a passenger seat. The system registers a reservation, then handles cancellation, retry, and actual entry. Another character competing for the same seat encounters a reservation conflict.

Video 1: Passenger reservation, competition, cancellation, retry, and seat change; 16 seconds. The case uses archived input playback and simplified character pose transitions.

A reservation contains two groups: the target relationship (Ped, Vehicle, seat) and the request identity (requester, task tag, request serial). The first identifies the intended allocation; the second identifies which request may continue operating on it. Writing a reservation on the vehicle seat does not make the applicant an occupant.

A driver-seat reservation can coexist with another occupant. It records takeover intent without evicting the original driver. Departure is committed separately, and the successor still has to pass occupancy checks before entry.

Confirmation checks the target and request identity. On success, it creates no persistent confirmed state and does not change the occupant. The diagram therefore has no durable “confirmed and authorized to drive” state. Confirmation and entry are sequential calls made by the caller. The current showcase executes them under prepared successful conditions and checks their results afterward; it does not implement a general task flow that stops immediately after every failed step.

Actual entry first validates the Ped, Vehicle, and seat, then checks for existing Ped occupancy and a current target-seat occupant. On success it updates the vehicle seat, establishes the corresponding Ped record, and derives the driver flag from the Vehicle’s actual driver-seat relationship. The successful case also clears the target reservation. That clearing occurs during vehicle-side assignment, before all Ped-side writes have succeeded; its failure implications are examined below.

The underlying entry interface does not universally require a confirmed reservation. The showcase’s upper-level handover confirms first and then calls entry. Its video sequence does not establish that every direct-entry path enforces the same reservation protocol.

If the Ped-side write fails, the entry implementation clears the occupancy it just assigned to the target seat. This is local cleanup, not a complete transaction rollback. It does not establish that serials, old commands, and every other side effect return to their original values. A full rollback contract would need a separate definition.

Seat change checks the old seat, the Ped’s current vehicle, and the destination. In Video 1, B moves from the front to the rear: the old seat becomes empty, the new seat points to B, and B’s seat index changes accordingly. This validates that successful move, not every failure branch or complete in-car animation.

Reservation policy follows a specific order

The reservation manager first copies Ped, Vehicle, seat, and request identity into the result, validates handles and index, and reads the current reservation. The policy input retains that record, and its default output is the same record. The manager writes a new value only when a permitted mutation branch explicitly constructs it.

This default-preserve arrangement allows missing-reservation, conflict, and identity-mismatch paths to return without accidentally clearing a newer record. It applies to the reservation record; it is not a general transaction guarantee for every relationship operation.

The key comparisons separate target and request identity:

sameTarget = reserved
             && stored.ped == ped
             && stored.vehicle == vehicle
             && stored.seat == requestedSeat

sameRequest = stored.requestedBy == requestedBy
              && stored.taskTag == taskTag
              && stored.requestSerial == requestSerial

The reserve branch checks sameTarget first. An existing reservation for the same Ped, Vehicle, and seat returns “already reserved.” Otherwise, an existing different-target reservation is a conflict. A new record is created only when no conflict exists and reservation is allowed. A different request serial does not automatically replace an old reservation.

Confirmation requires an existing same-target reservation, matching sameRequest, and permission to confirm. It then returns success. Although the status is named “confirmed,” the output remains the original reservation and the modified flag is false. Both the result enum and the write flag matter; an enum name cannot introduce a state bit absent from the structure.

Release first checks whether a reservation exists. Ordinary release rejects a different target; a same-target record also requires matching request identity. A permitted release resets the record. The lack of a new driver does not remove the identity requirement: the protected resource is the unfinished request.

Ped–Vehicle consistency checks run before these branches to detect existing one-sided residue. They do not require the applicant to occupy the requested seat already. A Ped outside the vehicle and a driver seat legitimately occupied by A can both be compatible with the request. The check prevents progress from contradictory relationships without requiring actual occupancy at the reservation stage.

What happens to a reservation when a seat is assigned?

The low-level seat-assignment helper clears an existing target-seat reservation. Its clearing function checks index, handle, and reservation existence, but does not compare every requester-identity field again. Callers must therefore perform any required reservation admission checks before occupancy writes begin.

The showcase places confirmation before entry to check identity, but aggregates results only after all three calls. That arrangement cannot guarantee that a failed confirmation prevents a subsequent entry call. Direct entry is not a complete reservation-security protocol either. Each interface guarantees its particular checks and writes; task-ownership rules must be applied at the appropriate reservation entry point. Bypassing those checks does not retain their protection.

Successful passenger entry in Video 1 and driver entry in Video 3 both consume the target reservation. This does not prove that every reservation clearing performs strict request-identity confirmation. Ordinary cancellation, administrative clearing, and clearing during occupancy assignment are separate paths.

Entry rejects before it writes

The current entry code follows this sequence. Neutral method descriptions omit result-field copying while retaining control flow:

Capture Ped, Vehicle, target seat, and Ped occupancy serial
If Ped or Vehicle handle is invalid: return the corresponding error
If target index is invalid: return invalid seat
If Ped already has occupancy: return already in vehicle
If target seat has a valid occupant: return occupied seat

Call the seat-assignment helper
If assignment fails: return the mapped error
Derive isDriver from the Vehicle's actual driver-seat relationship
If the Ped-side write fails: clear the target seat and return relationship mismatch
Update the Ped's associated vehicle; record the new serial and modification flags
Return entry success

Checking Ped occupancy before target availability prevents an empty seat from hiding another existing relationship. Validating the index first also prevents normal entry from depending on low-level array expansion. A preliminary rejection occurs before seat assignment and preserves the existing occupant and Ped record.

isDriver is derived from actual driver-seat occupancy, rather than copied directly from the caller’s Boolean. A caller can request designation of the target as the driver seat, and the helper adjusts this Vehicle’s driver-seat attributes accordingly. That parameter affects authority-related configuration; it is not merely a display option. The interface does not implement seat-configuration authorization for untrusted callers here. Callers must restrict who may request that change. The final Ped flag follows the resulting vehicle state, which subsequent eligibility checks inspect again.

The assignment helper also clears duplicate occupancy by the same Ped in other seats of this Vehicle, checks whether a seat change invalidated the old command owner, and clears the target reservation. Calling the helper therefore performs these related operations as well as Seats[index].occupant = ped.

The vehicle-side write clears this Ped from other local seats before assigning the destination, so a successful move does not leave two copies of B in one Vehicle. This scan does not traverse every vehicle in the world. Ped-side state and caller lifetime constraints must prevent cross-vehicle duplication; a local scan is not global deduplication.

Why seat change has its own entry point

A seated Ped already has occupancy, so calling ordinary entry would return “already in vehicle.” Seat change instead validates the current vehicle and old seat, confirms that the old seat points to the Ped, and then checks whether the destination is empty or already belongs to the same Ped.

If another Ped occupies the destination, this branch rejects the request; it does not start a forced-removal task. Moving to the current seat permits a consistent repeated assignment. Helpers determine whether anything actually changed, so repetition need not increment the occupancy serial.

Successful seat changes use the same assignment helper, including duplicate-occupancy and invalid-command-owner checks. The Ped record moves to the new seat. If the index changed, a reservation belonging to that Ped on the old seat is cleared; the destination reservation is also cleared during assignment.

These cases come from interface-branch analysis. Video 1 supplies runtime evidence for a successful passenger-seat change. Driver-seat changes, rejection paths, and failure rollback require separate experiments.

Write order determines what must be checked after failure

Vehicle-side assignment precedes the Ped-side write. If the latter fails, current entry code clears the target occupancy. Assignment may already have removed a reservation or old command, and clearing the seat does not undo those effects. The seat-change path likewise has no complete reverse restoration of the original seat after a failed Ped-side write.

Upstream parameter checks usually constrain Ped-side write failures, so this defensive branch should not be presented as a common fault observed in the videos. Interface guarantees must still follow the implemented cleanup scope. A failure-cleanup branch is insufficient evidence for strong transactional consistency.

Request identity isolates cancellation from retry

Cancellation often occurs immediately before another request. B can cancel a takeover and request the same driver seat again. If the old task performs delayed cleanup using only the Ped and seat, it can delete the new reservation.

Video 2: A takeover is cancelled and retried, followed by confirmation and release attempts using the old request; 15 seconds. Both stale operations are rejected and the new reservation remains.

The implementation first checks that the reservation belongs to the target Ped, Vehicle, and seat, then checks requester, task tag, and request serial. Confirmation and ordinary release of the same target must match the current request identity, even if both requests originate from the same character.

The following teaching values explain the relationship; they are not original log serials:

This path has two limitations. First, repeating a reservation for the same target returns “already reserved”; it does not upgrade the stored request identity. Normal retry requires the corresponding cleanup first. Second, a low-level option explicitly permits releasing a conflicting reservation; it is disabled by default. This case validates ordinary cancellation and retry, not a rule that all administrative cleanup can release only its own reservation.

The task layer must retain its request identity, supply it during confirmation and cancellation, and handle failure according to the result. A single “entering vehicle” Boolean cannot distinguish consecutive requests or explain which one owns delayed cleanup.

Explicit replacement differs from ordinary retry

The project also has a dedicated entry point to replace an old reservation from the same source. It requires an existing reservation and matching Ped, Vehicle, seat, and requester. An identical tag and serial return “already reserved.” A changed identity from the same source causes the old reservation to be cleared before the reserve entry point runs again.

Replacement occurs only through that dedicated entry point. The ordinary reserve branch does not replace automatically, and an identical destination does not authorize overwriting another requester’s reservation. The replacement method suits callers with explicit task-replacement context. Video 2 validates cancellation followed by a new request, not the complete dedicated-replacement branch.

Because replacement clears first and reserves again afterward, the new request can still fail subsequent checks. Current code does not automatically restore the old record on failure. The caller must read the resulting reservation rather than assume restoration.

Old-task cleanup must carry the old identity

Delayed completion callbacks can run after cancellation and after the next task has started. The old task must use its saved identity, rather than rereading the seat’s current serial and treating that as its own.

Suppose task 41 already saved its context. After request 42 is established, the old task could query the current reservation, obtain 42, and release it with that identity. The check would pass correctly; the caller would be wrong for giving a new identity to an old task. Request identity must be captured at task creation and retained through termination.

The showcase deliberately submits old confirmation and release calls with current serial − 1 after retry. It checks identity-mismatch results and verifies that the seat still retains the current serial and B. A rejection message alone is insufficient; preservation of the new record must also be checked.

Callers use those results to decide whether execution continues; logs only record the decision. Reservation failure should prevent waiting or entry. Confirmation failure should retain diagnostic state while the task chooses retry, cancellation, or termination. A failed stale release means the old task did not acquire cleanup authority over the current reservation. Those choices belong to task policy; one showcase sequence does not define recovery for every task.

What cancellation preserves

In the cancellation case, B’s driver-seat request is released and B is restored to the original passenger seat. A’s driver-seat relationship remains intact. Checks cover the empty reservation, A’s reciprocal driver occupancy, B’s reciprocal passenger occupancy, and rejection of B’s premature command.

The scene clears previous driving commands before the handover starts. A remaining the driver after cancellation does not imply that A’s old throttle command must still exist. Eligibility and command existence are independent: a qualified driver can temporarily have no control command. That is a valid cancellation result.

Driver handover can contain an interval with no eligible driver

Between A leaving and B entering, the system needs an explicit state in which neither the old driver nor the waiting applicant can command the vehicle.

Video 3: A leaves, the driver seat remains temporarily empty, and B enters before the same physical vehicle moves and stops; 16.2 seconds. Motion uses the existing route-constrained longitudinal controller and does not establish completed free driving.

B first reserves the driver seat while A still occupies it. After A leaves, relationship operations clear the seat and Ped record and check whether the old driving-command owner became invalid. The scene then attempts A’s old command and B’s premature command. Both must be rejected.

A no longer occupies the driver seat. B has a reservation but has not occupied it yet. The system therefore retains a no-eligible-driver interval until actual entry and eligibility checks succeed.

The caller subsequently confirms B’s reservation, commits entry, and attempts command acceptance, then checks all three results together. The end-to-end example below examines the failure boundary of this arrangement. Acceptance queries current eligibility: Ped and Vehicle handles, driver-seat designation, actual occupant, and reciprocal Ped vehicle/seat records. Only then does it store B’s command and ownership.

Eligibility is determined from the relationship at acceptance time. Reservations, keyboard events, and door distance describe requests, input, and space respectively; none replaces occupancy checks. The post-exit retry experiment tests the same entry point against this rule.

Clearing a logical command does not stop the physical body immediately. Inertia can remain; measured physics snapshots determine position and velocity. The video shows the authority transition and subsequent motion of the same vehicle, rather than substituting an instant visual stop for braking.

Eligibility narrows through a sequence of checks

The snapshot reads the vehicle’s driver-seat index and checks: valid Ped handle, valid Vehicle handle, an existing seat with the driver designation, actual occupancy, the submitting Ped as occupant, reciprocal consistency, and the Ped’s driver flag. All must hold for Ready.

ready = validPed && validVehicle
        && existsDriverSeat && occupiedDriverSeat
        && occupantIsSubmittingPed
        && reciprocalSeatRelationship
        && pedMarksDriver

The result reports the first failed check, while the snapshot retains the facts collected up to that point. A complete reservation cannot make B pass the occupant check while the seat is empty.

The reciprocal snapshot separately checks the Ped’s current vehicle and seat, the vehicle occupied flag, and the occupant handle. A nonempty handle with occupied=false still fails occupancy. A Ped claiming to be the driver also fails if the Vehicle points to A instead.

Vehicle-side ownership consistency is a narrower check

A Vehicle also exposes a command-ownership consistency snapshot. It checks whether the saved owner is valid, whether the saved seat exists and is designated as the driver seat, and whether that seat’s current occupant remains the owner. It receives no Ped object and therefore does not repeat the full Ped-side validation.

Full eligibility governs new command acceptance. Vehicle-local ownership checks identify invalid saved commands during seat changes or explicit repair. Their input scopes differ. If the Ped record is faulty but the Vehicle still names the same character, the local ownership snapshot may miss part of the inconsistency.

No saved owner is a valid no-owner result. Commands marked as not driver-owned are also outside this driver-invalidity cleanup rule. The showcase commands explicitly carry driver ownership; other ownership types are not indiscriminately cleared.

Driver identity and command source are arbitrated separately

B can remain seated while the Vehicle follows AI routing, temporarily performs a scripted maneuver, and returns to normal cruising. That transition changes the command source without changing occupancy.

Video 4: AI driving, temporary scripted control, and return to AI in a fixed scene; 10.1 seconds. B remains the driver and command owner. The roadblock markers have no collision.

A candidate contains source type, source tag, control command, and priority. A known source and a nonempty tag make it available. Nonzero throttle, brake, or steering is recorded separately, but is not required for availability. Zero-motion input can be valid; acceleration is not the validity test.

Arbitration selects the highest-priority available candidate. The showcase uses AI=10, Script=50, and Player=100. These are project demonstration policies, not universal reference-mechanism constants.

selected = none
for candidate in candidates:
    if candidate.sourceUnknown or candidate.tagMissing:
        continue
    if selected is none or candidate.priority > selected.priority:
        selected = candidate

Equal priority does not replace the current selection, so the first candidate in the input array wins ties. Construction order matters. There is no round-robin, fairness, or timed-preemption policy here. If all candidates are unavailable, arbitration reports no selection; it does not itself clear the old command.

The selected command enters the relationship interface, where current driver eligibility determines acceptance. Only success writes the command and saves Ped, seat, and caller-supplied task-source information. Highest Player priority cannot authorize an unseated character.

Task cleanup checks the owner, task tree, task priority, and permitted session identity. An old task ending must not clear a newer command solely by source type. This resembles reservation-request isolation but uses an independent state record.

Scripted avoidance in the video uses fixed trigger distances and a fixed target. The scene enters the script phase after about 6 meters of travel, places the target about 5 meters ahead with a lateral offset, and withdraws the script candidate after passing the marked region. The script supplies a stage target; the existing physics executor moves the body. These distances belong to the fixture, not a general obstacle-decision algorithm.

The markers have no collision. Validation checks measured body bounds against the predefined obstacle region and road limits. The case covers source handover and constrained scripted avoidance, not general obstacle recognition, arbitrary planning, or collision recovery.

Command content and ownership are written separately

Command content includes throttle, brake, steering, handbrake, reverse intent, source type, and source tag. Ownership stores Ped, seat, driver-owned status, task-source presence, task tree, task priority, session tag, and ownership serial.

struct CommandOwner {
    EntityHandle ped;
    int32 seat = INDEX_NONE;
    bool hasOwner = false;
    bool driverOwned = false;
    bool hasTaskSource = false;
    TaskTree taskTree;
    int32 taskPriority = INDEX_NONE;
    FName sessionTag = NAME_None;
    int32 ownershipSerial = 0;
};

Acceptance first builds a combined candidate-and-eligibility snapshot. Ineligible drivers return eligibility-not-ready first. Eligible drivers with incomplete sources return candidate-not-ready. Both checks must pass before command and ownership writes. The ordinary entry point uses default task-source information; the task-aware entry point explicitly receives task tree, task priority, and session tag.

Candidate priority chooses a command for this arbitration pass. Task priority identifies the submitting task slot. Source type and tag describe the kind and specific origin of the control intent. Candidate priority is not automatically saved as ownership’s task priority; different parameters provide them.

For example, AI priority 10 and Script priority 50 make Script win this candidate set. If Script originates from a task slot, that slot’s own priority and session identity must still reach the task-aware acceptance entry point. Treating 50 as task identity would make cleanup depend on an unrelated arbitration policy.

Identical command values can still represent a handover

Acceptance separately reports content changes and ownership changes. Throttle, brake, and steering use approximate equality; handbrake, reverse intent, source type, and tag use equality. This is a semantic comparison, not a bytewise comparison of the command structure.

Ownership is compared twice. The setter compares Ped, seat, flags, and effective task identity to decide whether to write a new version; an identity change advances the serial. After acceptance, the complete before/after snapshots are compared, including Ped, seat, task tree, task priority, session tag, flags, and serial. The serial records a completed version change and participates in result comparison; it is not an input to the setter’s identity-change decision.

Two submissions can both request zero throttle and full braking while a new task session changes ownership. Conversely, one task can vary throttle without changing the owner.

Logs should distinguish successful acceptance from modification. A repeated submission can succeed because eligibility and source remain valid without creating a new state version. Acceptance counts, content-change counts, and ownership-change counts require their respective fields.

The Vehicle also has a direct command setter. This low-level path clears existing ownership when writing content, preventing a new command from inheriting the previous driver’s identity. Driver acceptance instead validates eligibility, writes content, and explicitly establishes ownership. Mixing the entry points can leave command content present with no owner. Business code must specify which calls may submit without driver ownership.

Task-session tags include a compatibility path

Task-level cleanup checks Ped, driver-owned status, task-source presence, task tree, and task priority. Session tags do not use unconditional equality: a nonempty stored tag must match, but an empty stored tag passes this part of the check.

sessionMayClear = storedSessionTag is empty
                  or storedSessionTag == cleanupSessionTag

Nonempty tags isolate sessions. Empty tags preserve compatibility for commands without recorded session identity. This is not an absolute guarantee that an old session can never clear a new command: no complete session distinction exists when the stored tag is empty. Ped, tree, and priority must still match, but consecutive tasks can share them.

Ordinary task cleanup does not handle commands without registered task provenance. Missing Ped ownership, non-driver ownership, missing task source, or invalid caller task priority returns no cleanup. Other invalid-owner cleanup uses a separate explicit repair path; ordinary task termination does not perform it.

How the task executor submits driving input

The task-slot executor can optionally submit driving input. The caller enables submission, and the branch requires existing Ped occupancy in the target Vehicle. It then attempts permitted invalid-owner repair and invokes task-aware command acceptance.

Repair permission and acceptance remain separate. With cleanup disabled, repair can report residue without changing it; current eligibility must still be checked afterward. Results distinguish attempted, accepted, and rejected submissions, as well as command or ownership changes caused by repair or acceptance.

This branch explains how task slots connect to the relationship layer. The seven videos do not revalidate every selection, cancellation, and lifetime branch of that executor. Most showcase orchestration calls relationship interfaces directly. The two paths are described separately so a short clip is not mistaken for complete task-system coverage.

The UE execution section below follows the accepted Script command through target selection, steering, and route recovery.

Rejected exits preserve relationships; successful exits clear eligibility

The exit request has two outcomes in the fixture. While the vehicle moves, it is rejected and the character remains the driver. After stopping, exit clears reciprocal occupancy and invalidates the old driving-command owner.

Video 5: Exit is rejected during motion and succeeds after braking to a stop; 6.6 seconds. Character motion is showcase presentation, not a jump-out or forced-removal task.

The speed condition reads horizontal velocity from the physics snapshot. This scene rejects exit above 0.15 m/s. The threshold belongs to the showcase caller, not every low-level seat-removal interface. Those interfaces primarily validate the Ped’s current vehicle and seat against the actual occupant.

A rejected exit preserves the relationship. Clearing the driver before discovering excessive speed would leave a seated character unable to command the vehicle. The case checks that driver identity, command ownership, and reciprocal occupancy remain valid after rejection.

Successful exit removes occupancy, clears the Ped record and corresponding reservation, and checks whether the former owner’s driving command became invalid. Presentation then updates character position and orientation. Moving a model outside the car does not perform relationship cleanup.

Video 6: B returns beside the vehicle after exit, triggers driving input, and resubmits an old AI command. Both are rejected; 10 seconds. A script invokes the same keyboard-bound callback; this is not manual keyboard play.

The sixth case checks input acceptance after the driver field has been cleared. B is near the car but has not reentered. The script calls the driving-input entry point and separately retries the old AI command. Current eligibility rejects both, the driver seat and owner remain empty, and the vehicle stays still.

These attempts cover new input and retry from an old source. Neither gains eligibility from proximity. An old AI source can still construct a command without regaining acceptance eligibility. The stationary image must be interpreted with same-run state records; by itself it cannot exclude the possibility that input never fired.

How removal protects the current occupant

The exit interface validates Ped and Vehicle handles and target index, then requires existing Ped occupancy. It checks that the Ped’s current vehicle and seat match the requested target, and that the target seat’s occupant is this Ped.

A cannot clear B’s seat merely by supplying a driver-seat index. If A still points to an old seat while B now occupies it, removal returns a relationship or occupant mismatch and preserves B. A raw seat-clearing helper lacks this Ped-level meaning; normal exit flows should use the relationship interface.

After validation, exit captures old command ownership, then clears the vehicle seat through the relationship manager. The manager compares that saved owner with the post-clear driver-seat facts, removing the command and ownership if the former owner no longer occupies its driver seat. It then clears Ped occupancy, settles the associated-vehicle state, and removes any reservation for this Ped on the seat.

The captured owner identifies whose command must be checked after departure. Clearing ownership first would discard that information.

Associated vehicle is not current occupancy

The Ped also stores an associated vehicle, updated by successful entry or seat change. Exit settlement clears it only when the dedicated reset-associated-vehicle-on-exit flag requires that. Leaving a seat does not unconditionally remove every vehicle reference.

The associated record can retain recent or related vehicle context for other tasks. It cannot grant driving eligibility: that check uses current occupancy and the seat table. “Exit cleanup” here refers to current occupancy and related commands, not unconditional zeroing of every vehicle reference.

The speed threshold uses measured feedback

The caller reads PhysicalVelocityMetresPerSecond.Size2D(), the horizontal speed magnitude. Above 0.15 m/s it rejects exit. It does not infer a stop from zero throttle or receipt of a brake input.

Coasting after throttle release can still exceed the threshold. Once horizontal speed is no greater than the threshold, scene-stage conditions must also permit the removal call. The threshold is one condition, not the sole switch.

After successful removal, the scene computes an exterior position and orientation from the current physical pose and updates the character presentation. It uses a world-direction offset and simplified transition, not a general exit derived from door bones and real entry animations. The case demonstrates post-exit relationships and rejection, rather than complete exit placement for arbitrary vehicle types.

What post-exit input rejection checks

The sixth case constructs a Player command with a valid source tag through the input callback, excluding missing-source fields as the rejection cause. The old AI command also retains valid provenance, but its Ped no longer occupies the driver seat and fails eligibility.

Validation additionally checks absent Ped occupancy, no vehicle driver, no command owner, and a stationary physical body. The logical checks locate the rejection in the correct relationship state; observed stillness shows that residual movement input did not become effective in this case. A screenshot of a character outside the car cannot establish these interface checks alone.

Repairing inconsistent occupancy records

Reciprocal records can become inconsistent on one side: a Ped claims to be seated while the vehicle seat is already empty. The final case injects this diagnostic fault to expose repair separately.

Video 7: A stale Ped occupancy record blocks entry. Explicit cleanup is followed by a separate successful entry call; 11 seconds. A diagnostic script triggers both fault injection and repair.

Entry sees A’s existing record and returns “already in vehicle.” An apparently empty target cannot justify overwriting it: A could legitimately occupy another vehicle or seat. The rejection preserves the issue for explicit relationship inspection.

Repair checks consistency and whether the state belongs to a permitted residue category. If so, it clears the stale Ped record and handles a related driver-owned command when that command actually belongs to the Ped. Not every mismatch deletes every relationship.

The video keeps these steps distinct. A remains outside and the passenger seat stays empty immediately after clearing. A later call to the same entry interface assigns A and updates the Ped record; it does not reuse an old confirmed reservation.

Explicit repair can record the contradiction, changed fields, and resulting state independently. The final entry result alone does not explain those intermediate changes. Automatic recovery would additionally need an owner for detection, trigger timing, repairable categories, and protection against deleting valid relationships. Those decisions are outside this case.

Decide which side can be cleared

The consistency bridges work in two directions. Ped-side inspection starts from the Ped’s claimed vehicle and seat. Vehicle-side inspection starts from a seat occupant and checks whether the supplied Ped acknowledges it. Direction limits cleanup; inconsistency does not imply resetting both sides.

Ped-side inspection first requires occupancy, validates Ped and target Vehicle handles, and requires the recorded vehicle to match the supplied target. A target mismatch stops at source inconsistency, preserving a potentially valid relationship with another Vehicle.

For a matching vehicle, the check examines index range, empty seat, and different occupant. The cleanup whitelist includes the corresponding residue states. The Vehicle-side direction validates vehicle and seat, then requires the occupant to match the supplied Ped. It cannot use one Ped to explain away another Ped’s seat.

The table describes branch analysis, not runtime coverage of every row. Video 7 injects only stale Ped occupancy with an empty vehicle seat. Other branches are supported by implementation reading and require their own execution evidence.

Check order limits which corrupted states are reachable

Ped occupancy existence requires a nonnegative seat index. If raw fields say in-vehicle but the index is negative, the first check reports no structurally present occupancy and returns. It never reaches the later negative-index cleanup branch. A status in a whitelist does not mean every damaged record can reach it through the current preconditions.

An error enum is therefore different from a complete, reachable recovery path. The article explains the current normal and residue branches; it does not claim recovery from arbitrary field corruption. Lower-level repair needs a separate raw-field inspection contract and caller permissions.

Repair returns before/after snapshots

The public repair entry point captures both sides’ current claims. A no-action request returns without mutation and reuses the before snapshot. Ped-side cleanup calls the Ped consistency bridge; Vehicle-side cleanup calls the seat-occupant bridge.

After an actual Ped-record deletion, the manager also performs permitted driving-owner checks and recaptures the relationship. If nothing changed, the old snapshot distinguishes already consistent from unchanged. Unsupported actions are rejected; the caller must select a cleanup direction.

The repaired result need not report consistent seated occupancy. A now being outside with an empty seat can produce a no-Ped-occupancy snapshot. Repair removes the false claim; a subsequent entry operation must establish the new relationship.

Clearing command ownership also requires permission

Owner repair first inspects current ownership. Valid state returns already consistent. Invalid state with cleanup disabled is rejected and preserved. Only invalid state with cleanup permitted reaches command clearing. Results retain before/after snapshots and whether a command was actually deleted.

Failed command acceptance has different semantics: the new candidate lacked acceptance eligibility; the old command is not necessarily gone. A caller that needs old invalid state removed must explicitly invoke repair or relationship cleanup.

Ped-residue cleanup also checks whether that Ped held the old command as a driver and clears it when appropriate. The outer manager then checks Vehicle-local ownership. These two checks do not indiscriminately remove every command source. State neither owned by the stale Ped nor deemed invalid by vehicle-side rules is not cleared merely because a passenger relationship was repaired.

Connecting UE update phases to physical execution

Most interfaces above modify logical state rather than integrating body position. The showcase reads published physics snapshots in PostPhysics and uses measured speed, distance, and stage conditions to choose subsequent actions. Submitted commands affect later physics updates.

Snapshot interpretation depends on the update phase. The command may have switched to Script while the current snapshot still reflects an earlier physics update. A body may keep decelerating after command clearing. Handover checks must inspect both logical commits and subsequent motion rather than demand instantaneous completion in one screenshot.

Seat relationships are connected to the existing vehicle executor, but entry, seat changes, and exit still use simplified pose transitions. Complete door actions, entry-task waiting, paired forced-removal tasks, network import/synchronization, and free player steering need separate integration and validation.

When a scripted target reaches the executor

The bridge for this case is constructed in the PIE validation fixture. It is not a general system already connected to arbitrary story tasks. It supplies an optional scripted target only when current driver eligibility is Ready, the accepted source is Script, and its tag matches this scene. Other Script tags do not receive the fixed target automatically.

The steering task validates initialization, frame number, time step, target and maximum speed, and steering limits. With a scripted target, it additionally requires the corresponding full-road-physics branch and coordinates without NaN. The target then replaces this update’s default route target. Without it, the task uses its avoidance-direction or route-lookahead branch.

Only the execution input is replaced. Steering, speed control, road constraints, body integration, and physics readback remain in the existing chain. Withdrawing the Script candidate removes the optional target; AI wins again and default lookahead resumes on the same route.

Video 4 checks more than the source returning to AI. After about 27 meters of accumulated travel, the scene requires proximity to the original lane, lateral error below 0.2 meters, heading error below 3°, and measured horizontal speed above 2 m/s, followed by an additional interval of normal travel. Separate source and motion checks prevent an accepted but ineffective AI command from being counted as a completed return.

These are fixture criteria, not universal tolerances. The scene fixes audited road inputs and disables random route appending for this case while retaining road-coverage checks. That separates handover from route-extension behavior without expanding drivable road coverage.

Following a showcase call into a later physics update

Within one update, four kinds of data appear: the published physics snapshot, scene stage, candidates and ownership, and the subsequent execution target. Reading them in one Tick does not give them the same physical timestamp.

The showcase Actor ticks in PostPhysics and first reads measured position and velocity. When stage conditions are met, it constructs candidates, arbitrates, and attempts acceptance through driver eligibility. Later, while preparing vehicle-control input, the bridge reads the accepted source and provides a script target where applicable. New motion enters a later snapshot after physical execution. This order describes causality between update phases without assigning a fixed rendering-frame or network-frame number.

Stage decisions read measured state, accepted intent affects subsequent execution, and presentation reads the resulting motion. Claims about the same vehicle moving must associate the logical handle with the continuing physical body, rather than respawn an identical-looking model at handover.

Keep units explicit at the bridge

Seat indices and request/ownership serials are discrete identity data without physical units. Body positions and execution targets use UE world centimeters. Snapshot velocity uses meters per second. Heading checks explicitly convert between degrees and radians.

The scene’s 600-centimeter trigger is about 6 meters, its 1750-centimeter release distance is about 17.5 meters, and the 20-centimeter lane-return tolerance is 0.2 meters. Position differences cannot be compared directly with velocity fields, and shared “distance” names do not remove conversion requirements.

Throttle, brake, and steering are control inputs, not meters, meters per second, or final angles. Switching source does not change their units. The executor produces motion from control and vehicle state. This fixed-route demonstration explains relationship/control integration; it is not a basis for inferring complete vehicle-dynamics parameters.

Checking the actual avoidance path

The scene does not merely check whether the center passed the cones. It retains previous body position and orientation, reads current motion, constructs both body poses from vehicle bounds, and checks the swept region against a predefined roadblock rectangle.

This catches a path where the center clears the marker but a tail or turning sweep overlaps it. The rectangle is a conservative diagnostic region. The cones themselves have no collision, so the measurement establishes geometry between the executed trajectory and that region, not contact events from collision components.

The scene also reads executor road checks and requires the physical body to remain inside audited road coverage. A script target overrides lookahead without bypassing road protection. Lateral passage, road constraints, and post-return recovery must all pass for this fixed case to succeed.

Presentation must not write relationship state

Walking to a door, changing seated poses, and turning after exit use simplified presentation and scene orchestration. Models can be hidden for camera clarity while their logical Peds remain. Visibility does not create/delete entities or change the driver.

Video 7’s ground-position and pose correction is also presentation. It adjusts visual placement; relationship repair handles occupancy. Better visuals do not remove a stale in-vehicle claim, which would continue blocking entry. Same-run relationship logs remain necessary.

With complete animations, an animation-completion event could trigger an entry commit, but should still call the checked relationship interface rather than write the seat array directly. Resource waiting, waiting for the old occupant, entry execution, occupancy commitment, and cancellation cleanup need their own stages and identities. The showcase simplifies presentation while retaining these interface boundaries for integration.

Reference mechanism, UE implementation, and validated result

The reference mechanism informs responsibilities and timing: vehicle-owned seats, separate request and occupancy state, vehicle-side driving intelligence, and staged entry/exit coordination. It does not establish numerical equivalence for every UE branch.

The UE implementation organizes those responsibilities through structures, handles, static relationship interfaces, and explicit result snapshots. Showcase Actors orchestrate cases, the control chain consumes accepted commands, and the physics executor publishes body poses. These are target-engine choices, not the reference system’s original class diagram.

The videos and logs establish behavior for the specified map, characters, vehicle, and orchestration. They do not validate complete animation, door-resource competition, paired forced removal, network import, or multiplayer synchronization. Future integration needs evidence for each added runtime case.

Following one handover through state, results, and next actions

The following teaching timeline combines mechanisms from the independent cases; it does not present seven recordings as one continuous run. A and B are characters, V is the vehicle, the driver seat is 0, and request serials 41/42 are teaching values.

Capture the applicant and driver together

Driver=B alone cannot explain a handover. A useful snapshot includes occupancy, reservation identity, B’s record, command owner, and source. They can occupy different stages simultaneously.

The table separates reservation release from B’s passenger reentry inside the cancellation callback. Retry also requires a passenger exit before the new reservation. Each occupancy change has an explicit operation; cancellation or retry labels do not create it automatically.

Two empty states are legitimate. Between A leaving and B entering, there may be no eligible driver. After B enters but before submission, there may be a driver without a command owner. Whether absence is an error depends on the stage; the system should not automatically reinstate A.

A can also remain a valid driver while B holds a reservation. Failure or cancellation handles resources belonging to that request without implying that the current driver should be cleared. Separate reservation and occupancy records support this state directly.

How the current showcase checks its successful sequence

At a controlled handover stage, the showcase uses the following order. Neutral names omit logging fields while retaining the relationship between calls:

confirmResult = confirm current reservation
seatResult = commit B's entry
commandResult = attempt to accept B's driving command

Check that confirmResult, seatResult, and commandResult all succeeded
Check that the target reservation was cleared
Advance the showcase stage only after all checks pass

The showcase executes all three calls before validating their combined results. This checks prepared successful conditions, but later calls may already mutate state after an earlier failure. Failed scene validation stops advancement; it cannot undo committed entry or command writes.

As a derived counterexample, consider an empty driver seat and a Ped outside. Confirmation might reject a mismatched request identity while direct entry still passes its Ped/empty-seat checks. Vehicle assignment can then clear the current reservation. After successful Ped occupancy, command acceptance can also pass. Aggregate validation fails, but state has already changed. This follows from current interface conditions; it is not an injected failure claimed as validated by the videos.

The material therefore establishes the prepared successful handover and a separate stale-request rejection case. It cannot combine them into a guarantee that every stale-confirmation failure prevents takeover. That requires injecting confirmation failure into the complete call sequence and observing subsequent calls and their effects.

Where an integrated task should stop

An integrated task can inspect and retain each result before continuing. The following is integration advice, not a state machine claimed to exist in the current showcase:

Confirmation fails: stop this takeover; handle the reservation with this task's identity
Confirmation succeeds: attempt actual entry
Entry fails: inspect mutations and current relationships; cancel or use an explicit recovery path
Entry succeeds: construct and attempt a driving-command submission
Command rejected: retain the seated fact; handle source or eligibility issues
Command accepted: wait for execution feedback before claiming physical motion

Cleanup depends on the failed stage. A task that never acquired occupancy must not remove another character through ordinary exit. Successful entry followed by rejected control is still a seated character. Automatic withdrawal would require an explicit removal call and its own result handling.

Local failure also requires checking write scope. Assignment may already have cleared reservations or commands, and seat change lacks complete reverse restoration. A failure enum alone cannot establish that the original state remains intact. Callers should retain before snapshots, inspect modification flags, and recapture relationships where needed before choosing permitted recovery.

Locate faults along the data flow

Check logical rejection, command commitment, and physical results in sequence. Locating the failing entry point before interpreting same-run logs reduces guesses based only on images.

What the seven videos establish

All final videos are 1920×1080 at 10 fps, totaling 84.9 seconds. The frame rate describes capture/encoding, not measured UE runtime performance. The first three use archived input playback; the last four are scripted showcase sequences. Each retains its associated state and logs.

Video makes continuous behavior visible. Exact rejection reasons, handle identity, and record changes require same-run logs. Asset hashes and decoding checks establish file identity and playability, not runtime mechanism correctness. Preparing this article did not rerun the entire UE regression suite, and earlier build test totals are not presented as acceptance results for this version.

The implementation keeps reservation, actual occupancy, driver eligibility, and command source separately queryable throughout cancellation, handover, exit, and repair. The previous article’s traffic policies determine where a vehicle should go; this layer determines who may currently submit the driving intent for execution.

Notes on AI-assisted development

The initial handoff followed the seven videos, which made assets easy to find but left state and interface behavior underexplained. This revision organizes the text around state, relationship operations, and UE execution while preserving video order. Twelve mechanism and implementation diagrams explain fields, checks, and writes. Three revision passes checked interface guarantees, reordered code explanations, and added the complete teaching timeline.

AI assisted implementation reading across reservations, occupancy, driver eligibility, arbitration, task-source cleanup, explicit repair, and the fixture’s physics bridge. That reading corrected two overstatements: confirmation creates no persistent state, and direct entry does not universally require a confirmed reservation. Arbitration and driver eligibility also occur at separate entry points. The article describes those actual boundaries rather than extending showcase call order into universal interface guarantees. Further reading identified empty-session compatibility cleanup, direct command setters clearing ownership, and damaged fields being blocked by preliminary existence checks; each is explained beside its relevant operation.

Handoff records and code jointly constrain input provenance, the exit-speed threshold, noncolliding markers, and explicit repair. Complete character tasks and player driving need additional runtime evidence. The timing of aggregate confirmation/entry/acceptance checks follows the showcase source; per-step stopping remains integration advice rather than completed work.