Open-World Player Vehicle Driving P2: Input, Driving Authority, and Vehicle Cameras — When Does Player Input Belong to the Vehicle?

This is the second design-analysis article in the Open-World Player Vehicle Driving series. P1 examined how the player becomes the current driver through seat relationships and takeover. This article follows the input after that takeover: how it passes through the system control layer, the player-in-vehicle router, and vehicle-specific executors before becoming a driving meaning that an automobile, boat, or aircraft can understand. Vehicle cameras are treated as part of the same chain, but not as vehicle controllers. Concrete target-runtime implementation remains outside this article.

Introduction: Pressing a Button Does Not Mean the Vehicle Received Control

In a simple driving model, the player presses a key, the vehicle receives a value, and physics moves it. That model is sufficient only when the vehicle is a local object with one control source and one motion interpretation.

Open-world vehicles are different. Before input reaches the vehicle, the runtime must decide whether the current source is valid. After input enters the vehicle, it must be interpreted according to the current vehicle type. Once execution produces a result, the camera must turn speed, steering, collision, and attitude changes back into a continuous player-facing signal. Input does not travel directly from a controller to tires, propellers, or rotors; it passes through a runtime chain maintained by several owners.

The chain explains a frequently missed fact: player input is not vehicle control itself. It is a set of intentions that the vehicle runtime interprets under the current authority, state, and vehicle type.

P1 established the player’s current command-submission relationship rather than transferring ownership of the entire vehicle runtime. P2 explains how that relationship is validated, routed, interpreted, and fed back during each update cycle.

1. Continuing from P1: A Control Window Still Requires Validation

P1 solved how the player obtains a driving window through seat relationships and the takeover process. This article does not redefine driver identity. It examines how input is accepted, routed, and interpreted inside that window. Completing the entry action does not guarantee that the next update can submit driving input: a seat transition, exit, hit reaction, mission control, script camera, or input gate may temporarily change the current consumer relationship.

P2 therefore keeps one necessary premise: every control cycle must revalidate the driving window, the input view, the vehicle bridge, and the type-specific executor. Command submission is not a permanent switch; it is a runtime relationship updated by context.

2. Source-Reading Boundary: Abstract Responsibilities Instead of Copying Names

To avoid treating private source names as public APIs, this article uses responsibility aliases. These aliases describe stable responsibilities observed while reading the source and do not prescribe the names used by a target runtime. The article abstracts responsibility relationships rather than reproducing source naming.

Article alias	Responsibility observed in the source	Focus here
InputRuntime	System-level input management and input-state maintenance	Sampling, mapping, disabling, exclusivity, and input views
PlayerVehicleRouter	Upper-level routing for the player’s in-vehicle state	Maintaining the in-vehicle state and selecting driving, interaction, or exit branches
VehicleControlBridge	The bridge that installs player control on the vehicle intelligence tree	Validating the relationship and selecting the vehicle type
VehicleDriveBase	A driving contract shared by player-driving leaves	Common entry, update, exit, and no-driver handling
VehicleDriveAutomobile, etc.	Type-specific executors for automobiles, boats, aircraft, and rotorcraft	Interpreting the same player intention in different ways
CameraOrchestration	A coordination layer for script, scene, and special-state camera requests	Camera switching, interpolation, attachment, hints, and temporary takeover

This naming approach preserves source-reading granularity without turning internal names into target-runtime APIs. It also allows the same responsibility map to survive a different engine implementation.

3. The Input System Is a Continuously Updated Runtime, Not a Key Table

The source input layer is not merely a static table such as “W means throttle” or “mouse means camera.” It has at least three responsibilities: obtaining current device state, converting that state into logical input values, and exposing different control views to different consumers.

3.1 The Control Manager Sits Between Devices and Gameplay

The system-level control manager initializes input devices, advances the input-update process, maintains input state, and exposes updated control objects to gameplay, cameras, the frontend, and scripts. It is not a vehicle driver and does not understand tires, elevators, or hull displacement.

Its responsibility can be summarized as:

device state → input update → mapping state → control views → gameplay consumers.

This separation matters. The input layer should not write throttle directly into a vehicle, nor rebuild every low-level binding into an aircraft-specific table merely because the player is flying. Device-to-logical conversion belongs to the input layer; logical values becoming vehicle semantics belongs to the player-control path and the vehicle-specific executor.

3.2 The Input Update Process Is Not Another Gameplay Owner

The source shows a dedicated input-update process coordinated with the main flow through run signals, completion signals, and message-pump synchronization. Loading, startup warnings, pause states, and streaming installation may also call input update directly, but these are special loops or fallback consumers, not independent input systems.

For player driving, the important question is not which execution context updated the input. The important question is whether an interpretable result exists before gameplay consumes it. A vehicle executor should not read the keyboard, controller, or mouse by itself, and it should not bypass authority checks because one input update arrived late.

3.3 The Control State Owns Values; the Mapper Owns Interpretation

Each control object maintains input values, device bindings, context mappers, and current sources. Mapping is also affected by platform settings, keyboard and controller layouts, user preferences, first- or third-person preferences, scripted mappings, and editor mappings.

The same “forward” intention therefore passes through two interpretations. First, a device state becomes a logical value: a stick, key, pedal, touch gesture, or script injection may all produce the same logical axis. Second, the logical value becomes a vehicle meaning: an automobile may interpret it as throttle or a speed target, a boat as propulsion, and an aircraft as a flight-control intention.

The first compatibility principle is therefore not that every vehicle shares one control structure. All vehicles should share a sufficiently stable intention interface while retaining their own semantic interpretation layer.

4. Control Views: Player, Camera, Frontend, and Mapping Query Are Not the Same Input

The control manager exposes several public control views. Their names may be similar, but their gates are different.

4.1 Player View

The player view may return empty control, or prevent ordinary gameplay consumption, during warning screens, system UI, missing player information, missing player characters, or other forced states. It answers one question: can the current player submit gameplay control?

4.2 Camera View

The camera view has stricter gates. Camera-disable flags, weapon-wheel blocking, multiplayer frontend state, and script-camera ownership can disable camera input even while the player can continue to move or drive. Player control and camera control are therefore not one Boolean value. In-vehicle interaction, target lock, cutscenes, stunts, and script cameras can block ordinary view input while vehicle commands continue.

4.3 Frontend View

Frontend input should not be swallowed entirely by ordinary gameplay disabling. Pause menus and system UI still need confirmation, cancellation, and navigation. The frontend view therefore has its own gate policy.

4.4 Mapping Query View

The mapping-query view bypasses some gameplay gates so that settings screens, input icons, and script UI can inspect the actual binding relationship. It must not be mistaken for a vehicle-control source: being able to query a binding does not mean that the current context may submit a driving command.

5. Disabling and Exclusivity: Why “No Input” Does Not Mean “No Control”

Script control, pause states, weapon wheels, and special scenes often need to suppress selected inputs. The safer strategy is not to stop updating input values. The mapper continues to maintain device state, while disabling or exclusivity is applied at the consumption gate.

5.1 Continue Updating the Mapper to Avoid Stuck Input

If the mapper stops during a disable window, the device may change state while disabled. When input resumes, an old pressed state can be mistaken for a current one, producing a stuck key, persistent throttle, or a camera that cannot release. Updating the mapper and blocking consumption lets the input state return to the actual device state.

5.2 Global and Per-Input Disable Are Different

Global disable may have duration and merge rules. Per-input disable blocks one logical input. Related input groups may also need to be handled together, such as the positive and negative sides of one action or equivalent sources on a platform.

5.3 Exclusive Input Closes the Current Source

When an input becomes exclusive, the system closes the currently active related source before enabling the selected one. This explains why player, script, and UI sources cannot submit contradictory values to the same logical axis at the same time.

5.4 Zero Input Can Be a Valid Control

When the player does not move a stick, the vehicle still needs a valid control state for the current cycle. Zero input is not absence of control; it is a neutral value submitted by the current source. Whether the vehicle holds, recenters, or enters safe deceleration belongs to the vehicle executor.

This is also the P2/P3 boundary. P2 describes how input becomes a valid current source. P3 will describe how those values become a complete DriverCommand contract.

6. In-Vehicle Player State: The Upper Router Does Not Control Every Vehicle

After the player enters a vehicle, the character-side runtime enters an in-vehicle state. It maintains the relationship with the seat and switches between driving, in-vehicle interaction, seat changes, and exit.

The article calls this layer PlayerVehicleRouter. Its responsibility is to select and maintain an upper-level branch, not to calculate tire angle, aircraft roll, or rudder angle.

6.1 The In-Vehicle Baseline Comes from Player State

After entry, the router establishes an ordinary in-vehicle baseline so the character remains understood as being inside the vehicle. This baseline is not the vehicle executor. It answers character-side questions: is the character still inside, is the driver-seat relationship valid, and should the next branch be driving, interaction, or exit?

6.2 The Current Movement Context Selects the Player-Control Task

The player-control task is selected by the current movement context rather than fixed once at startup. Walking, vehicle movement, ladders, jumping, weapons, cover, and other contexts can select different player-control branches. Entering a vehicle changes the player branch to the in-vehicle driving router.

This is an organization in which the current movement state selects the input consumer. The global input layer does not hard-code “whenever the player has input, call a vehicle.”

6.3 Input Consumers Change with the In-Vehicle State

The router chooses among driving, in-vehicle interaction, seat changes, and exit. The same device axis can be consumed by the camera during driving and by another in-vehicle consumer in a different state. The mapping did not change; the current state changed who is allowed to consume it. Specific weapon and combat behavior belongs to P10.

7. From Player Side to Vehicle Side: The Bridge Selects, It Does Not Replace the Executor

After the router confirms that the local player is driving, it installs the driving path on the vehicle-side intelligence tree. This article calls that step VehicleControlBridge.

Its responsibilities are:

1. confirm that the character is the valid local player driver;
2. confirm that the vehicle is not a read-only clone;
3. select a type-specific player-driving executor;
4. install that executor in the vehicle intelligence tree;
5. reduce inappropriate time-slicing for the local player vehicle;
6. allow the executor to consume the current player-control view.

It should not collapse every vehicle into a generic automobile task, and it should not let the player router take over physics. The bridge is a responsibility boundary, not a universal controller.

7.1 Why the Player Vehicle Needs More Continuous Updates

Distant AI vehicles can use time slicing to reduce cost. A player vehicle must preserve continuity across input, camera, and feedback. If the player releases the brake for one cycle and accelerates again on the next, skipped vehicle updates should not become visible control latency.

The bridge therefore places the local player vehicle on a more direct execution path. This does not remove it from world scheduling; it means that the player-control window has a stricter continuity requirement.

8. Shared Lifecycle, Separate Motion Semantics

Vehicle-specific executors are not entirely independent implementations. The source structure reflects a shared player-vehicle driving contract, called VehicleDriveBase here. It fixes the lifecycle and control gates common to different vehicle types.

The shared contract covers:

• initialization when driving control begins;
• input consumption during normal updates;
• cleanup when driving control ends;
• inactive updates while input or the player is temporarily invalid;
• a no-driver state;
• installation and recovery of secondary vehicle tasks, such as a mode or shape change;
• maintenance of the exit action and driving state.

The shared part is lifecycle and ownership policy, not every control value. Automobiles, aircraft, and boats all need to know when control begins, ends, or loses its driver. They do not share the way lateral and longitudinal intention becomes motion.

9. Vehicle Compatibility: One Intention, Multiple Meanings

Vehicle compatibility does not mean that every vehicle calls one universal Drive(). It means that vehicles share a stable upper entry while type-specific executors interpret the same or related intentions.

9.1 Common Questions Across Vehicle Families

Every vehicle receives directional intention, intensity, discrete actions, and camera intention. The shared interface should express what the player wants, not the final motion quantity. For each vehicle family, ask three questions: what is shared, what is not shared, and why must a type-specific executor interpret it?

Vehicle family	Shared intention	Type-specific interpretation	State that must remain explicit
Automobile	Longitudinal, lateral, brake, exit	Steering, reverse, handbrake, secondary mechanisms	Speed, ground contact, braking state
Two-wheel vehicle	Longitudinal, lateral, brake	Lean, balance, sprint, airborne attitude	Lean angle, wheel contact, stability
Boat	Longitudinal, lateral, vertical	Propulsion, rudder, pitch, water state	Water surface, drift, out-of-water state
Submersible	Longitudinal, lateral, vertical	Depth, rise, dive, underwater attitude	Depth, immersion, exit conditions
Aircraft	Longitudinal, lateral, vertical, brake	Roll, pitch, yaw, thrust	Airspeed, altitude, flight phase
Rotorcraft	Attitude, altitude, yaw	Hover, lift, lateral movement, rotor attitude	Height, hover error, failure state
Train	Longitudinal, brake, direction	Traction, consist braking, track direction	Track position, consist, brake state
Transforming/amphibious	Basic direction, exit	Shape, mode change, cross-medium control	Form, medium, mode commit point

An automobile may turn lateral intention into tire steering; a two-wheel vehicle must also interpret lean and balance. A boat’s zero propulsion does not mean immediate stopping. An aircraft interprets lateral intention through airspeed and flight phase. A rotorcraft may enter hover or descent when input is released, while a train cannot accept free-space steering. They share entry and lifecycle, not motion interpretation.

9.2 Mode Changes Are Also Compatibility

An amphibious or transforming vehicle is not “simultaneously a car and a boat.” It is one vehicle identity with multiple movement modes. The shared lifecycle maintains the driving relationship. The type-specific executor stops the old mode’s submissions at a defined point, installs the new semantics, and preserves speed, driver, and necessary vehicle state. Compatibility therefore requires one active motion interpretation at a time.

10. The Actual Compatibility Pattern: Shared Contract, Separate Control Laws

Vehicle compatibility can be organized into four layers.

Layer 1: Common Player Intention

The control layer outputs stable logical intentions such as longitudinal, lateral, vertical, brake, exit, camera, and special-action intention. It does not decide whether those values mean throttle, rudder, elevator, or rotor thrust.

Layer 2: Common Driving Lifecycle

The shared contract defines when control is entered, updated, exited, suspended, or transferred to a no-driver state. It answers who owns the driving execution at a given point, not how the vehicle moves.

Layer 3: Type-Specific Semantics

The type-specific executor maps common intention to the automobile, two-wheel, boat, submersible, aircraft, rotorcraft, train, or transforming-vehicle semantics. Different parameters, curves, state machines, and physical seams are valid here.

Layer 4: Vehicle and Physics Feedback

After the executor submits control, the vehicle runtime and physics layer produce speed, attitude, collision, damage, or failure feedback. The next cycle can use that feedback when interpreting input. Compatibility is therefore a loop rather than a one-way conversion.

11. Compatibility Matrix: What Can Be Shared and What Must Stay Separate

The matrix makes compatibility concrete by separating common intention, specific interpretation, preserved state, and feedback.

11.1 Input Parameters Cannot Be Reduced to One Generic Float

If every input is reduced to MoveForward and MoveRight, the first prototype is simple but the second vehicle family quickly exposes the loss of meaning. At minimum, the contract must distinguish continuous values from discrete edges and held states.

Throttle, steering, lift, and camera movement are usually continuous. Exit, seat change, handbrake, landing gear, mode change, and weapon fire can be edge events or held states. Treating all of them as “is this frame’s value greater than zero?” loses the difference between press, hold, and release.

The contract also needs source validity, time continuity, and mode context. A player value can be disabled by the current view. A zero can be an intentional neutral value or a gate-produced zero. Aircraft, rotorcraft, and boats may depend on duration and previous state. A vertical axis can mean different things in a boat, submarine, aircraft, or helicopter. The type-specific executor should interpret that context rather than hiding it in the global input layer.

11.2 Compatibility Also Includes Rejection

An executor’s interface should describe not only what it accepts, but when it refuses or postpones an intention. A train can refuse free-space steering. A submersible can refuse depth control outside a valid underwater state. An aircraft can restrict attitude input before it enters a valid flight phase. An amphibious vehicle can defer control while changing modes.

Rejection is not an input-system error. It is the executor taking responsibility for the current vehicle state. If every field must be consumed, an invalid intention will be misinterpreted as motion and produce an impossible state.

11.3 A Shared Interface Must Preserve Type Differences

An automobile, boat, aircraft, rotorcraft, and train may all accept a forward intention, but they do not share the meaning of zero, failure, or invalid fields. Rejection is part of the vehicle-specific contract rather than an input-system error.

11.4 Diagnostics Must Preserve Vehicle Differences

A unified diagnostic surface can report which intentions were consumed, which fields were rejected, and what type-specific control was produced. The tool interface can be common; the diagnostic state cannot be reduced to “input received.”

12. Why There Should Not Be One Universal Player-Driving Task

A universal task appears to reduce class count, but it moves every vehicle difference into one conditional branch. That creates three problems.

First, state ownership becomes ambiguous. Handbrake, boat pitch, landing gear, and hover state appear in one object, making it difficult to tell which state is valid for the current vehicle. Second, intention semantics contaminate each other: one axis is steering in a car, roll in an aircraft, and depth control in a submarine. Third, failure recovery cannot be universal. Skid, stall, out-of-water motion, loss of hover, and loss of track are different failures.

The correct compatibility target is not the fewest classes. It is the most stable separation of responsibility.

13. Player Input and Camera: One Source, Different Consumers

Driving feel is not produced by vehicle motion alone. The camera must know when to follow the vehicle, when to allow free observation, and when a script or scene temporarily owns the view. It consumes vehicle state, but it is not a vehicle controller.

13.1 The Camera Has Its Own Control View

Third-person, first-person, in-vehicle, and stunt cameras can observe the same vehicle while using different response speeds, collision handling, fields of view, target points, and input ownership. The control layer therefore separates player control from camera control. Player commands may continue while camera input is blocked by a camera gate, script camera, or another upper-level state.

13.2 Script Cameras Sit Above Ordinary Camera Behavior

The source camera bridge can create, activate, switch, interpolate, attach, and hint camera requests, and can apply temporary follow, collision, or stunt overrides. It is a camera orchestration layer, not a vehicle controller. A mission can change what the player sees without rebuilding the vehicle executor, while the vehicle continues to run under its own state and constraints.

13.3 The Camera Feedback Chain

Speed, steering, collision, and attitude affect camera position, lag, shake, field of view, and target point. The camera organizes vehicle feedback into continuous player perception, but should not silently write back into vehicle state. Weapon-camera and replay-camera details belong to later articles.

14. A Complete Control Cycle: From Device State to Screen Feedback

Combining the preceding layers, one local player-driving cycle can be described as follows.

Stage 1: Device and System Input Update

The input-update process or a special loop obtains device state and updates control state, mappers, user settings, and scripted mappings. Mappers may continue updating even while a view is disabled so that state does not remain stale.

Stage 2: Control-View Gating

Player, camera, and frontend views independently determine whether input is available. Pause, script control, system UI, camera lock, and frontend state can affect different views in different ways.

Stage 3: Player In-Vehicle Routing

The player router confirms whether the current branch is driving, in-vehicle interaction, seat change, or exit. Only the driving branch submits the relevant intention to the vehicle bridge.

Stage 4: Vehicle-Type Dispatch

The bridge validates the local driver and vehicle entity, then selects the automobile, two-wheel, boat, submersible, aircraft, rotorcraft, train, or transforming-vehicle executor.

Stage 5: Type-Specific Interpretation

The executor interprets common intention as propulsion, steering, attitude, braking, depth, hover, flight control, or a special mechanism state.

Stage 6: Vehicle and Physics Update

The vehicle runtime sends the executor’s semantic control to the appropriate vehicle and physical seam, producing speed, attitude, collision, damage, and medium-specific state.

Stage 7: Camera and Presentation Preparation

The camera organizes the view using vehicle state, current camera ownership, and script overrides. Lighting, sound, HUD, and other presentation systems consume the resulting state.

Stage 8: Validation Continues on the Next Cycle

The next cycle cannot assume that the previous one remains valid. The player may exit, the vehicle may transform, input may be disabled, or the camera may be taken over. The current relationship must be checked again.

15. Input Failure, Mode Changes, and Recovery

The difficult part of compatibility is not the normal path. It is whether input still has a clear owner when it is interrupted, suspended, or restored. Vehicles may be hit, transformed, change medium, enter a scripted segment, change seats, or return to AI or distant simulation after the player exits.

15.1 An Interrupted Input Update Does Not Mean Vehicle State Is Zero

If the input-update process temporarily submits no new value, the executor must not blindly clear every state. It may need to hold braking, enter safe deceleration, preserve a flight-safety state, allow water inertia to decay, or keep an existing train traction state. The exact response belongs to the vehicle type.

The executor must distinguish “no new input arrived this cycle” from “the current source explicitly submitted neutral input.” The former can trigger a failure policy; the latter represents the player releasing control.

15.2 When Player Control Is Disabled, the Vehicle Still Needs a Valid State

A script scene or system UI may temporarily disable player input, but the vehicle cannot become an uninitialized entity. The runtime must retain the driver relationship, know whether the previous source is paused, know whether the vehicle task continues, and know whether the same executor can resume when input returns.

15.3 Mode Changes Need a Commit Boundary

When an amphibious vehicle changes from road to water mode, the old and new executors must not submit the same input simultaneously. The old mode stops submitting its no-longer-valid controls, the new mode confirms that it can consume the current intention, and vehicle and camera feedback switch together.

15.4 A Vehicle Mode Change Does Not Change Player Identity

Changing from surface mode to underwater mode changes the executor and the interpretation of input, not the player’s driver relationship. The character side retains the driver identity, the vehicle side retains the entity and seat relationship, and the bridge updates the active execution mode.

15.5 Different Failure Causes Need Different Recovery Ownership

Failure	Automobile	Boat/submersible	Aircraft/rotorcraft
Input temporarily disabled	Hold or safe deceleration	Preserve inertia and restrict new propulsion	Enter attitude or altitude protection
Driver temporarily invalid	No-driver state	Stop propulsion or wait	Safety or mission handoff
Mode transition	Pause old controls	Wait for medium confirmation	Wait for flight-mode confirmation
Motion state invalid	State-specific recovery	Check current medium and motion state	State-specific safety recovery
Player exits	AI, parking, or mission control	Mooring, AI, or distant state	Mission, distant state, or safe path

The purpose of this table is not to prescribe every recovery implementation. It identifies the requirement that rejection, suspension, and recovery must have explicit owners.

16. Information Passed to the Next Command Article

P2 does not define the complete DriverCommand structure, but it must preserve enough input semantics for P3:

• input source and source validity;
• current driver and seat relationship;
• vehicle type and current movement mode;
• continuous values, discrete edges, and held states;
• whether the current control view permits submission;
• whether the executor accepts, rejects, or defers the intention;
• the time or version associated with vehicle and physical feedback;
• whether another upper-level consumer temporarily occupies an input.

These fields are not an attempt to write P3 early. They prevent the command contract from collapsing into a few floats with no source, validity period, or mode context. A command is suitable for the vehicle execution layer only when it can explain who submitted it, for which vehicle and mode, whether it was accepted, and what feedback resulted.

16.1 P2 Is Not Complete Merely Because Every Vehicle Moves

P2 should not be judged by whether one automobile can move forward. The relevant checks are relational: can the player view produce input in the correct state, can the router select the driving branch, can the bridge reject an invalid clone or driverless entity, can the executor consume common intention while preserving its own state, and can the camera continue to provide consistent feedback after a mode change?

16.2 Do Not Mistake a Caller for an Owner

Reading player-driving code invites a common mistake: if a function reads input, it appears to own input; if it writes to a vehicle, it appears to own vehicle control. In practice, caller, bridge, and state owner may be different roles.

An input bridge may query or disable a value without owning the vehicle’s movement semantics. The player router may select driving or interaction without calculating tire angle or rotor lift. The vehicle bridge may install an executor without owning every vehicle difference. Motion interpretation belongs to the type-specific executor.

16.3 Minimal Compatibility Scenarios

To verify that vehicle families really share the correct entry, use scenarios that do not depend on complete physics. Let one player enter an automobile, boat, and aircraft; confirm that the input view is shared, dispatch differs, and each executor receives the same intention snapshot. Disable and restore player input; confirm that mapping state continues, inactive update runs, and driver and mode are revalidated. Switch an amphibious vehicle between modes; confirm that the old executor stops writing before the new one begins. Finally, enter and leave an in-vehicle interaction branch and confirm that camera and driving input relationships return without rebuilding the vehicle.

16.4 Debugging Should Display Relationships, Not Only Values

Displaying only the final float cannot show whether the failure occurred during device sampling, mapping, view gating, routing, type dispatch, or execution. A useful diagnostic snapshot should show the current input source, view validity, in-vehicle branch, vehicle type, movement mode, active executor, acceptance or rejection reason, previous-cycle state, and vehicle feedback.

17. The Most Important Counterexamples in P2

Counterexample 1: The Input Layer Writes Automobile Throttle Directly

This works quickly in a one-vehicle prototype, but bypasses authority, mission constraints, clone handling, and vehicle-type compatibility. It also blurs the boundary between camera feedback and vehicle state.

Counterexample 2: Every Vehicle Shares One Steering Value

Automobiles, boats, aircraft, rotorcraft, and trains may all accept a “left” intention, but their control quantities, motion constraints, and failure states differ. Intention can be shared; the control law cannot be forced into one value.

Counterexample 3: Stop Updating the Mapper When Input Is Disabled

On recovery, this can leave a stuck key, persistent throttle, or stale camera state. The source state should continue to update while consumption is blocked.

Counterexample 4: A Driver Seat Automatically Grants Every Input

Driver identity, command submission, camera input, and interaction input must be confirmed separately. A valid seat relationship is necessary, not sufficient, for every control relationship.

Counterexample 5: A Script Camera Becomes the Vehicle Controller

A script may own the view without owning vehicle motion. Camera orchestration and vehicle execution must communicate through explicit state or constraint relationships.

18. Migration Insight: Which Boundaries a Target Runtime Must Preserve

Migration is not about copying source class structure. It is about preserving the boundary between input intention, control authority, and motion interpretation. A target runtime needs an independent input service for sampling, mapping, disabling, and control views; a player-state router for driving, in-vehicle interaction, seat changes, and exit; a vehicle bridge for validating the current relationship and selecting a vehicle type; and type-specific executors for automobiles, boats, aircraft, and other vehicle families.

These responsibilities may be implemented by different classes, components, or subsystems, but they should not be collapsed into one universal driver. Shared elements are intention, lifecycle, and feedback entry points. Specific elements are motion interpretation, failure policy, and the physical seam. Preserving that separation allows a target runtime to support a small set of vehicles first without pushing every later difference back into the global input layer.

19. Source-Reading Conclusions

From the distribution of responsibilities, player-driving input is not a straight line from controller to vehicle. It is the result of four cooperating runtime layers.

The first is the system input layer, responsible for device state, mapping, disabling, exclusivity, feedback, and multiple control views.

The second is the player-state layer, responsible for deciding whether the character is in vehicle driving, in-vehicle interaction, seat change, exit, or another branch.

The third is the vehicle bridge, responsible for installing the local player-driving relationship on the vehicle intelligence tree and selecting the type-specific executor.

The fourth is the type-specific execution layer, responsible for interpreting common player intention as automobile, two-wheel, boat, submersible, aircraft, rotorcraft, train, or transforming-vehicle motion.

The camera does not occupy a final slot in those four layers. It is a parallel control-and-feedback chain with its own input view, ownership, and script overrides. It consumes vehicle state and returns the result to the player as perception.

P2 is therefore not about reading a throttle value. Its central question is: how can one player enter multiple vehicle-specific executors through a stable control entry without breaking the relationships among control authority, in-vehicle state, motion semantics, and camera feedback?

20. Interface to the Next Article

P2 explains where input comes from, who may submit it, how the current branch is selected, and how different vehicles interpret common intention. The next article tightens the next seam: how those intentions become an explicit driving command, how command arbitration and constraints are applied, and how the vehicle runtime receives a state that can be validated.

In short: P1 asks when the player becomes the driver; P2 asks when driving input belongs to the vehicle; P3 asks what command the vehicle actually receives.