Open-World Player Vehicle Driving P4: How AI Releases and Regains Control of a Vehicle — Control-Source Handoff, Temporary Tasks, and State Recovery

P1 discusses how the player obtains a driving control window through seating relationships; P2 discusses how input enters the vehicle; P3 discusses how multiple inputs, goals and constraints form a consumable driving command. This article continues to ask: When the vehicle is already run by an AI task and the player requests to enter, take over, leave, or a script or temporary action is inserted, how to release the original control source? How can the vehicle continue to maintain task, route and status continuity after the handoff is completed?

Previous article: Open world player vehicle driving P3: How driving commands are formed – from input snapshot to vehicle executable contract

1. Taking over is not deleting AI

Introduction: Takeover is not about removing AI from the vehicle

The player approaches a vehicle driven by an AI and presses the enter button. What the player sees is opening the door, taking a seat, camera switching, and the vehicle starting to respond to input; when the vehicle is running, it faces a control source handoff: whether the original task is still valid, whether the seat allows changing the driver, whether the current task can be replaced, whether the player’s driving task can be installed, whether the network status allows local submission, and whether the original AI can be restored when the handoff fails.

If you simplify this matter to:

AI = false
Player = true

Then the system will immediately lose a set of information: what task the AI was originally performing, whether the route target still exists, whether the vehicle is waiting for the intersection, whether the temporary action has not been completed, who should resume after the player leaves the vehicle, and whether the current entity still has local control.

The core judgment of P4 is:

Player takeover changes the current command submission relationship, not the vehicle intelligence, task tree and entity identity itself. This is also the difference between P4 and P1 and P3. P1 solves “whether the player can obtain the driving window”, P3 solves “how the command is formed”, and P4 solves “how the source of the command is handed over safely”.

2. Control source handoff model

1. What is still missing after P3?

P3 has organized inputs, task goals, local constraints and execution cycles into driving commands. But even if an order has been formed, it cannot directly answer the following questions:

• Whether the current command comes from AI, player, script or temporary action;
• Whether the original control source still has the submission qualification;
• Whether the new control source has completed seat, entity and network checks;
• Should the old task update parameters, be replaced, suspended, or terminated;
• After the temporary action ends, whether the original route and original task will continue;
• After the player exits, should the vehicle resume AI, enter a driverless state, or wait for a new control source;
• Whether cached tasks can be reinstalled when an entity is changed from a remote clone to a local entity.

Therefore, the transfer of control is not a transient assignment, but a runtime process consisting of request, admission, replacement, submission and recovery.

2. AI driving is not a switch, but a set of ongoing relationships.

In large open worlds, AI driving usually maintains multiple layers simultaneously: vehicle entities, vehicle-side intelligence runtimes, task trees, routes and goals, local avoidance states, seating relationships, and control sources. “AI driving” here refers to the fact that these relationships are jointly valid in the current period, rather than the individual value of a certain field.

A vehicle side link can be abstracted from the source code structure and calling relationship:

Replacement does not mean directly releasing all old state. Whether the old task can be restored depends on whether it saves enough target, route, arrival rules and control source information.

4.3 Task terminates and enters driverless state

A vehicle can enter an explicit driverless state when the driver leaves the vehicle, or when the player’s driving relationship lapses without a suitable AI recovery source. This status does not clear all tasks, but declares that no valid driver currently submits a driving command.

Driverless status can still be maintained:

• Vehicle identity and damage;
• Current seat relationship;
• Reasons for task completion or failure;
• Recoverable route targets in the future;
• Entity state required for vision or network migration.

4. How to take over the new control source

5. How does the player enter the vehicle side during the driving task?

Player driving is not directly written into the vehicle, but enters the vehicle-side intelligent runtime through player-side driving tasks and vehicle bridges. As can be observed in the source code material, there is a set of access conditions for player driving installations: the character must be a player, the character must be in the driver’s seat, the vehicle must have a valid driving layout, the entity cannot be in a clone state that does not allow local control, and the vehicle must have an acceptable entrance to the driving task.

These conditions are used to avoid a dangerous situation where the input layer has accepted player actions, but the vehicle-side task tree is still maintained by another machine, another task, or another driver.

After the player’s driving task is installed, the update strategy of the vehicle’s intelligent operation may also be changed. For example, player local driving often needs to avoid being skipped directly by normal AI time slices; but this does not mean that the vehicle-side intelligence runtime stops working. It still needs to handle task status, events, seats, networks and feedback, but the current source of local driving commands has changed.

6. Three coexistence methods for player takeover and AI tasks

Player driving doesn’t always exclude the AI entirely. There are at least three ways of coexistence.

6.1 Player replaces local command source

Task objectives and routes remain, the player only takes over the direction, acceleration or braking intentions of the current cycle. This approach is especially important in escort, follow or chase scenarios: the task still has a target relationship and the player has local control rights.

Task goal: continue to exist
Route constraints: continue to exist
Traffic constraints: continue to exist
Partial Driving Intent: Player Command Submission

6.2 Script temporarily overwrites player

Plot or scene controls may temporarily turn off player local command submission, but do not delete the player’s seating relationship with the vehicle. After script control ends, the system needs to restore the original control window instead of simply resetting a Boolean value to true.

When restoring, at least confirm:

• The player is still in the driver’s seat;
• The vehicle entity is still the same instance;
• The script does not change the vehicle task objectives;
• Current network authority still allows local driving;
• Old input snapshots are no longer mistaken for new commands.

6.3 Inserting temporary actions into the main task tree

Honking, braking, avoidance, collision recovery or special actions usually only affect a short window of time. They can enter the main task tree as temporary tasks and release their local relationships after completion, allowing the original tasks to continue consuming.

Temporary actions cannot permanently erase the original task tree, otherwise an action of a few hundred milliseconds may cause the route, goals and driving style to be completely lost.

7. Why do temporary actions need independent priority relationships?

The difference between temporary actions and ordinary tasks is not only the duration, but also that they change the scope of the current control submission.

7.1 Temporary actions may only cover one control channel

For example, traffic constraints require brief braking, but do not require taking over direction; obstacle avoidance requires partial steering, but do not require changing task objectives; scripts require the vehicle to stop at a certain location, but still allow the player to adjust the lateral direction.

Such actions should log channel-level coverage:

Throttle: limited by traffic constraints
Steering: still submitted by players
Brake: Forced by temporary action
Target: still maintained by the task

7.2 Forced actions may enter independent priority branches

Collision, rollover, emergency parking and other states cannot be immediately covered by ordinary cruise tasks. They require a clear priority relationship and produce interpretable results upon completion: action completed, action failed, vehicle unrecoverable, or return to the original task.

7.3 Clone entities cannot forge local temporary actionsWhen a vehicle is a remote clone entity, local players cannot directly write temporary actions into its task tree. Otherwise, the local system will see a braking, steering or impact result that only exists on the current machine, and is subsequently overwritten by the network state, forming a ghost control.

This is also the joint between P4 and P12: P4 discusses whether the control source can enter the current entity, and P12 discusses how the task relationship is rebuilt after the entity is migrated.

5. Recovery after the player leaves the car

8. Player leaves the vehicle: who will take over after release

The player leaving the car cannot be simplified to:

Driver = null

A more accurate process is:

8.1 AI recovery requires saving old tasks, not re-guessing

If the AI only knows “this car needs to go” when it takes over again, it can’t restore the original route, goals, speed strategy, and task phases. The recovery source needs to read the rebuildable state from the task snapshot before the handoff.

8.2 Recovery does not mean immediate recovery of all control channels

After the player releases driving rights, the vehicle may still be in transition for camera switching, seat animation, collision recovery, or network submission. The AI can restore the target and route first, and then wait for the actuator to allow local control; this can avoid the vehicle suddenly jumping due to old status or unfinished actions as soon as the character leaves the vehicle.

8.3 Explicitly enter the safe state when there is no recovery source

If the task has ended, the route has expired, the AI does not allow recovery, or the vehicle cannot continue running locally, the system should enter one of the driverless, parked, distant, or waiting states. The safety state must be observable and cannot be expressed as “the vehicle is still running but there is no source”.

6. Failure and rollback

9. Multiple rollback paths corresponding to takeover failure

A robust handoff process must cover failed paths.

Stage	Potential failure	Relationships that should be preserved or restored

|Target confirmation|The vehicle is invalid or has been moved|Cancel the request without changing the original task|

|Seat reservation|The player leaves or the seat is occupied|Release the reservation and keep the original driver|

|Enter action|Vehicle movement or animation is interrupted|Roll back the occupation relationship and restore the original task|

|Driving task installation|Vehicle does not accept player tasks|Reserve seat results, reject command submission|

|Old AI released|Task is not replaceable|Refuse to take over, avoid double submission|

|The player leaves the car|The recovery source fails|Enter without a driver or wait safely|

|Network Migration|Authority check failed|Preserve current authority, do not accept local writes|

The key to the failure path is that the relationship changes that have occurred must correspond to undo, release, or downgrade results.

10. Control source handoff in network migration

This section only discusses how the network status affects the admission conditions for control source handoff; the entity migration, replication and complete recovery process will be launched on P12. P4 does not expand the full network protocol, but control source handoff cannot bypass network authority. When a vehicle changes from a local entity to a clone entity, or returns from a clone entity to a local entity, it needs to be re-judged:

• Whether the current driver has been synchronized;
• Whether the seat occupancy is consistent;
• Whether the current task allows migration;
• Whether temporary actions can be copied;
• Whether the local player is still the driver;
• Whether cache tasks can be installed into new vehicle side runtimes.

Therefore, P4 only retains a handoff layer conclusion: the network state may temporarily prohibit local submission, or may require re-validation of entity, seat and task relationships before recovery. As for task caching, entity replication and cloning-local reconstruction, leave the discussion to P12.

7. From the perspective of source code responsibilities, why handoff requires boundaries

11. Three architectural conclusions obtained from source code reading

The following conclusions are architectural abstractions based on source code structure, calling relationships and responsibility distribution, and do not represent the only form of public implementation; class names and function names use neutral responsibility aliases in this article.

11.1 The vehicle-side intelligent runtime is a continuous consumption environment

The vehicle-side intelligence runtime is more than just a container for the current driving task. According to the distribution of responsibilities, it can be abstracted into providing task access, environment query, route status, event processing and recovery entrance.

11.2 Player driving is a source of vehicle tasks

Player driving tasks enter the vehicle side task tree through character side packaging and vehicle bridges. It changes the current command source but does not replace the vehicle entity’s ongoing operating environment.

11.3 Taking over arbitration requires observing seats, tasks, entities and authorities simultaneously

Checking “whether the player is in the driver’s seat” alone does not prove a successful takeover. Effective takeover also requires simultaneous fulfillment of seating relationships, driving task installation, command window submission, entity authority, and execution feedback.

8. Why the handoff process must leave traces

12. A verifiable control handoff record

In order for “vehicle not to be restored as expected” to be located, at least the following records should be kept during the handoff process:

HandoffRequest
├─ PreviousSource
├─ RequestedSource
├─ SeatIndex
├─ VehicleIdentity
├─ PreviousTask
├─ RequestedTask
├─ ControlWindow
├─ LocalOrCloneState
├─ PriorityDecision
├─ReleaseResult
├─ InstallResult
└─ RecoveryResult

This does not require that all fields be exposed to the player, but that the runtime can answer: who initiated the handoff, whether the old source was released, whether the new source was installed, which layer the failure occurred at, and which state the vehicle ended up in.

13. Boundary between P4 and adjacent articles

P1 is responsible for seat relationship and driving window establishment; P2 is responsible for input status, control view and consumer routing; P3 is responsible for driving command contract, candidate merger and validity period; P4 is responsible for control source release, task replacement, temporary action insertion, player leaving the car and AI recovery.

The following content is reserved for subsequent articles:

• P5: How player goals enter the GPS and route life cycle;
• P6: Driving personality, risk parameters and strategy modulation;- P7: Local avoidance and immediate risk response;
• P8: How to enter different vehicle executors with commands;
• P9: Collision, damage and loss of control recovery;
• P10: driving, aiming and in-vehicle combat;
• P11: Chase, escape and dynamic control;
• P12: Network, replay, LOD and multi-vehicle continuation.

14. From the source code entry: the handoff determines the installation location in the task tree

The issue of takeover cannot be viewed only from the character side. The role-side task can make a driving request, and the vehicle-side bridge and task installation entrance determine how the request enters the vehicle runtime.

14.1 Role-side tasks are responsible for making relationship requests

Character-side driving packaging logic typically captures the relationship between characters, seats, and target vehicles. It knows whether the character has completed entry, is in the driving branch, needs to exit the vehicle, has changed to a passenger, or needs to hand the vehicle over to another source of control.

But character-side tasks shouldn’t have the entire vehicle task tree. It can propose task parameters, driving intentions and control sources, but cannot directly write the final motion results bypassing the vehicle-side intelligent runtime.

14.2 Vehicle bridge determines installation location

Vehicle bridging needs to distinguish at least three types of requests: ordinary driving tasks, temporary actions, and mandatory actions such as collision or loss of control. Their installation locations, replacement conditions, and recovery rules are different.

If all requests are written into the same “current task” field, the system cannot determine whether to resume cruising, resume driving, or continue chasing after a temporary brake.

14.3 Similar task update and cross-category task replacement

An important optimization can be observed in the source code: when the requested task belongs to the same semantics as the current main task, and the relationship between the vehicle and the driver has not changed, the system may only update the task parameters without creating a new task object.

This requires life cycle judgment rather than object reuse:

• Whether the current task type is compatible;
• Whether the current driver is still valid;
• Whether the current vehicle is still the same entity;
• Whether the task is in the updateable stage;
• Whether the new parameters will change the recovery semantics of the task.

Only when these conditions cannot be met simultaneously does a complete replacement need to be performed. When replacing, you must save the recoverable fields of the old task before submitting the new task.

15. Complete timing sequence when players take over

Breaking down the player takeover into timing, you can see that it is not a Boolean change completed in the same frame.

15.1 Request phase

The player enters the system to request entry. At this point, the player is not the source of driving commands, and there is no reason for the vehicle to stop its current AI task. The request only contains the target vehicle, target seat, request source and request period.

15.2 Relationship confirmation stage

The seat system confirms whether the reservation is successful, the character side tasks confirm whether the entry action can be started, and the vehicle side confirms that the entity can still interact. If any of them fails, the reservation should be canceled and the original control source should be maintained.

15.3 Action execution phase

Actions such as opening the door, moving, taking a seat, and closing the door may span multiple update cycles. The AI ​​may not necessarily immediately release the full driving task during this time, as the vehicle may still need to keep moving, waiting, or parking safely.

15.4 Driver Command Submission Phase

After the seat occupancy relationship is confirmed, the vehicle bridge installs the player’s driving task. At this time, it is necessary to re-confirm the player, seat, vehicle and local authority to avoid the old request at the beginning of the entry action from continuing to take effect in the submission phase.

15.5 Old source release phaseThe old AI releases the current driving command source only if the new driving relationship is eligible for submission. The release action needs to record the completion result; if the old task refuses to be released, the player can maintain the seat relationship, but cannot obtain the current command submission right.

15.6 First valid period

The installation of a player task does not mean that the vehicle has performed player input. It also needs to go through an effective control cycle: the input snapshot is collected, the command candidate passes the check, the vehicle task consumes the command, and the executor returns an acceptance or rejection result.

Therefore, there may be multiple stages between the “start driving” perceived by the player and the “control has taken effect” confirmed at runtime.

16. The complete sequence when the player leaves the car

The process of leaving the car also cannot only focus on the final seat release.

16.1 Close the new source first, then release the seat

If you release the seat first and then close the player command window, a brief state of “no driver but still player command” may occur in the next cycle. The correct sequence is usually to disable new command submissions first, then end the player’s driving task, and finally handle seating and character actions.

16.2 Select recovery source

The vehicle needs to determine whether the original AI task is still valid. Routes may have been completed, objectives may have been destroyed, tasks may have been replaced by scripts. The restore source cannot just save a “formerly AI” label, it also needs to re-validate the old task snapshot.

16.3 Restore source commits

If the AI task can be restored, the vehicle-side intelligent runtime reinstalls or activates it; if only parking is allowed, it is submitted to the waiting or driverless state; if the vehicle is in network migration transition, the restoration request is delayed until the entity authority confirms it.

16.4 First cycle after recovery

Recovery also requires the first valid period. The vehicle cannot assume that the AI ​​has full control immediately just because the task object has been installed. Routes, goals, traffic constraints, and actuator acceptance states still need to be recalculated.

17. Task replacement matrix: who can replace whom

The replacement relationship between different control sources can be expressed in a matrix first, rather than written as a fixed global priority.

Current Relationships	New Requests	Typical Processing	Restore Requirements
AI Cruise	Player Takeover	Install player driving, release AI submission rights	Save cruise target
Player driving	Short-time braking	Partial channel coverage	Restore player channel		Player driving	Script forced driving	Close player submission window	Restore input view and window
Chasing task	Temporary avoidance	Retain the pursuit target and cover the local target	Resume the local execution of the chase
Any task	Collision recovery	Enter safety priority relationship	Record runaway results
Local Entities	Clone Migration	Cache Tasks and Stop Local Tree	Rebuild by Snapshot
Clone entity	Local takeover	Confirm authority before installing tasks	Reject old local input

This matrix is used to determine whether new requests can replace, overwrite or coexist in the current state, rather than presupposing a certain item to permanently occupy the highest priority.

18. Why “restore original task” may also fail

Saving a task does not mean that the task can be restored. The following situations can invalidate a snapshot:

• The target vehicle or target area no longer exists;
• Route nodes are regenerated;
• The control source to which the task belongs has been released;
• Changes in vehicle model or sport mode;
• The identity of the entity has changed after network migration;

• The temporary action has modified the task completion status;
• Script changed task objectives during player takeover.

Therefore the recovery process must include revalidation rather than unconditional deserialization. When recovery fails, the system should return clear results, such as target failure, insufficient authority, inconsistent seating relationships, task non-migrability, or not accepted by the executor.

19. Why is the “old order” in handoff dangerous?

Player takeovers, script overwrites, and network restores can all cause legacy command remnants. Old commands may come from a previous cycle, a previous machine, a released AI task, or a temporary action that has ended.

At least you need to check:

• Whether the source still has a control window;
• Whether the command sequence belongs to the current vehicle instance;
• Whether the generation cycle has expired;
• Whether the task version is still consistent with the current goal;
• Whether the command has been rejected or consumed;
• Whether the new source has been submitted.

If the source and sequence information is not retained, the vehicle may suffer from three types of faults that are difficult to locate: the vehicle continues to accelerate after the player releases the accelerator, the vehicle continues to maintain the old direction after the script ends, and the driving state of the previous machine reappears after the network is restored.

20. Minimum verifiable collection of handoff status

P4 is not required to implement all vehicle tasks, but any implementation should be able to verify the following results:

1. When driving with AI, the vehicle can identify the current AI task and submission source;
2. When a player requests to take over, the original AI will not be deleted before the player is qualified;
3. After the player obtains the driving window, the AI will no longer submit the same control channel;
4. After the temporary action ends, the original task or player task can be restored according to the record;
5. After the player leaves the vehicle, the vehicle enters an explainable recovery or safety state;
6. When switching between clone and local entities, the old input will not directly cross the entity authority boundary;
7. Any failure can indicate at which level it occurred at request, seat, task, authority, installation or recovery.

21. AI Native: AI is suitable for organizing handoff relationships, but not suitable for determining pertasks for others.Materials for P4 are typically spread across multiple portals for seat tasks, vehicle tasks, temporary actions, player driving, network objects, and entity migration. AI can help establish a handoff matrix: which entry generates a request, which object owns the task, which relationship can be replaced, which relationship can only take effect locally, which fields need to be saved, and which failure results must be rolled back.

But AI should not be able to decide on its own whether a source has control. It can compress materials, check call chains, and discover missing release paths; in the end, which relationships are source code evidence and which are just migration plans is still left to human judgment.

22. Why can’t the handoff request directly cover the main task?

In a simple prototype, a new driving request might directly call “Set Current Driving Task”. But in an open world runtime, the main task is not a pointer that can be overridden at will. It may be maintaining a route, waiting for an intersection, performing arrival judgment, or holding a task phase that cannot be interrupted by short-term actions.

If the new request directly overwrites the main task, at least four inconsistencies will occur:

• The character side thinks that the player has taken over, but the vehicle side still thinks that the AI task is valid;
• The route target still exists, but the new driving task does not inherit the target;
• After the temporary action ends, there is no original task to resume;
• The task completion callback is sent to a source that no longer owns the control window.

Therefore, control handoff requires first generating a replacement decision. The replacement decision itself is not a final task, but rather determines whether the current task can be replaced by a new request and what relationships will be retained after replacement.

22.1 Parameter update applies to requests with unchanged semantics

Player changing direction input every cycle should not cause the vehicle to rebuild the entire driving task. When AI tasks update speed, follow targets or local targets, the task life cycle should not be reset to the initial state.Parameter updates require that the semantics of the task remain the same. Changes in target position do not necessarily represent changes in task type, nor do changes in the speed limit necessarily represent changes in driving sources. The system needs to distinguish between “new parameters for the same task” and “replacement requests for another task”.

22.2 Replace and retain applies to control source migration

When the player takes over the AI, the source of control changes, but the vehicle, route, task objectives, and entity identity may still be valid. Instead of copying the AI’s instantaneous throttle value, you should save task relationships that continue to explain the vehicle’s behavior.

22.3 Temporary coverage is suitable for short-term local intervention

Avoidance, sudden braking and plot actions only need to cover part of the channel or short time window. They should not get the same lifecycle as the main task, otherwise it will be impossible to tell who is responsible for recovery after the action is completed.

22.4 Rejection is also a normal handoff result

If the current vehicle is a remote clone, or the current main task is in an uninterruptible phase, new requests can be rejected. Rejections cannot be swallowed as exceptions, but the source, target, reason, and current task status should be retained for the upper layer to decide to retry later, wait instead, or cancel the request.

23. Ownership stratification in control source handoff

“Who takes over the vehicle” in P4 includes at least four different ownerships. They often change simultaneously but cannot be combined into a single field.

23.1 Seat Relationship Ownership

Answer whether the character occupies the driver’s seat and which character can continue the relationship. Seat relationships are maintained by entry, seat change, exit and synchronization processes.

23.2 Task Ownership

Answer which task tree is responsible for explaining the current goals, routes, and stages. Just because the player is in the driver’s seat does not mean that the player owns all task objectives; the task may still be held by an escort, chase, or scripted relationship.

23.3 Command Submit Ownership

• Recoverable snapshots of old tasks;
• Admission results for new tasks;
• Release, installation, rejection and recovery reasons.

If only one CurrentController field is implemented, the system cannot express temporary actions, channel overrides, task retention and network migration. A more reasonable approach is to save the handover decision record and let the vehicle side runtime complete the task tree installation and subsequent consumption.

31. Final acceptance issue of P4

A control source handover system needs to answer at least:

1. Who is submitting the current driving order?
2. Why is the original control source released?
3. Why was the new source of control accepted?
4. Do the old and new tasks have the same semantics?
5. Is this change a parameter update, task replacement, or temporary override?
6. Are overwritten goals and routes still saved?
7. Who will be restored after the temporary action is over?
8. What state does the vehicle enter after the player leaves the vehicle?
9. What is saved when switching between clone and local entity?
10. Which part of the relationship has been rolled back when the handover failed?
11. Has the new source been consumed in the first valid period?
12. If the vehicle is unresponsive, does the failure occur at the entity, seat, task, authority, execution, or physical layer?

32. Handover request and time difference

Players regard “entering the vehicle” and “starting driving” as consecutive actions, but the runtime must recognize that there is a time difference between the two. Entry animation, seat reservation, target confirmation, and driving task installation may be spread over multiple update cycles. This time difference is where the old control source is most likely to be mistakenly released.

If the AI ​​is stopped as soon as the entry request is submitted, the vehicle may lose control before the player is seated; if the AI ​​maintains full control, commands will be written simultaneously with the AI ​​after the player completes seating. A reasonable handover requires recording “request arrival”, “relationship confirmation” and “new source taking effect” respectively.

Each stage should have timeouts, cancellations and rollback paths. In this way, when the entry action is interrupted, the system can return to the original AI control; when the installation of the driving task fails, the seat relationship can also be maintained but the player’s submission is refused, instead of leaving a half-completed state.

33. Seat changing and driving handover are not the same path

Changing the passenger’s seat to the driver’s seat, the driver’s seat to the passenger’s seat, and the player’s movement from the driver’s seat to another seat will all change the character and seating relationship, but they will have different effects on the source of control.

When a passenger enters the driver’s seat, he or she needs to confirm that the target seat is available, whether the original driver allows release, whether the vehicle allows a new driver to submit, and whether the original task needs to be migrated to the new driver. When the driver moves to the passenger seat, the original driving command window should be closed first, and then it is decided whether the AI ​​should be restored or controlled by another character. When the player leaves the vehicle, it will also trigger changes in the camera, input view, character tasks, and world interaction state. The vehicle side cannot directly guess that the player has left because the input device has been released.

34. The difference between task completion, cancellation and controlled release

Task completion means that the goal has been met; task cancellation means that the task no longer needs to be continued; control release means that the current source no longer submits commands. The three may occur simultaneously or separately.

For example, the player takes over an AI vehicle that is heading to the target point: the AI ​​control source is released, but the mission goal is not completed; after the player leaves the vehicle, if the route is still valid, the AI can be restored; if the mission is canceled by the script, the vehicle should enter a new mission state instead of restoring the old AI.

The end of the temporary action does not necessarily mean the completion of the temporary task. Some actions need to enter failure recovery after being canceled, some actions need to be resubmitted after being rejected by the executor, and some actions are only released naturally at the end of the time window. Therefore, handover records need to distinguish at least: task completion, task cancellation, source release, handover rejection, waiting for recovery and executor unavailability.

35. Why can’t the vehicle identity be changed in temporary tasks?

Temporary collisions, sudden braking, avoidance, or scripted actions may affect vehicle performance, but they should not change the vehicle’s physical identity. The vehicle still has the same seating relationships, damage status, mission environment and network identity.

If a temporary action creates a new vehicle entity to represent the result, the player will see the vehicle’s position or damage suddenly jump, and the AI ​​task will have no way of knowing whether the original vehicle still exists. The correct approach is to have temporary actions briefly occupy the necessary tasks or control channels within the same vehicle runtime.

Likewise, a player takeover should not create a “player vehicle” that replaces the original AI vehicle. The player enters an existing entity and changes the current control source; after leaving the vehicle, the original entity can still be maintained by AI, tasks, visions or network systems.

36. Relationship between handover and route status

While P5 discusses route lifecycle in detail, P4 only needs to retain one key boundary: route semantics must not be lost on control source handoffs.

Routes can be provided by AI missions, scripts, chases, or escort relationships. When the player takes over, the route does not necessarily continue to drive local direction, but may still provide target, area, or speed constraints. Whether restoring the AI ​​is possible after the player exits the vehicle depends on whether the route objective is still valid.

The route status must at least be distinguished: still valid, waiting for re-routing, overwritten by player local control, replaced by script, and completed or invalid. This will avoid mistaking “the player changes direction” for “the player cancels the entire mission.”

37. The relationship between handover and driving personality

Driving personality belongs to the relationship between tasks and execution strategies. During the player’s takeover, it can temporarily stop generating local control; the recovery after leaving the car will re-select the strategy parameters based on whether the original mission continues, whether the driver is changed, or whether the vehicle enters parking and waiting. Specific risk modeling is left to P6.

38. When multiple sources request takeover at the same time

Player entry, script enforcement, network migration, and security recovery may occur simultaneously in an open world. At this time, the order of request arrival cannot be regarded as the order of permissions.

Each request needs to save the source, target vehicle and seat, request type, validity time, whether it can be delayed, whether it can be canceled, whether it is allowed to overwrite the current relationship, and whether it needs to restore the original source after failure. Player entry requests may wait for seat confirmation, script enforcement may temporarily turn off local input, network migration may block local submissions, and collision recovery may only cover the brake pass. They are not competitors at the same level and must first be divided according to relationship types and then arbitrate in the current state.

39. Diagnosis sequence of handover faults

When a vehicle becomes unresponsive after a player takes over, or does not recover after leaving the vehicle, diagnosis should not start with physical results.

The first step is to confirm whether the entity is still the same vehicle, whether it has become a clone, and whether it is still eligible for local interaction. The second step is to confirm whether the character still occupies the driver’s seat and whether the seating relationship is in the entry or exit stage. The third step is to confirm which of the AI, player, script, temporary action, or safe recovery has the current submission eligibility. The fourth step is to confirm whether the task is to update old objects, install new objects, enter temporary coverage, or be denied access. The fifth step is to confirm whether the old AI stops submitting, whether the temporary action ends, and whether the command window is closed after the player leaves the car. Step 6 Confirm that the original task snapshot is valid and complete the recovery. Only after these are established, check whether the vehicle cannot move due to collision, rollover, friction or other physical conditions.

40. The handover result should be indirectly perceived by the player experience

Players do not need to see the mission tree, but will judge whether the handover is successful through continuity: after entering the vehicle, the vehicle will not suddenly reset its route or be damaged; after releasing the input, the vehicle will not be pulled back by the old AI command; after the plot action is over, the player’s input can be restored; after leaving the vehicle, the vehicle will not stop for no reason or suddenly accelerate; after the network switch, the vehicle will not appear stale control from the previous authority.

These experience results all correspond to the underlying handover relationship. The so-called stable hand feeling is not only determined by the actuator, but also comes from the control source release, task retention and recovery sequence.

41. Implementation boundaries of P4

This article can describe control source handover, task replacement, temporary actions, player leaving the vehicle, driverless state and migration access, but does not expand on P2’s device sampling and camera input, P3’s command fields and candidate merging, P5’s GPS and route search, P6’s driving personality, P8’s vehicle actuators and physical control laws, P10’s in-vehicle combat input, and P12’s complete network copy, playback and perspective reconstruction.

These systems will appear as handover sources, constraints, or recovery targets, but this article does not develop internal algorithms for them.

42. P4’s source code abstraction and target implementation boundaries

The focus of source code reading is to confirm how different entrances participate in the same vehicle-side task runtime, rather than looking for a function called “takeover”: role tasks propose relationships, vehicle bridging determines installation locations, vehicle intelligent runtime maintenance tasks, temporary actions affect local priority relationships, player driving tasks become a source of commands, and network objects determine whether entity states can be migrated.

The target runtime does not need to mechanically replicate the original source code class hierarchy, but it does need to retain these responsibility boundaries:

When this chain can be recorded and verified, subsequent P5, P6, P8, and P12 can respectively expand routes, strategies, actuators, and migrations without having to add all control sources into the vehicle control class again.

44. Reasons for failure in handover records

If the handover system only records the source of success, it still cannot answer “why there is no takeover” during debugging. The reason for failure should fall on the relationship chain rather than just giving a generic error.

It can be distinguished: the target vehicle is invalid, the seat relationship is not confirmed, the driver’s seat is occupied, the entity is still a clone, the current task cannot be replaced, the old source is not released, the new source is not installed, the command window is not opened, the network authority is denied, the executor is temporarily unavailable, and the recovery snapshot has expired.

These reasons correspond to different recovery actions. If the target fails, the request needs to be canceled; if the seat fails, the reservation needs to be released; if the task is not replaceable, the original AI needs to be retained; if the network is rejected, you need to wait for the authoritative change; if the recovery snapshot expires, you should enter a new security task instead of blindly restoring the old task.

45. Why status version is needed for handover

The same vehicle may experience entry requests, script overrides, temporary actions, player takeovers, and exit recovery in a short period of time. Without a version number, old requests may complete after new ones, and the old tasks may be reinstalled incorrectly.

Therefore each handover should be accompanied by vehicle identity, task version, request sequence and generation period. When a new request is submitted, the vehicle side checks whether it is still targeted at the current entity and current task version; old requests can only be recorded as expired results even if they are subsequently returned.

Version checking can also account for a common problem: the player has left the car, but the old player driving command reappears in the next cycle. The reason is not whether the input is cleared, but because the old command lacks the handover version and is still mistakenly regarded as the current source.

46. Control source handover is not a global lock

Adding a global lock to the entire car can ostensibly avoid concurrent writes, but it will prevent legal parallel relationships. For example, missions can continue to provide goals, traffic rules can provide speed constraints, players can provide local directions, and camera scripts can change lenses independently.

A more reasonable approach would be to record coverage by relationship and channel: who owns the target, who limits the speed, who commits direction, who controls the camera, who has status commit rights. Only conflicting channels require arbitration, and non-conflicting relationships can continue to exist.

47. Restoring from AI driving to world continuity

Whether the vehicle can continue to exist after the player leaves the vehicle depends on whether the handover releases the vehicle from the player’s command window and returns it to an interpretable world state. This state may be AI cruising, or it may be parking and waiting, a mission goal, a distant agent, or a network authority.

It’s not necessarily a bug that a vehicle doesn’t recover AI; what’s buggy is that the vehicle doesn’t have any clear source of control yet still exhibits constant motion. In turn, vehicle recovery AI does not necessarily indicate a successful handover; if it recovers a dead route or expired mission, players will still see sudden deviations in vehicle behavior.

Therefore, “the vehicle continues to belong to the world” does not require that the vehicle continues to move, but requires that the vehicle have clear relationships, tasks, and status explanations at each stage.

48. Methodological conclusion of P4

P1 interprets entering the vehicle as the establishment of the seat and driving window, P2 interprets the input as the device state confirmed by routing and views, P3 compresses the input and task constraints into verifiable commands, and P4 puts the command source itself back into the life cycle.

What this chain ultimately answers is: whether the old source is safely released, whether the new source is eligible for submission, whether the overwritten tasks are retained, whether temporary actions can be restored, and whether the vehicle still has clear world relationships after the player leaves the vehicle.

49. Handover status and observability

The handover of control sources ultimately comes down to observable results. It is not necessary to display all internal states to the player during runtime, but the debugging record must be able to restore a takeover into a sequence of events: when the request arrives, when the seat is reserved, when the original task stops submitting, when the new task is installed, when the first cycle is consumed, and at what step the failure is rolled back.

If you only record the final “player is driving”, you won’t be able to tell whether the handover is late, the mission installation is rejected, the old AI has not been released, or the vehicle has become a remote entity. Observability belongs to the control model itself, not additional log decoration.

50. Engineering inspection of handover process

In the implementation phase, the handover inspection can be divided into three groups. The first group checks access: whether the entity, seat, task, and authority allow entry to the new source. The second group checks replacement: whether the old source is released, whether the coverage is clear, and whether the original task is saved. The third group checks and recovers: whether the new task is installed, whether the first valid cycle is consumed, and whether it enters a safe state after failure.

The three sets of checks respectively correspond to “whether it can take over”, “whether there is dual control during takeover” and “whether it can continue to operate after takeover”. They should not be merged into a final boolean, otherwise failure of any layer will turn into a hard-to-locate “vehicle unresponsive”.

Fifty-one, the last layer of continuity of the takeover experience

What players feel is not whether a certain task object has been replaced, but whether the vehicle maintains the same interpretable state before and after the handover. Directional input should not be suddenly pulled back from old sources, mission objectives should not disappear for no apparent reason upon entering a vehicle, and vehicles should not turn into static objects with no identity as the player exits after exiting.

This requires the interface layer to simultaneously preserve the past, confirm the present, and leave portals for future recovery. In the past, it was the original mission and the original route, now it is the source of effective commands, and in the future, it will be the next source of control after the player leaves the car, the script ends, or the entity migrates.

52. Migration principles of handover relationships

When migrating to a target runtime, the key is to maintain the order between handover events, source releases, task saves, admission decisions, and recovery results, rather than duplicating an old class. Preserving this sequence chain allows vehicles to switch between player, AI, script and network states without losing identity.

53. Handover is not a one-time event

Each handover may leave a subsequent state of waiting, recovery, or arbitration again. If it is regarded as a one-time event, the same conflict will still be faced again in the next cycle; if it is regarded as an ongoing relationship, the vehicle can complete the migration of the control source.

54. The handover results must be recoverable, rejectable and explainable

If control source migration can only succeed, cannot be rejected, cannot be restored, and cannot be explained, then it is still only an input override, not a runtime handover.

55. Final check of handover semantics

Before publishing, both the article and the implementation should return to the same question: who releases, who receives, what is retained, and how to recover from failure. The four answers are clear, and the main line of P4 can remain consistent.

56. AI Native: AI is suitable for organizing handover relationships, but not suitable for determining permissions for others.

The continuity of the player’s driving comes from more than just directional response and acceleration. When the player takes over, the vehicle is still the same vehicle; when the player leaves, the routes, tasks, and world relationships still have the opportunity to continue; after the temporary action ends, the original source of control can be restored; after the entity is migrated, the task semantics can still be reconstructed.

Therefore, the core conclusion of P4 can be written as:

Control transfer is not about deleting the old controller and creating a new one, but about saving the relationship, releasing commit rights, installing the new source, and retaining enough state for the next restore.

P3 lets the vehicle know “which command should be consumed currently”; P4 further ensures that “the source of this command can be handed over, and the vehicle still knows who it is after the handover.” The next article will start with goal formation after control handover and discuss how the player’s destination becomes a route that can be continuously maintained.