Open-World Player Vehicle Driving P3: How Driving Commands Are Formed — From Input Snapshot to an Executable Vehicle Contract

This article is the third article in the “Player Vehicle Driving Series in the Open World”. P1 discusses how the player obtains the control window through seating relationships and driving takeover; P2 discusses how device input enters the vehicle through control views, player-state routing, and vehicle type bridging. This article continues to ask: When multiple systems may affect the vehicle, what exactly does the vehicle runtime receive? Who is responsible for organizing these sources into a verifiable, executable, and recoverable driving command?

Previous article: Open-World Player Vehicle Driving P2: Input, Driving Authority, and Vehicle Camera — When Does Player Input Truly Belong to the Vehicle?

Introduction: The vehicle will not directly consume “what the player pressed”

When the player presses the accelerator, only one thing happens on the surface: an input value changes from zero to a positive value.

But the real questions that vehicle runtime needs to answer are far more than “what is the throttle?” It needs to know:

• Who this input comes from;
• Which control window does it correspond to;
• Which vehicle instance it belongs to;
• In what control period it was sampled;
• whether it is still valid;
• Whether it is constrained by a task, script or other control source;
• Whether the current vehicle accepts this intent;
• After this command expires, should it be maintained, centered, braked, or handed over to another source.

Therefore, the input stream of P2 cannot terminate directly on the vehicle-side. After the input passes through player-state routing and vehicle bridging, an intermediate semantics that can be understood by the vehicle runtime needs to be formed.

This is the topic of this article: driving command is not a collection of input values, but an executable contract that controls the intent under specific vehicle, specific period and specific ownership conditions.

The traditional simplified model is usually written as:

This model is suitable for explaining small racing prototypes, but it is not sufficient for explaining open world vehicles. Command formation in the open world is closer:

This article focuses on the middle four layers: how control candidates are formed, what the command contract contains, how vehicle tasks are consumed, and why different tasks cannot directly compete for the same set of control channels. The final tires, thrusters, flight control surfaces and physics seams were left to P8.

1. What is missing after P2?

P2 has established an input portal. The player input passes through the input runtime, control view, player in-car state and vehicle bridge, and finally reaches the dedicated interpretation layer of the current vehicle.

But “reaching the executor” is still not “forming the command”. There is a stage in the middle that must be clarified: the system needs to compress multiple sources into the only effective control result in the current cycle.

At least four differences must be dealt with at this stage.

1. The input source and the target source are not the same thing

The player can provide direction and throttle intents, but the destination may be provided by a task, the route may be provided by a GPS or AI driving task, and traffic rules may require slowing down or stopping.

The input of the player determines “how I want to control it”, and the task and route determine “what target the vehicle should move towards”. If you mix the two into one input table, the vehicles will be indistinguishable:

• player releases the accelerator;
• The task requires keeping the speed low;
• traffic rules require parking;
• The executor actively refuses acceleration due to failure.

2. The driver’s identity and the command submitter are not the same fields.

P1 has already explained that the driver’s seat relationship is not equal to all control relationships. The fact that the player is sitting in the driver’s seat can only prove that the relationship between the character and the seat is established; P2 further explained that the input view may be temporarily changed by script shots, in-car state, or exclusive control.

Therefore, P3 needs to keep “who is the driver” and “who submitted this order this cycle” separately.

3. One frame input and continuous task are not the same state

The player direction input can change every cycle, but the route target may last for several seconds; the taskconstraint may remain effective for a period of time, and the temporary avoidance only affects a few cycles.

The command contract cannot just save the last floating point value. It also needs to let consumers know:

• Which time window does this value belong to;
• Is it a continuous target or a one-time pulse;
• Whether inheritance is allowed when there is no new value;
• Whether it must be cleared when the source expires.

4. Vehicle tasks need to be rebuildable instead of only receiving instant callbacks

The vehicle driving task in the source code not only runs in the local frame loop, but also participates in task replication, clone recovery and network migration. An anonymous control value that only exists in the input callback cannot support task tree reconstruction.

Therefore, the driving command must be able to be recognized, saved, verified, and reinstalled into the vehicle vehicle-side task runtime when necessary.

2. From the source code entrance: the vehicle consumes the task contract, not the naked input

The following part is an architectural abstraction based on the source code structure, calling relationship and responsibility distribution, and is not the only design form in public implementation. The article uses responsibility aliases to explain relationships; the specific class names in the source code are only used as evidence anchors and are not equivalent to the public API of the target project.

The current reading material gives a clear vehicle-side entry chain:

In this chain, TaskControlVehicleBridge is an important role—the vehicle bridge point. It is not responsible for executing the entire vehicle movement, but connecting the character character-side state, target vehicle and vehicle vehicle-side task. The vehicle entity itself establishes a persistent smart object through VehicleEntity::InitAi(), and subsequently drives the vehicle vehicle-side runtime through VehicleEntity::ProcessIntelligence(...).

These two entrances together illustrate a key fact:

The player-side task determines “who is submitting the control relationship to the vehicle”, and the vehicle-side intelligent runtime determines “how this relationship enters the vehicle task tree and continues to be consumed.”

2.1 VehicleIntelligenceRuntime is not a current driving pointer

The most common misunderstanding in source reading is to understand the vehicle smart object as “the container of the current driving task”. In fact, it has a much wider scope:

• Responsible for maintaining the vehicle vehicle-side task manager and its access relationships;
• Organize scans, events and nearby entity queries;
• Maintain access to routes, nodes, junctions and traffic states;
• Process local vehicle state, stagnation and non-moving records;
• Create and translate vehicle tasks for different task types;
• Distribute different state sources between local vehicles and cloned vehicles;
• Execute delayed completion and distant entity strategies after task processing.

Therefore, the P3 command will not end after writing directly into a “vehicle control field”. It enters a vehicle vehicle-side runtime with its own lifecycle, task tree and post-processing stage.

2.2 VehicleMissionTaskBase provides a common task contract

The value of the shared base class for vehicle tasks is not that it implements specific control for all vehicles, but that it provides a set of contracts that are identifiable across tasks.

Shared parameters that can be observed in materials include:

• target entity;
• Explicit target location;
• reach distance;
• Obstacle size correction;
• driving flags;
• Cruising speed;
• Maximum cruising speed.

The combination of these fields is not the “player button state”, but the task-level driving intent that the vehicle task needs to understand. It can be created by an AI task, or generated by a script entry, police task, or player control bridge.

2.3 The joint contract also bears the responsibility of state reconstruction

The vehicle task shared base class is also responsible for target coordinate analysis, moving target judgment, speed and arrival rule normalization, driving-flag strategy, as well as task serialization and route reconstruction after migration.

Therefore, the driving command contract must be able to answer at least two types of questions:

1. How the current cycle should move;
2. How to restore the same task semantics if the runtime is copied, migrated or reinstalled.

The player input itself usually cannot answer the second question. The player only provides real-time intent on the current device, and the vehicle task must embed this intent into a task relationship that can continue to run.

3. The driving command is not the three floating point numbers of “throttle, brake, and steering”

Simplifying the driving command into three floating point values ​​will lose a lot of runtime semantics.

From the perspective of runtime responsibilities, a driving command needs to express at least five types of semantics.

3.1 Source information: who submitted the command

Source field answer:

• Is it a local player, AI task, script, or replay driver;
• Whether the source still owns the current control window;
• Whether the source allows submission on the current vehicle type;
• Whether the source’s control period is still valid.

The source information is not to display a beautiful label on the debugging interface, but to prevent different systems from writing the same vehicle state at the same time. Without a source, the system cannot explain “why the throttle was cleared in this frame.”

3.2 Target information: What purpose does the command serve?

Target information can come from:

• target entity;
• target location;
• route or node;
• reach distance;
• Chase, follow, cruise or escape modes.

When controlled by the player, the steering wheel and throttle are usually local operations, but the vehicle may still be constrained by the task target. For example, if the player changes direction in the escort task, the task still retains the target vehicle or target area; the player controls local actions during the chase, and the chase task still provides the target relationship.

Target information and input sources must be separated, otherwise the task will be erroneously cleared due to player takeover, or player input will be mistaken for redefining the entire task target.

3.3 Motion intent: How do you want the current cycle to change?

The motion intent is the layer closest to the input of the command and may include:

• longitudinal acceleration or deceleration;
• Lateral steering;
• braking;

-Handbrakes or special actions;

• heading, vertical or attitude intent;
• Whether to accept automatic re-centering or hold.

This is still not where tire angle, propeller thrust, or aircraft control surface angle should be written. That falls under the motion interpretation of type-specific executors.

3.4 constraint information: what the command can do

Constraint information comes from task, traffic, vehicle state and current mode. For example:

• Parking is currently required;
• Lane changes are currently not allowed;
• The current vehicle is entering a junction;
• The current vehicle does not accept a certain input axis;
• The current vehicle is in damaged, overturned or special special motion mode;
• The current driving window is temporarily restricted.

Constraint does not necessarily generate a new player input, but it will determine whether the playerintent can continue to be propagated to the executor.

3.5 lifecycle information: when does the command expire?

The driving command needs to be clear:

• Generation cycle;
• valid tick or cut-off condition;
• Whether to allow the previous cycle to be used;
• How to clear the source when it is released;
• Whether to generate a failure state after executor rejection.

This is also the critical boundary between P3 and P8. P3 defines when the command is valid and how it is consumed; P8 discusses how the executor handles tires, buoyancy, aerodynamics and loss of control when converting valid commands into specific physical controls.

4. Control candidates: retain source differences before command arbitration

“Arbitration” should not be understood as a simple prioritization. It first requires collecting candidates and retaining the source, target, and validity conditions of each candidate.

An open world vehicle may simultaneously receive:

• player local driving intent;
• task target or forced direction;
• Parking constraints generated by traffic rules;
• Temporary controls generated by scripts;
• Playback or network state driver;
• Safety recovery request for the vehicle itself.

The relationship between these sources is not fixed “player is always the highest” or “task is always the highest”. It depends on the current control mode, permissions and failure policy.

For example, in normal driving, the player can submit steering and throttle; during task shots, the script may temporarily turn off local player input, but still retain the vehicle state; in network migration, the network determines which state version can be submitted, rather than directly becoming a normal local input source.

Therefore, a more accurate structure is:

4.1 Candidate commands cannot cover each other without leaving traces

If the player input is directly written to the vehicle, and then the task writes a set of speed limits, the final debugging interface only sees one result value, and the system cannot answer:

• The task covers the player, or the player input does not pass at all;
• The current control view is disabled, or the executor rejected the command;
• The vehicle is switching modes, or the commands of the previous cycle have not been cleared.

Therefore, candidate commands should be able to preserve rejection reasons, coverage relationships, and final selection sources. Even if the public runtime ends up retaining only one copy of the valid commands, the diagnostic snapshot should know which candidates it was generated from.

4.2 A null value is not a candidate, only a zero value may be a candidate

P2 has distinguished between “disabled input” and “zero input”. P3 requires further distinction:

• No candidate commands;
• A valid source submitted a neutral order;
• There are candidates but the constraint is cleared;
• There are candidates but rejected by higher level control;
• A rollback command is generated by the security policy after the source times out.

These five situations may eventually bring the steering value to zero, but their lifecycle and recovery methods are completely different.

5. Goal and control must be separated: why does the vehicle know “where to go” and “how to drive”

The car task family in the source code divides route ownership, local goals and final control into different levels.

5.1 The cruise task has routestate but does not have the final steering wheel value.

VehicleCruiseTask‘s responsibility goes far beyond “moving the car slowly.” It maintains path searches, node lists, follows routes, junctions and lane changes, and switches between road, straight and navmesh modes.

It also calculates the forward distance and speed limit based on factors such as current speed, road nodes, speed zones, turns, narrow roads, trailers and large vehicles.

But it does not therefore become the final controlling writer. Its key output is:

• Which local target point should be approached currently;
• What cruising speed is currently allowed;
• Which navigation mode should be used next.

This is a high-level driving command or target constraint, not tire angle.

5.2 Goto task turns open cruise into goal-driven

VehicleGoToAutomobileTask inherits the same route and state switching mechanism, but adds target-oriented semantics:

• Exit when the target is invalid;
• Determine arrival based on target distance;
• Switch between road routes, straight lines and navigation grids when necessary;
• Continuously provide target position and velocity to local executors.

It illustrates that “go to a target” and “continue cruising” do not require two completely independent vehicle control systems. The two share the routelifecycle and local target interfaces, and the differences focus on target validity and arrival strategies.

5.3 Partially avoid tasks consuming local targets without re-searching for the entire route

VehicleGoToPointAvoidanceTask is located below the routetask and is responsible for traffic and obstacle response within a short time range. It may handle:

• Blockage by vehicles, pedestrians, doors and objects;
• give way at junction;
• rear-end collision and following distance;
• Oncoming vehicles and emergency steering;
• U-turn at three o’clock;
• Stop briefly and accelerate again.

Its key outputs are local: adjusting target points, limiting speed, requesting brakes or steering branches. It does not re-determine the entire route and should not be misinterpreted as a complete pathfinder.

5.4 The lowest GotoPoint task generates local driving intent

VehicleGoToPointTask consumes a local target point and target speed, and then generates a local driving intent closer to the execution layer:

• steering;
• Throttle;
• brake;

-Handbrake.

It adjusts the amount of control based on target direction, current forward speed, steering angle, grade, traction and slip conditions, with the potential to smooth and humanize low-speed movements or conservative driving.

This is the process of “narrowing the command contract layer by layer”:

P3 focuses on this chain of semantic narrowing. P8 will continue to ask how these control quantities enter physical execution.

6. Time semantics of commands: continuous target, short-term coverage and safe return to center

The main difficulty in vehicle driving command is not the number of fields, but the time relationship.

6.1 The lifecycle of the route target is longer than the local control value

A route may last for tens of seconds, the local target point may change every few frames, the braking request generated by avoidance may only last for a short window, and the player’s steering may change every cycle.

If these states are all written into the same structure, the system cannot determine when it should be used and when it must be cleared.

A reasonable command contract should distinguish them as:

• Sustained goals;
• current cycle intent;
• Temporary coverage;
• Failure recovery.

6.2 Coverage must have a beginning and an end

Script cutscenes or task force controls may temporarily override player input. If the overwrite only writes new values ​​without recording the original source and recovery conditions, at the end of the overwrite the vehicle may:

• Continue to maintain the last control of the script;
• Reuse expired player input;
• The zero value is mistaken for the player actively releasing;
• Jitter back and forth between two sources.

Therefore, the coverage relationship needs to be saved at least:

• coverage sources;
• Covered control channels;
• Entry time;
• end condition;
• Source of recovery after closure.

6.3 Timeout is not simply clearing

Cars, boats, and airplanes don’t all use the same recovery method after a command times out.

• The car may gradually slow down and maintain its current direction;
• The ship may maintain propulsive inertia or enter a low-speed drift;
• The aircraft may need to maintain attitude or enter a dedicated failure strategy;
• The train may continue along the track with braking logic.

Therefore, P3 is only responsible for marking the command as invalid, providing the reason for the failure and recovery entry; the specific security movement strategy is responsible for the type-specific executor and P8.

7. Task wrapper and vehicle task: who owns which part

The most common mistake in writing P3 is to regard the player side driving task, vehicle-side task and the final executor as the same object.

7.1 Player-side wrapper ownership relationship and submission entry

Character vehicle-side tasks such as CarDriveTask, CarDriveWanderTask and TaskControlVehicleBridge mainly handle:

• Whether the character enters the correct vehicle;
• Whether the driver relationship is established;
• Whether the corresponding task has been installed on the vehicle-side;
• Whether the character continues to maintain the state in the car;
• Whether you want to exit the car, change seats or other branches.

They can install tasks on the vehicle-side, but this does not mean that they have route, avoidance and local motion interpretation.

7.2 Vehicle smart objects have a continuous consumption environment

The vehicle-side VehicleIntelligenceRuntime is responsible for ongoing processing of task trees, scans, events, route access and task completion. It is the persistent consumption environment after the command enters the vehicle.

This also explains why player driving cannot be simply “player task writes the car directly every frame”. The playertask may be replaced when the character state switches, but the vehicle smart object needs to continue to maintain the vehicle identity, task and feedback.

7.3 The shared task base class has cross-task semantics

VehicleMissionTaskBase is responsible for allowing the Cruise, Goto, Chase, Police Behavior, Attack and Escape tasks to share goals, speeds, driving flags, serialization and migration semantics.

It is not a universal controller, but a contract layer that allows different tasks to be recognized and reconstructed by the same vehicle intelligent runtime.

7.4 Specific tasks have their own target transformations

The cruise task turns the route into a local target; the chase task turns the target entity into a chase geometry; the pull side task turns the target vehicle into a laterally offset position; the police behavior task selects subtasks between cruise, follow, block, and collision.

They can all change “what to approach next” but ultimately still leave motion consumption to common car routes and local execution families.

8. How to enter the same command model from different control sources

Player driving does not require a completely independent vehicle command system. On the contrary, the value of player input is that it can enter the vehicle’s existing task and execution boundaries.

8.1 Player input is a control candidate, not a task tree replacement

After the player takes over, the player can submit local motion intent, but the vehicle still needs to know:

• What type of vehicle is it currently?
• Whether the current control window is valid;
• Whether the current task allows player input;
• Whether the current executor accepts the intent;
• Whether the current vehicle is in network, clone or read-only state.

The player command is therefore a source of vehicle-side, rather than replacing the entire vehicle task tree with a device callback.

8.2 AI tasks can provide constraints without taking all inputs

Chase, escort, and traffic rules may all affect vehicle targets, but they don’t necessarily all cover every local input from the player.

For example:

• task maintains the target entity;
• The route system provides feasible paths;
• player adjusts local direction;
• Avoid speed limit by system;
• executor interprets final control based on vehicle type.

This combination is only true when the goal, intent, and constraint are separated.

8.3 Script control needs clear coverage

The script may require the vehicle to go to a certain location, maintain a certain speed, or enter a cutscene state. But the script control should not automatically take ownership of all vehicle states.

It requires a statement:

• Which command channel to cover;
• to what conditions it lasts;
• Whether to retain camera feedback;
• Which source to restore at the end;
• Whether the vehicle task is still ongoing.

This is also an extension of the “control view” in P2: the input system is responsible for providing legal sources, and P3 is responsible for organizing the sources into bounded command contracts.

9. What different vehicles share is not the control law, but the command lifecycle.

P2 has discussed how different vehicles receive common intents. This article further defines the sharing boundaries:

Cars, boats, airplanes, helicopters, and trains can share sources, validity periods, target relationships, and command lifecycles, but they should not share a set of control laws that convert intent directly into motion.

For example, the same “left” intent:

• The car needs to combine road direction, tire steering and ground adhesion;
• The boat needs to combine propulsion, rudder angle, current and hull inertia;
• The aircraft needs to combine attitude, speed and flight control;
• Helicopters need to combine rotor, lift and hover state;
• Trains need to incorporate track direction, grouping and braking distances.

They can be shared:

• Current command source;
• Command sequence number or control cycle;
• The relationship between goals and constraints;
• Whether the order is accepted;
• Failure reasons and feedback entry.

But they must be dedicated:

• Movement explanation;
• Parametric curve;
• state machine;
• Failure recovery;
• Physical seam.

This boundary makes “adding new vehicles” become adding new interpreters, rather than modifying the global input system.

10. Command rejection is also part of the command system

A mature driving command system cannot only record successful execution. It must also make rejections and delays explainable.

10.1 Rejected input does not mean that the input did not arrive

The vehicle is not moving forward for a number of reasons:

• player view is disabled;
• Driving privilege has expired;
• The vehicle is in read-only clone state;
• The current vehicle does not accept this control axis;
• taskconstraint requires parking;
• The command has timed out;
• The executor is switching modes;
• The physical layer returns failure feedback.

If these conditions all appear as “throttle equal to zero”, the system cannot debug, nor can it explain to the player why the control does not produce movement.

10.2 Rejection needs to be attributed to the correct layer

• The input view is invalid: it belongs to the input runtime;
• The driving window is invalid: it belongs to control authority and player-state;
• Vehicle type does not match: it belongs to bridge and executor selection;
• task is not allowed: belongs to the target constraint or command arbitration;
• Command expiration: belongs to lifecycle verification;
• Movement cannot be completed: belongs to executor and physics feedback.

Putting the rejection reason back into its own layer can avoid using a “universal controller” to handle all exceptions.

11. Several counterexamples in source reading

Counterexample 1: When you see AddTask, you think the player directly controls the vehicle.

The character side bridge calls the task installation function of the vehicle smart object, which can only prove that it hands over the vehicle task to the vehicle vehicle-side runtime. The real route, avoidance and final control are still borne by the vehicle task family.

Counterexample 2: See sVehicleMissionParams and think it is the final control command

This set of parameters includes the target entity, position, speed and driving flag, which is closer to the task-level command contract. It’s not tire rotation or physics engine input.

Counterexample 3: When you see VehicleGoToPointTask writing the control value, you think it owns the route

This task only consumes local targets and speeds and converts them into control quantities. Route search, junction and re-planning still belong to the higher-level cruise/Gototask.

Counterexample 4: Seeing that the chasing task continues to modify the Goto subtask, you think that chasing has all the driving implementations

The pursuit task has pursuit geometry and target transformation, but the actual local motion is still completed through the shared car task family. It’s a target wrapper, not another physical control stack.

12. Minimum command contract of P3

If the discussion in this article were condensed into a minimum conceptual structure, it should at least contain:

This does not require the target project to copy a certain structure, but requires that these semantics cannot be silently discarded.

12.1 Source

Record player, AI, script, replay or safe recovery sources.

12.2 VehicleIdentity

Ensure that commands are not accidentally cast to vehicle entities that have been replaced, migrated, or cloned.

12.3 ControlWindow

Record whether the command is still part of the current driving relationship.

12.4 TargetContext

Record the route, target entity, target point, arrival distance and task mode.

12.5 MotionIntent

Record the desired movement direction in the current control cycle without binding some physical control law in advance.

12.6 ConstraintSet

Document traffic, task, mode, and executor restrictions on commands.

12.7 ValidFrom / ValidUntil

Record when the command takes effect, when it expires, and whether inheritance is allowed.

12.8 Sequence or Frame

Enables local updates, network migrations, and debug snapshots to distinguish between old and new commands.

12.9 AcceptanceState / FailureReason

Enables the system to differentiate between accepted, partially accepted, delayed, rejected and invalidated.

13. Command lifecycle during a complete drive

To understand the value of DriverCommand, break down an ordinary drive into a complete cycle. The player is already sitting in the driver’s seat, and the vehicle has completed the input bridge of P2. At this time, when the player pushes the joystick forward, the vehicle will not immediately write this value as the final movement result.

First, enter runtime to form a control snapshot of the current cycle. The snapshot carries the player source, control view, and sampling period, but it does not have a vehicle target, nor does it have a type-specific motion interpretation. Then the player’s in-car router confirms that the driving branch is still valid, and the vehicle bridge confirms that the target vehicle is still controlled by the local player before submitting this snapshot as a control candidate.

After the vehicle-side receives the candidate, it must be merged with the current task relationship. The routetask may continue to provide target points; the traffic state may provide a speed limit; local avoidance may require brief braking; the vehicle type executor may reject axes that are incompatible with the current mode. Finally, the system forms the driving command that can be consumed in this cycle.

This lifecycle can be expressed as:

13.1 The snapshot is the sampling result, not the final command

The input snapshot only describes “what the player expressed during this cycle.” It cannot alone determine how the vehicle should move.

For example, the player’s forward input may remain unchanged, but the vehicle enters a junction, detects a pedestrian, loses a road node, or is controlled by a script in the next cycle. The same player input can form different final commands in different contexts.

This is why input values ​​must be layered with command contracts. Snapshots are good for describing sources, and commands are good for describing what the system ultimately accepts.

13.2 Candidates are rejectable intermediate states

The purpose of the candidate command is to allow the system to complete the check before final submission. It may be rejected for the following reasons:

• The current driving window has been closed;
• The identity of the vehicle changes;
• Input comes from a read-only clone;
• The current branch is not driving;
• The task requires exclusive control by the script;
• The target command has expired;
• The current executor has not been installed;
• Vehicle mode does not accept this intent.

Rejection of a candidate does not mean that the input system has failed. On the contrary, rejection is the result of the normal working of the control authority and task system. What is important is that the rejection must be observable and cannot be compressed into an unsourced zero value.

13.3 The accepted command may be only partially consumed.

The vehicle accepts a command, which does not mean that all fields can be used by the current executor.

Cars can accept longitudinal and lateral intent, but may ignore vertical control; boats can accept propulsion and steering, but not necessarily car-style handbrakes; aircraft can accept attitude and thrust, but need to interpret “brake” as special semantics for the ground taxiing phase.

Therefore, a command contract should distinguish between:

• Whether the command as a whole is valid;
• Which channels are accepted by the executor;
• Which channels are ignored;
• Which channels were rejected due to pattern mismatch.

This is more reliable than unifying all inputs into a set of default fields.

14. Arbitration is not a fixed priority, but is selected according to channel and mode.

“Command arbitration” can easily be understood as a priority list from high to low: scripts at the top, players in the middle, and AI at the bottom. The real runtime is usually more complex than this structure, because different control sources may be responsible for different channels.

14.1 The same vehicle can have multiple control channels

The task may continue to have target entities and routes, the player may have local steering, the traffic system may have parking constraints, the camera system may have perspective input, and the script may temporarily have a performance channel.

If all sources compete for “control authority over the entire vehicle,” unnecessary coverage will occur. A more reasonable approach is to first determine which fields each source can submit, and then complete the merge at the channel level.

For example:

Source	Can be provided	Should not be owned directly
player	local motion intent, perspective intent	vehicle identity, physical results
AI task	target, route, strategy constraint	player input view
Script	Temporary target or overlay channel	Permanent vehicle lifecycle
traffic rules	parking, speed limit, yield constraints	vehicle type control laws
executor	acceptance, rejection and feedback	upper task target

This division can avoid mistakenly compressing “goal control” and “motion control” into a Boolean value.

14.2 Player input and task target can coexist

Player driving does not necessarily mean that the task target disappears. Escort tasks, chase tasks, and scripted driving may all retain a persistent goal while allowing the player to control local movement.

In this mode:

• task provides target entity or target area;
• The route layer provides feasible road targets;
• player provides local direction and speed intent;
• The avoidance layer provides real-time risk constraints;
• Vehicle executor completion type-specific interpretation.

This is not about multiple systems “grabbing the steering wheel” at the same time, but multiple systems providing input material at different levels.

14.3 Coverage requires channel declaration

If the script needs to temporarily control the vehicle, it should declare that it covers:

• target location;
• Speed limit;
• Shift to intent;
• Entire driving window;
• Or just presentation level feedback.

Different coverage areas correspond to different recovery methods. Overwriting the target position does not necessarily require clearing the player’s steering; covering the entire driving window requires closing player command submission and recording the recovery source.

14.4 Traffic constraint does not necessarily become an independent command source

Red lights, pedestrians, vehicles in front, and junction rights-of-way are usually more suitable as constraints or local target corrections, rather than generating a completely new “traffic driving command.” This keeps the player, AI and script sharing the same consumption chain.

For example, when the player maintains throttle input, the traffic layer can lower the upper limit of the acceptable speed; local avoidance can require braking in the current cycle; the route layer still retains the destination and road relationship. After the obstacle is lifted, player input can continue to be consumed without the need to recreate a set of player driving tasks.

15. sVehicleMissionParams: Why task-level commands need to maintain granularity

sVehicleMissionParams in the source code is one of the most important pieces of evidence for P3. It does not compress vehicle driving into a generalized “target vector”, but retains multiple fields that can be used by different tasks and network states.

15.1 The target entity and target location must coexist

The target entity is suitable for expressing: chasing a car, following a character, approaching a dynamic object. Explicit target positions are suitable for expressing: driving to a fixed point, using the local target given by the task, and continuing execution when the entity is temporarily unavailable.

If only the target entity is retained, the task cannot continue when the entity temporarily expires; if only the target location is retained, the identity relationship of the dynamic target will be lost.

Therefore, the target entity and target location are not duplicate fields, but two different target sources.

15.2 Reaching distance is not a constant

Reach distance affects:

• When to switch to completion state;
• When to stop expanding routes;
• When to switch from straight-line approach to road approach;
• How much space is required for large vehicles or trailers.

It belongs to the task contract, not the local steering parameter. The local executor can adjust the approach method according to it, but should not redefine the task completion conditions on its own.

15.3 Cruising speed and maximum cruising speed have different semantics

The cruising speed can express the target speed desired by the current task, and the maximum cruising speed expresses the upper limit allowed by the task. Road speed limits, driving personality, traffic state and local avoidance can continue to impose constraints on these two values.

If only one speed field is saved, the system cannot differentiate:

• task originally wanted to cruise at a slow speed;
• Road restrictions reduce speed;
• Temporary speed restrictions caused by blocking by the vehicle in front;
• The player input wants to speed up but does not exceed the task limit.

15.4 A driving flag is a collection of strategies, not a switch

Driving signs may affect red lights, stop signs, route usage, waiting nodes, avoidance and special task behaviors. They cannot be simply reduced to a Boolean value that “obeys traffic rules”.

The source task family needs to decide path search and local behavior based on these flags, rather than having the final controller guess the taskintent at the last minute.

This also explains why compatibility mapping must preserve field granularity. The data structure can be changed during subsequent migrations, but several semantics with different consumers cannot be combined into one fuzzy switch.

16. From route target to local command: four narrowings of the car task family

The car task family provides a very clear example of command narrowing.

First narrowing: task target to road route

Cruise and Goto tasks read the target, road nodes and current vehicle state to decide whether to search or re-search the route. The output of this step is the route and node relationship.

It will not directly answer “how much does the steering wheel turn this cycle?” because the complete route has not been compressed into a local approach target.

The second narrowing: the road route to the local target point

The route owner selects a current local target point based on the current speed, required turns, junctions, road width, vehicle size, and forward-looking distance, and calculates the acceptable speed.

This local target point changes as the vehicle moves. It is not a physical control result, but an intermediate result that allows the lower executor to form a stable local driving intent in a short period of time.

Third narrowing: local target to traffic response

The local avoidance task checks the relationship between vehicles, pedestrians, objects, road edges and junctions, and may change the target point, reduce speed, request waiting, temporarily brake or cut into a three-point U-turn.

This step adds the real-time risk of an open world to the command, but still does not require rediscovering the entire destination route.

The fourth narrowing: traffic response to local driving intent

The GotoPoint task generates local driving intents such as steering, accelerator, brake and handbrake based on the local target, current speed and vehicle direction. At this level, the command is specific enough and can be given to the car executor for consumption.

Description of the four narrowings:

This chain is also the most important engineering revelation of P3: commands at different levels cannot override each other.

17. Why chasing task should not re-implement a driving system

The Chase task is often mistaken for another vehicle controller. The source code structure shows that chasing is more like a high-level object changer.

17.1 Before chasing, first determine the real target of pursuit

Goals might be:

• the vehicle being driven;
• The vehicle being ridden;
• Character after losing the vehicle;
• A target entity that needs to regain sight.

When chasing a task, you need to normalize the target relationship first, and then decide which geometric mode is currently used.

17.2 Chasing geometry change targets without writing final control directly

The pursuit task can switch between states such as “approach from behind, continue tracking, find the target, re-establish line of sight”, and continuously modify the target point, distance and cruise speed of the Goto subtask.

What it handles is:

• Chasing drift;
• Detection points;
• line of sight state;
• Chase offset;
• Target speed relationship.

How the car handles junctions, leading vehicles, and direction control is still borne by the common route and local executor.

17.3 Shared execution family ensures continuity between pursuit and ordinary driving

If chasing implements a separate set of controllers, what will happen when the vehicle switches from normal driving to chasing is:

• The speed curve is broken;
• Avoid logical duplication;
• route cache cannot be reused;
• There are two sets of explanations for traffic rules;
• It is difficult to resume normal driving after the task is over.

As a goal wrapper, pursuit can retain the underlying vehicle motion semantics and only change the upper-level goal and strategy parameters. This is why task layer reuse is more important than controller duplication.

18. Invalid path of control command

The successful path can only show that the system is active, and the failed path can show whether the command contract is complete.

18.1 Driver failure

When the player leaves the vehicle, is forcibly removed, enters a non-driving branch, or the control window is closed, the current command should be marked as source invalid. The vehicle cannot continue to use the previous player command until the next system happens to overwrite it.

18.2 Target failure

The target entity may be destroyed, moved, become invisible, or the road node where the target point is located has not yet been loaded. The task should distinguish between the target being temporarily unavailable, requiring replanning, and the task actually failing, rather than turning all situations into zero speed.

18.3 executor failure

The executor may not be installed, has a type mismatch, is not allowed in the current mode, or the physical seam report cannot be executed. The command can remain valid at this point, but the consuming state must be explicitly marked as waiting, rejected, or degraded.

18.4 Command source invalid

The end of the script, the completion of the AI task, the stop of playback, or the transfer of network authority may render the source invalid. The system needs to shut down the source before deciding who will take over; it cannot allow the old source to remain in the arbitration results.

18.5 Unified results for failed paths

The motion recovery of different vehicles can be different, but the command layer must at least provide a unified state category:

Accepted
PartiallyAccepted
Deferred
Rejected
Expired
SourceReleased
ExecutorUnavailable

What is unified is the diagnostic semantics and lifecycle, not the specific movement results.

19. A complete case: the player temporarily loses input during the chase

Consider a continuous driving scenario: the player is driving a car to chase the target, the task retains the target vehicle, the route system continues to provide road directions, and the player makes local corrections through direction input. At this point the player opens a menu or enters a brief scripted scene, and normal driving input is disabled.

The system cannot simply perform an “input stop update”. The correct processing order should be:

1. Enter runtime to continue updating the device state;
2. The player view is marked as temporarily unsubmittable;
3. The current player control candidate no longer enters a valid command;
4. The relationship between chasing tasks and routes remains unchanged;
5. The vehicle task enters the script or safe consumption path according to the current mode;
6. The camera is switched to consumption by script or special view;
7. Re-verify the control window, vehicle identity and current task after input recovery;
8. The player candidate re-enters arbitration instead of directly reusing the old value before being disabled.

This case reveals an important difference:

The input cannot be submitted temporarily, which does not mean that the vehicle task is destroyed; the player cannot be controlled temporarily, which does not mean that the vehicle loses its running state.

If the command contract only saves the throttle and direction, it cannot express this process correctly; if it saves the source, validity period, control window and acceptance state, recovery can become a verifiable lifecycle operation.

20. Command diagnosis: don’t only display the final control value

The debug information for P3 should not just show “steering = 0.2, throttle = 0.6”. These two values ​​cannot tell the developer which layers the command passed through.

A useful diagnostic snapshot should also display:

• current source;
• control windowstate;
• Current vehicle identity;
• Current task type;
• target entity or target point;
• current routestate;
• constraint collection;
• Enter candidate values;
• Value after arbitration;
• Command serial number and validity period;
• executor type;
• Accept, delay or reject state;
• Reason for the last failure;
• Vehicle feedback.

20.1 The same zero value needs to be displayed differently

Turning to zero can mean:

• player has no input;
• player input is disabled;
• The current task requires going straight;
• The current vehicle does not accept steering axes;
• executor returns to center;
• The command has expired;
• The vehicle is under script control;
• The current vehicle does not have a dedicated executor installed.

The debugging interface must show the cause, rather than lumping these conditions into zero.

20.2 The command chain should be replayable

If the source, candidate, arbitration result and rejection reason are saved in each cycle, an abnormal driving process can be reconstructed: when the player lost control, which task covered the intent, when the executor rejected and when it recovered.

This is closer to true runtime diagnostics than just recording the vehicle’s final position. The position is the result, and the chain of command explains how the result is produced.

Twenty-one, P3 verification scenario

P3 does not need to wait for the complete physical system to be completed before validating. Command contracts can first be inspected using observable executor stubs and state records.

21.1 Single player source

The player enters the car, submits the continuous direction and throttle, and verifies:

• The source is the local player;
• control window is valid;
• The command cycle is continuous;
• The target and constraint are not cleared by mistake;
• The executor accepts the corresponding channel.

21.2 Player and task coexist

In an escort or chase relationship, let the task retain the target and let the player change the local direction. Verify that the target relationship and local intent do not overlap each other.

21.3 Temporary script override

Let the script briefly close the player submission and then resume it. Verify that the old player value will not be reused directly, and the first command after recovery will go through permission and validity checks again.

21.4 Target Failure

Destroy the target entity or make the target node temporarily unavailable. The verification command state will enter the target failure or replanning entry instead of silently outputting a zero value.

21.5 The same command for multiple vehicles

Submit the same set of abstract intents to cars, boats, and airplanes, and verify that the source, sequence, target, and lifecycle are consistent, but the channels and feedback semantics accepted by the executor are different.

21.6 Command migration or reconstruction

Save the vehicle task contract, re-create the vehicle vehicle-side task, and verify that the target, speed, driving sign, and source relationships can be restored; at the same time, confirm that local player input will not bypass the new control authority confirmation.

22. From vehicle initialization to command consumption: a complete reading of the source code call chain

The previous chapters explained command contracts by duty. Now re-stringing the source code entries in chronological order, we can see more clearly why the command must exist at the task layer and cannot stay at the player input layer.

22.1 Initialization phase: The vehicle first has intelligence and then waits for the driving source

When the vehicle is initialized, the vehicle-side smart object is created and the driverless or default vehicle task state is set. This step occurs before the player enters the vehicle, and also before the AI driver enters the vehicle.

This means that the first state of the vehicle runtime is not “player is ready for input”, but:

Player driving is just a source of entry later. It does not create a vehicle smart object, nor should it write motion results directly, bypassing the vehicle’s default state.

22.2 Role entry stage: character side bridge preparation submission relationship

The vehicle-side driving task will be prepared only after the character side driving task confirms the target vehicle, seat relationship and entry into the state. This stage may simultaneously handle character animation, seating relationships, and in-car baselines, but it hasn’t yet determined how the car will find its way or avoid pedestrians.

What a role task really accomplishes is two things:

1. Let the character continue to be regarded as a valid occupant or driver by the vehicle runtime;
2. Give a copy of the vehicle task or task parameters to the vehicle-side smart object.

This division of labor prevents the “getting in the car animation task” and the “road driving task” from having the same state with each other.

22.3 Vehicle task installation phase: general tasks are translated into specific task families

The vehicle smart object has a set of task creation and translation entries, and specific tasks can be selected based on the vehicle type, task identifier and task parameters.

What this translation process solves is:

• How universal task identifiers correspond to car, boat, airplane or helicopter tasks;
• How to re-create tasks when the network is restored;
• How to choose cruise, goto, chase or police behavior branches for high-level tasks;
• How to enter different specific task subclasses with the same task parameter.

Therefore, the command contract should not directly carry a pointer to which control function to call. It should carry identifiable task semantics, allowing vehicle smart objects to reselect specific tasks under the current entity and current vehicle type.

22.4 task update phase: upper-level tasks continue to rewrite lower-level goals

In the vehicle task tree runtime, the upper-level cruise, Goto or pursuit tasks will continuously update the target, speed and mode of the lower-level tasks. Lower-level tasks do not need to know the complete task history and only need to consume the currently valid local contract.

This gives the task tree an important continuity: high-level goals can change, but low-level executors do not need to be rebuilt every time the goal changes; local tasks can also change due to avoidance or path mode switching, without affecting the identity of the player’s input source.

22.5 Post-frame phase: completion and feedback cannot be forgotten

The vehicle smart object will also perform delayed completion, state cleanup, event processing and entity strategies after task processing. This means that the lifecycle of a command does not end at the moment when the control amount is written.

For example:

• The task has been completed, but the character still needs to maintain the relationship in the car;
• The route is invalid, but the vehicle needs to enter the re-planning state;
• The executor rejects an input, but the vehicle still needs to retain the rejection reason;
• The vehicle becomes a distant view or a clone entity, and the command source needs to be switched;
• After the player leaves the car, the vehicle needs to return to AI or driverless state.

If the command contract only exists in the temporary variables of the update function, the post-frame phase cannot continue to maintain these relationships.

23. Why is the task factory the command translation layer?

In the source code material, the vehicle smart object has both a task update entry and a task creation entry. This type of organization is critical.

23.1 Create an entrance to translate external intent into internal task

The external system may only know:

• Cruise;
• sail to a certain point;
• Chasing goals;

-Police obstruction;

• Escape from danger.

The vehicle smart object needs to translate these intents into specific task objects based on the current vehicle, current mode and task parameters. This translation process must be centralized, otherwise each external caller will determine the vehicle type and create its own control path.

23.2 Task identifier cannot replace parameters

The task identifier can only express “what type of thing to do” and cannot express target location, speed, arrival distance, traffic signs and target entities.

Therefore, the command contract includes at least:

Mission Type
+
Mission Parameters
+
Source Context
+
Validity and Ownership

Separating task types and parameters allows the same type of tasks to be used by different sources, and also allows network recovery or script reconstruction to maintain consistent semantics.

23.3 The task translation layer is not equal to the universal decision maker

The task factory is responsible for creating the correct task type. It is not responsible for determining the goals for all tasks, nor is it responsible for interpreting the final movement.

This is an easy structural slippage: developers see that all tasks go through the same factory, and they stuff routes, avoidance, speed, and physics into the factory. The result is that new tasks must modify the central dispatch logic, and new vehicles must pollute the global creation entry.

A more stable boundary is:

• The factory is responsible for type and contract translation;
• task is responsible for its own target transformation;
• The executor is responsible for its own motion interpretation;
• The vehicle smart object is responsible for continuous scheduling and lifecycle.

24. Cloning and migration: Why can’t command contracts only exist locally?

Another important property of a vehicle driving command is that it must be able to be observed, copied or reconstructed. This does not mean that this article will expand on the complete network protocol, but it will explain why P3 needs to retain serializable semantics.

24.1 The local player command and the cloned state are not from the same source

Local player control can rely on device input and local control views; a cloned vehicle cannot read local devices and cannot assume that the local player still owns its control window.

Therefore, the vehicle-side intelligence of the cloned entity needs to run based on network state, task snapshot, or state reconstruction information, rather than continuing to execute the player input on the previous machine.

24.2 Taskstate can be rebuilt, but device state cannot be rebuilt directly.

The target entity, target location, task type, cruise speed and driving flags can be saved and restored as task state. The player’s current joystick position belongs to the device’s instant state and cannot be directly reused on another entity.

This requires command contract distinction:

• Reconstructable task semantics;
• Device intent that is only valid for the current local control window;
• Feedback of results generated by authoritative state.

24.3 Command serial number is used to determine the old and new relationship

When a vehicle task is migrated or reinstalled, the system needs to determine whether the new command overwrites the old command. Serial number, cycle or version fields can help differentiate:

• New local controls;
• old delayed messages;
• Resend the same command;
• Residual state before migration.

It doesn’t necessarily require the use of some fixed field name, but the semantics can’t go away.

24.4 Control authority must be re-confirmed during recovery

Even if the task parameters can be completely restored, the playercommand-submission authority cannot be automatically restored. The recovery process still needs to be reconfirmed:

• current controller;
• Current seat relationship;
• Whether the current entity is writable;
• Whether the current input view allows submission;
• Whether the current vehicle type and executor match.

This rule connects the control window of P1, the input view of P2, and the command validity of P3.

25. Four coexistence forms of player commands and AI commands

Player and AI do not only have two mutually exclusive states: “player control” and “AI control”. At least four finer coexisting forms can be observed.

25.1 AI provides the target, and the player provides local movement

This is the most common form under task escort, chase or route constraint. The AI task continues to hold the target relationship, the player submits steering, speed, or local operations, and the executor merges the two.

25.2 The player provides motion intent, and the transportation system provides hard constraints.

The player continues to press the accelerator, but a red light, pedestrian or obstacle ahead causes the system to limit the speed. The traffic system does not have to create a new player control source, it only needs to provide a constraint or local rejection reason to the command contract.

25.3 Script temporarily owns a channel

Scripts may temporarily control target position, camera, or vehicle behavior, while the player retains other inputs that are not overridden. Turning off player command submission completely is only necessary if the script explicitly monopolizes the entire driving window.

25.4 AI reconnects to the command source

After the player leaves the car or the input fails, the AI can pick up the car. This process does not create the AI from scratch, but restores a new valid source using the vehicle’s already saved routes, task phases, and entity state.

The four forms jointly describe:

The control source is a relationship in the command contract, rather than switching the entire vehicle between the player and the AI.

26. Field mapping and minimum implementation order of command contract

If you migrate P3 to another runtime, the most common mistake is to design a huge structure first and stuff all possible vehicle fields into it at once. A more reliable approach is to gradually build up semantic levels.

Phase 1: Identity and Validity

First implement:

• Vehicle identity;
• Source identity;
• control window;
• period or sequence number;
• Accept, reject and expire states.

Without these fields, no special-motion value can be attributed.

The second stage: task target and constraint

Then add:

• target entity;
• target location;
• reach distance;
• Cruising speed;
• maximum speed;
• driving flags;
• Temporary constraints.

This layer can be consumed by the car task first, without waiting for the physical implementation of ships and airplanes.

The third stage: joint movement intent

Then add:

• Vertical intent;
• Horizontal intent;
• brake intent;
• Special moves;
• Neutral value and source state.

Common intents remain abstract and should not be tied directly to tires, rudder angles, or flight controls.

The fourth stage: type-specific acceptance of state

Finally, provide different executors:

• Which channels are accepted;
• current mode;
• Reasons for ignoring and rejecting;
• feedback state;
• Invalidation and recovery portal.

This sequence allows the car to establish a complete command chain first, and then the ship and aircraft only need to implement their own interpretation exits without having to repeatedly modify the player input entry.

Twenty-seven, several engineering counter-examples of P3

Counterexample 1: Directly write the player input to VehicleEntity

This design is easy to “look like it can drive” in the early stage, but it bypasses the task target, control source and vehicle smart object. Explicit access will be lost when player leaves, script overwrite, network recovery and AI takeover.

Counterexample 2: Define completely different command structures for each vehicle

Of course, cars, boats, and airplanes have different motion semantics, but if the source, validity period, target, and failure state are defined separately, the system cannot handle control authority migration and diagnosis in a unified manner.

Counterexample 3: Let local avoidance regenerate the complete route

Short-term obstacles only require changing the local target or speed constraint. Allowing the avoidance task to regain full pathfinding will lead to duplicate route caches, confusing task completion conditions, and loss of pursuit targets.

Counterexample 4: Mark all overrides as “script control”

Scripts may only cover cameras, targets, speed caps, or a certain performance channel. Squeezing these into a script-exclusive state will cause the player input to be excessively closed, and it will be impossible to know which channels should be handed back when restoring.

Counterexample 5: Expired commands automatically use the previous frame

For continuous cruising goals, inheritance may be reasonable; for player steering, script overrides, and network migration, inheritance may produce dangerous ghost controls. Inheritance policy must be explicitly determined by the command channel and executor.

28. From source code evidence to public articles: Which judgments can be written where?

P3’s source code material can easily be written as a string of class names. In order to maintain the credibility of the article, the levels of evidence need to be separated.

28.1 The fact that the code directly displays

You can write more explicitly:

• Vehicle initialization will create persistent smart objects;
• The vehicle processing loop will call smart objects;
• The character side control task will install the task to the vehicle smart object;
• Shared task parameters include target, distance, speed and driving flag;
• Cruise, Goto, avoidance and final control tasks have different responsibilities;
• Chase and police action tasks will override or select underlying tasks.

28.2 Architecture abstracted from calling relationships

You can use “embody” and “can be abstracted as” to express:

• There is a continuous running owner on the vehicle-side;
• character vehicle-side task is the bridging layer of vehicle tasks;
• The shared task base class assumes the command contract;
• The car task family forms the hierarchy of routes, local execution and final control.

28.3 Unique implementations should not be declared directly

Don’t write:

• All games must use the same task tree;
• A certain public abstraction is the only real implementation;
• All vehicles share the same set of control fields;
• A certain bridge function owns the entire vehicle system;
• The task parameter is equivalent to the physical input.

This is not to reduce the strength of the article, but to separate the source code evidence and project migration judgment. The reader can tell which are observations and which are abstractions based on responsibility relationships.

29. See how command semantics change layer by layer from the four types of tasks

Putting the car task family in the same table can more intuitively see the changes in the form of commands at each level.

task layer	main input	main output	irresponsible content
Cruise / Goto	Target, route, speed, driving flag	routestate, local target, speed limit	Final steering and braking
Local avoidance	Local targets, obstacles, traffic state	Waiting, braking, offset targets, short-term speed limits	Full destination
GotoPoint	Local target, target speed, current vehicle state	Steering, accelerator, brake, handbrake	route search and task target
Chase / Police Packaging	Target entity, tactical mode, offset relationship	Rewritten Goto target and speed	Vehicle underlying control law

29.1 The command of the cruise task is “continue how to go”

Cruise is not an idle state that only runs when the vehicle has no tasks. It continuously maintains routes, nodes and the current road context, and decides whether to re-plan the next step based on the vehicle state.

Its command semantics typically include:

• Continue along the current route;
• Adjust speed according to speed limit and driving strategy;
• Change the forward sight distance before junction;
• Waiting for road nodes to load;
• Switch from road route to straight line or navigation grid mode;
• Regenerate task state after route ends or target changes.

When the player’s directional input enters this layer, it should not be interpreted as “changing the entire route.” The player only provides local control intent in the context of the current task; if the player performs an operation that significantly deviates from the road, the routetask can continue to exist, and the local executor determines how to approach or return to the road based on the current vehicle position.

29.2 The command of Goto task is “Complete approach to this goal”

Goto shares many route mechanisms with cruise, but it adds target validity and arrival judgment.

When the target position changes, Goto may need to replan; when the target is invalid, it needs to end or switch strategies; when the vehicle approaches the target, it needs to determine whether the task is completed based on the arrival distance.

These all belong to task command semantics, not throttle or direction values. In the end, the executor only needs to know the current local target and speed limit, and does not need to understand “this target comes from an escort, a chase, or a script task.”

29.3 The command to avoid a task is “do not approach as originally planned for the time being”

Partial avoidance is a layer that is particularly easy to misread. It does not necessarily generate new destinations, but imposes short-term constraints on the original destinations:

• slow down;
• Stop and wait;
• Go around the obstacle;
• Recalculate local targets;
• Trigger three-point U-turn;
• Special response to pedestrians or vehicles entering ahead.

After the avoidance is lifted, the original route and target may still be valid. If avoidance is designed as a complete task replacement, the system will need to restore the route, reach distance and task target every time an obstacle occurs, adding unnecessary state migration.

29.4 The final GotoPoint command is “Now how to exert control”

GotoPoint should not know the complete task tree, nor should it own the chasing target. It only consumes narrowed local data: target position, target speed, current vehicle state and local constraints.

The benefit of this design is that player input, AI cruise, pursuit goals and script goals can ultimately be interpreted through the same local execution entry. The differences remain in the target formation and constraint merging stages, rather than duplicating four sets of steering, throttle and braking logic.

30. Why does the processing cycle of VehicleIntelligenceRuntime determine that commands must be layered?

The processing cycle of the vehicle smart object is not a simple task callback. It also completes scanning, events, junctions, route caching and entity state processing before and after tasks.

30.1 At the beginning of the frame, the instantaneous state of the previous cycle needs to be cleared

Each cycle of the vehicle may produce:

• Whether a threatening vehicle is detected;
• Whether the water surface or alarm state changes;
• Whether local avoidance needs to be reprocessed;
• Whether it is in a stagnant or unable to move state;
• Whether the task needs to be updated from the network or cloned state.

These states cannot directly override persistent targets. They belong to this cycle or short window data and should have a clear start and end in the command contract.

30.2 Task pre-processing determines which candidates can continue

Before the vehicle smart object enters the task tree, the context may have been updated based on entity state, clone state, nearby objects, and route conditions. What the task consumes is not an input separated from the environment, but data that has been prepared by the vehicle-side.

This also explains why the player input cannot write the final value directly outside the vehicle entity: external writing will bypass the vehicle context confirmation of this cycle, causing the task tree to think that the vehicle can be executed, but the entity state actually does not allow execution.

30.3 Consume the current valid contract in the task processing stage

In the task tree runtime, the upper-level tasks and the lower-level tasks have different responsibilities. The upper-level tasks continuously generate local targets and constraints, and the lower-level tasks read these results and calculate more specific control quantities.

If multiple tasks can directly write to the vehicle in the same cycle, the order of the task tree will become the implicit control authority. A safer way is:

1. Task generates candidates or updates targets;
2. Determine the currently valid command from a unified consumption point;
3. The type-specific executor reads and reports the acceptance results;
4. The vehicle smart object records feedback and task state.

30.4 Task post-processing retains completion and rejection information

The end of the task does not mean that the vehicle command disappears immediately. For example, after the Goto is completed, the vehicle may still remain in the vehicle smart object; after the pursuit task is completed, the vehicle may return to cruising; after the partial avoidance is completed, the route target still needs to continue consuming.

If the task post-processing only deletes the current pointer without retaining the completion reason and next state, the command chain will be broken. The command contract therefore needs to coexist with the tasklifecycle, rather than being created only once when the task enters.

Thirty-one, three common command merging cases

31.1 player normal driving

The player owns the current control window, the vehicle has no script coverage, and the route or task only provides background constraints.

The merging process can be written as:

The source of the final command is the player, but it is still subject to vehicle, route and traffic constraints.

31.2 Temporary script control during player driving

The script requires the vehicle to enter a scene location, but does not necessarily require the entire driving lane to be captured.

Possible merging methods are:

• The script provides the target location;
• player still provides local direction;
• task provides speed limit;
• The camera switches to script view;
• executors continue to use car control semantics.

If the script needs to take over completely, mark the player control window as unsubmittable and make the script the current valid source. At the end of the script, the relationship between the control window and the source is restored, not just changing a Boolean value back to true.

31.3 Partial correction of the player in the chase

The pursuit task continues to have a target entity and a pursuit mode. The player wants to change the lateral direction, perform partial avoidance, and discovers that there is an obstacle ahead.

The end result might be:

• Target source: chasing task;
• Local motion source: player;
• Speed constraint source: obstacle ahead;
• executor: car-specific executor;
• Accept state: horizontal intent is partially accepted, and vertical intent is limited.

If the command system can only choose one “ultimate controller”, this scenario will be forced into an overlay relationship; if the command system allows sources to be combined by channel, more real semantics can be preserved.

32. Why does the command contract require “partial acceptance”?

There are also a large number of partial acceptance states between “accept” and “reject”.

32.1 Vehicles may only accept partial axles

When the car is currently in reverse at low speed, certain inputs may be accepted, but lateral control may be modified by the reversing strategy or road constraints. A boat in shallow water may accept direction but refuse to advance. The aircraft may accept taxi direction during the ground phase but not attitude control in the air.

32.2 task may only accept some targets

A script may temporarily override speed but still allow the player to change direction; an escort task may retain the target area but release local route selection; a traffic system may only limit speed and not change the player’s camera and input view.

32.3 Feedback needs to state some of the reasons for acceptance

If the executor only returns a Boolean value, the developer cannot determine whether:

• The entire command is rejected;
• Only a certain channel is restricted;
• The command is delayed until the next mode;
• The current value is replaced by the security policy.

Therefore, command results can contain channel-level state:

Throttle: Accepted
Steering: Clamped
Brake: ForcedByConstraint
Vertical: Unsupported
Camera: OwnedByScript

This type of result does not require that all vehicles have complete physical implementation immediately, but the control boundaries can be clearly verified first.

33. Debugging path from “control value” to “interpretable result”

A complete diagnostic process should be directed backwards along the chain of command, rather than guessing the cause from the final location.

Step 1: Confirm the source

Check whether the current command source is player, AI, script, replay or safe recovery. If the source is no longer the player, you should not continue to check whether the player joystick value is correct.

Step 2: Confirm control window

Confirm that the character is still in the driving branch, the seating relationship is valid, the vehicle entity is writable, and the player view is not disabled. If this layer fails, there is no need to continue troubleshooting subsequent vehicle tasks.

Step 3: Confirm task target

Confirm whether the target entity, target point, route and reach distance are valid. If the target has expired, the vehicle may have no local target to consume, and the player’s local input may only remain in the executor layer.

Step 4: Confirm constraint

Check for traffic stops, task speed caps, local obstacles, mode switching and special script controls. Many “throttle has no effect” problems are actually speed constraints taking effect.

Step 5: Confirm executor

Check that the bridge has the correct type of executor installed, that the executor accepts the current channel, and that it is in input valid mode.

Step 6: Confirm feedback

Vehicle speed, attitude, collision and physics feedback are checked last. This distinguishes between a command not being formed, a command being denied, and a command being formed but physically unable to be executed.

This diagnostic path itself is the engineering value of P3: it breaks down a vague “car not responding” into multiple relationships that can be independently verified.

34. Contents that P3 should not assume in advance

In order to maintain the continuity of the series, this article explicitly does not expand on the following content:

• Complete implementation of device sampling, control view and camera input, belongs to P2;
• How AI releases, saves and restores control source, belongs to P4;
• The complete lifecycle of GPS, road routes and navigation services, which belongs to the subsequent navigation chapter;
• Independent calculation of driving personality, risk parameters and traffic strategies, which belongs to the follow-up strategy chapter;
• Tires, flotation, aerodynamics and physics fit, P8;
• In-vehicle aiming, driving shooting and combat controls, belong to P10;
• The complete plot flow of the chase event and dynamic control authority belongs to P11;
• Complete rebuild of network authority, replays and LODs for P12.

This article may mention these systems because they are the source of command candidates or constraints; but without re-expanding their internal algorithms.

Thirty-five, P3 core checklist

When a driving command is considered “formed”, it should at least be able to answer:

1. Which control source does the current command come from?
2. Does the source still have a control window?
3. Which vehicle is the order directed against?
4. What is the current task goal?
5. Which routes and traffic constraints are in effect?
6. Which control cycle or version does the command belong to?
7. Can the command be continued?
8. Which channels are accepted, restricted or denied?
9. What type is executor?
10. When the vehicle does not respond, at which level does the failure occur?
11. Who will take over after the source is released?
12. Which fields must be retained when the task is rebuilt?

If these questions cannot be answered, the system may still be able to move the vehicle, but it may not yet form a stable driving runtime.

36. Migration judgment of command contract

When moving from source reading to target runtime design, the most important thing to retain is not a certain class name, but the semantics that are not lost when commands are passed between different layers.

First, retain source and ownership. Any vehicle control results should be able to answer who submitted, who approved, who rejected, and when the source was released. Second, keep the separation of goals and constraints. Task, route, traffic, and player local inputs can be combined to form commands, but they should not be squashed into an uninterpretable final value. Third, retain the time and sequence number. The command must be able to determine whether it is old or new, valid, expired and restored. The control value of the previous cycle cannot be defaulted to be still valid in the next cycle.

Fourth, preserve the boundaries of type interpretation. Cars, boats, and airplanes can share command lifecycles, but they should not share an unproven set of motion control laws. Fifth, retain rejection and partial acceptance results. The executor does not support a certain channel and the mode temporarily does not allow certain actions. These are normal runtime results and should not be hidden as silent failures.

Once these five boundaries are retained, the target runtime can first implement cars, and then gradually add boats, planes, helicopters or special vehicles, without having to re-modify the player input system for each expansion. On the contrary, if you only pursue “the input can make the car move” at the beginning, all subsequent control authority migration, task coverage, network recovery and type compatibility issues will be piled back into the same vehicle control class.

Therefore, the migration goal of P3 is not to copy the vehicle task source code, but to establish a checkable command chain: the source is confirmed, the target is retained, the constraints are visible, the lifecycle is clear, the executor can explain, and failures can be reported back.

This chain also determines how subsequent articles are written. P4 does not need to re-discuss where the input value comes from, but should discuss how the source is released and restored; P8 does not need to re-determine the task target, but should discuss how the accepted command enters the specific executor; P12 does not need to copy the local device state, but should discuss how the command and task relationship remains reconstructable during entity migration, playback and remote state. As the middle layer, P3 is responsible for turning the “input belongs to the vehicle” in the previous article into “the command has been established” that can be consumed in the next article.

When this layer is clarified, many originally vague vehicle problems will be accurately attributed: the player cannot control, check the source and control window first; the vehicle goes in the wrong direction, check the target and local constraints first; the vehicle continues to accelerate after mode switching, check the validity period and old source first; new vehicles cannot respond, check the type acceptance matrix first; ghost control appears after the network is restored, check the serial number and command reconstruction first. The value here is not to add an intermediate structure, but to have a runtime location that can be tracked for each failure.

This is also the basis for the player’s driving experience to remain continuous: what the player feels is direction, speed and camera feedback, and the system must maintain the source, target, constraint, task and execution state at the same time. Only if these relationships are preserved at the command level, the vehicle will not suddenly lose its identity due to an input disable, a task switch, or a vehicle mode change.

The command layer is therefore not an additional abstraction burden, but a necessary seam that connects the player experience to the vehicle runtime.

It allows inputs, tasks, vehicles, and executors to acknowledge each other within the same cycle.

This is exactly why P3 exists.

It is also a prerequisite for stable access of the subsequent execution layer.

This seam must remain clear.

Thirty-seven, the boundary between P3 and P2, P4, P8

P2: Who does the input belong to?

P2 is responsible for device state, input mapping, control view, player in-car routing, bridge and type selection. It answers:

Whether the current input is qualified to enter the vehicle, and which type of vehicle should be given for interpretation.

P3: What does the vehicle receive?

P3 is responsible for candidate commands, sources, targets, constraints, validity periods, sequences, and rejection reasons. It answers:

Which verifiable driving command is finally received by the current vehicle runtime.

P4: How AI hands over control

P4 will continue to discuss how the AI driving task releases, saves and restores control relationships, and how the vehicle returns to the next control source after the player leaves.

P8: How commands become movements

P8 discusses how the executor converts commands into specific movements of cars, boats, airplanes, and other vehicles, including kinematics, physical adaptation, and failure handling.

38. AI Native: Divide “vehicle not responding” into verifiable relationships

P3 is suitable for using AI, but the value of AI does not lie in replacing source code judgment.

Faced with a large number of vehicle tasks, script entries and state branches, AI can help establish cross-indexes:

• Which functions generate candidate commands;
• Which objects have the command lifecycle;
• Which tasks only change the target;
• Which tasks generate local driving intent close to the execution layer;
• Which fields need to be serialized;
• Which rejection reasons should be shared between different vehicles.

This kind of sorting can break down “vehicle not responding” into multiple verifiable problems:

• Whether the input forms a candidate;
• Whether the candidate passes the control authority check;
• Whether the order is still valid;
• Whether the vehicle task is accepted;
• Whether the local target is valid;
• Whether the type executor is accepted;
• Whether physics feedback reports failure.

AI can be responsible for compressing materials, building relationship tables, and discovering omissions; humans still need to judge which relationships are source code evidence and which are just migration assumptions.

39. Conclusion: Command is the common language of vehicle runtime

After P2, the player input is no longer an isolated device value. It needs to enter the vehicle vehicle-side task tree and form a command contract with route, target, traffic, script and executor with source, constraint, validity period and failure reason.

From the perspective of source code responsibility distribution, vehicle driving can be split into several layers:

1. The player-side task and the bridge maintain the control relationship;
2. VehicleIntelligenceRuntime provides a durable vehicle-side consumption environment;
3. VehicleMissionTaskBase provides shared task contract;
4. Cruise and Goto tasks maintain routes and local targets;
5. The avoidance task handles short-term traffic constraints;
6. GotoPoint task generates local control values;
7. Type-specific executor and physical layer complete specific movements.

Among them, P3 is between the input entrance of P2 and the movement execution of P8.

What it really wants to solve is not “how to pass the throttle value”, but:

How ​​to make different control intents from player, AI, task and script form a driving command with source, target, lifecycle, rejectability and recoverability on the same vehicle.

The next article will continue to deal with the handover of control authority: when the player, AI, task and vehicle itself may need to change the source of commands, how does the system save the old state, release the current submission rights, and allow the vehicle to continue running after the handover is completed.