Open world player vehicle driving P12: Network, replay, LOD and multi-vehicle continuation – how the vehicle continues to belong to the world after the player leaves

Previous article: Open World Player Vehicle Driving P11: Chase, Escape and Dynamic Control – How Missions Change the Driving Constraints of a Car

P11 examined how tasks change vehicle goal relationships, route interpretation, pursuit attitude and control constraints. P12 follows with a less visible question: how does a vehicle retain its identity, state and temporal continuity when the player leaves it, leaves the area, changes network authority or enters replay mode?

Introduction: The vehicle remains in the world after the player leaves

Imagine the player is driving a damaged car on a city road. The vehicle has just completed a chase. The right door is deformed and the steering ability of the front wheels is reduced. The mission is temporarily ended. The player gets out of the vehicle and enters a nearby building. A few minutes later, the player returns from another street: the car is still parked in the original area, the damage has not been unconditionally cleared, the seat relationship has been released, and the engine status, route relationship, and mission results have not covered each other.

What the player sees is that a car still exists. What needs to be maintained at runtime is a set of states across different time scales: entity identity, physical state, damage status, task results, network registration, streaming loading, perspective representation and playback records. They don’t update at the same frequency, nor are they owned by the same system, but together they must answer the same question: Is this still the same car?

If the system keeps complete vehicles only near the player, destroys an entity after it leaves that range, and regenerates a visually similar vehicle when the area is re-entered, world continuity develops an obvious gap: the vehicle may return to its initial position, damage may disappear, occupants may reappear, task relationships may reset, or network state may conflict with local observation. Conversely, running every vehicle at maximum accuracy at all times would quickly exceed the entity budget of an open world.

Therefore, the core question of P12 is not “how to keep the vehicle fully simulated forever”, but:

How can a vehicle retain a recognizable, recoverable and reconstructable identity while control rights, simulation accuracy, network authority and time sources change?

Network, replay and LOD can be understood along the same continuity thread. Networking handles the authority to commit and confirm state; replay handles how historical state can drive an entity again; LOD handles which information an entity retains at different viewing distances. None of the three directly replaces the vehicle runtime. Each changes how vehicle state is committed, reconstructed and represented.

1. Vehicle identity precedes performance accuracy

A car needs a stable identity anchor

A vehicle’s identity in the world cannot consist solely of its model, color, or current coordinates. Models can be replaced, vehicles can move into distant representations, physical entities can temporarily cease to exist, and locations can change due to network migration or recovery processes. What really needs to be persisted is the identity anchor that connects different points in time.

Several sets of interrelated fields with different responsibilities can be abstracted from the vehicle runtime and object registration materials:

• Entity identification: used to distinguish this vehicle from other vehicles in the world;
• Type and configuration: car model, appearance, modification, painting, additional parts and vehicle subtypes;

-Relationship status: driver, passenger, trailer relationship, task relationship and target relationship;

• Operating status: position, direction, speed, route phase, damage, capacity limitations and current control source;
• World state: network registration, loading level, visibility, perspective agent or replay ownership.

These fields are not necessarily implemented as a contiguous structure, nor are they necessarily held entirely by an object. The key is that when the entities are reconstructed, they must be able to regain the interpretable state of the same car.

Network object registration is not the vehicle behavior itself

The responsibility of the network object management layer is to map game entities to network objects, maintain object identification, type registration, search and registration capabilities. It is not responsible for substitute vehicle missions or deciding whether a vehicle should be pursued, stopped, or recovered.

From the perspective of source code responsibility distribution, the network object registration center, registration capacity management and vehicle local runtime belong to different layers: the vehicle continues to have its own routes, tasks, physical and behavioral states; the network layer is responsible for determining how these states enter the synchronizable object collection. The advantage of this approach is that the vehicle behavior does not need to know all the details of the network object table, and the network layer does not need to take over the driving decisions for each frame.

Online registration is therefore more like an identity portal. When a vehicle joins the network object collection, it needs to provide an identifiable type and life cycle; when the vehicle leaves, is destroyed, or enters a temporarily unsynchronizable state, the registration layer needs to clean up the corresponding relationship. Clearing the registration does not automatically equal clearing all world states of the vehicle unless the upper life cycle explicitly requires the entity to end.

What still needs to be retained after the vehicle leaves the field of view The information retained at different distances can be different, but all information cannot be reduced to “one position”. At least you need to keep:

• Ability to relocate entities’ identity information;
• Ability to reconstruct appearance and vehicle type configuration summaries;
• Mission and relationship summaries that explain why the vehicle is in its current state when the player returns;
• Version and time information that can be avoided from being repeatedly generated or incorrectly overwritten;
• A recovery portal that allows close entities to regain physical and mission control.

The perspective system can omit tire contact, door bones, and detailed suspension, but it cannot omit whether the vehicle has been damaged, is on a mission, or belongs to a player or network object. Representational precision can be reduced, but identity continuity cannot be lost.

The world takes over after the player leaves the car

P1 discussed how players establish a driving relationship, and P4 discussed how the source of control is handed over. P12 deals with the continuation of the world after the handover is completed: the player releases the right to submit commands, and the vehicle needs to find the next valid control entrance. Rather than repeating the handover decisions here, we illustrate how the results of the handover continue to be valid during the vision, network, and physical reconstruction process.

The vehicle departure process includes at least four different judgments: whether the seat relationship is released, whether the vehicle’s current mission is still valid, whether the original AI or script control can be restored, and whether the vehicle has entered a state that requires remote vision or network hosting. Compressing these judgments into Driver = null will lose the basis for recovery.

After the player leaves, the vehicle may enter several different outcomes:

• AI continues executing unfinished routes or tasks;
• Mission control vehicles enter waiting, parking or safety areas;
• The vehicle retains its current state, but does not submit to high-frequency motion control for the time being;
• Vehicle entry into the vision agent, maintained by a simplified runtime location and task summary;
• Network objects continue to exist, receiving or committing status from new authoritative locations;
• The vehicle mission has been completed and the entity enters the process of recycling or destruction.

These results depend on the collective judgment of the mission, vehicle, network, and world lifecycles. The action of leaving the car only releases the current player relationship and does not directly determine the final destination of the vehicle.

Recovery is not about returning to the moment before leaving the vehicle

After the player leaves, the vehicle may continue moving, suffer collisions, be modified by a mission, or cross a streaming level. Recovery therefore cannot simply roll the vehicle state back to the frame in which the player left.

A more reliable recovery process re-establishes a valid state: confirms that the entity still exists, reads the latest vehicle state, checks tasks and routes for expiration, selects available control sources, re-creates necessary local targets, and lets the actuators continue working from the current physical state. The vehicle retains identity and interpretable continuity rather than an old snapshot that is frozen.

Recovery must be interruptible again when the player re-approaches Players may re-enter after the vehicle reverts to AI control, or they may approach the vehicle while the network migration or LOD switch has not yet been completed. The recovery process cannot assume that it has permanent control, it needs to accept new takeover requests, task overrides and permission checks like a normal control source.

This means that there is a symmetrical relationship between off-car recovery and player takeover: the former releases the player command source and hands it to the world, and the latter obtains the current driving window from the world control source. Both must retain the original vehicle identity and cannot escape relationship migration by destroying and regenerating.

2. LOD is not deleted, but downgraded during runtime.

Multiple independent dimensions of LOD

LOD is more than just model level of detail in vehicle systems. It also affects budgets for physics, AI, routing, animation, audio, collision, network sync, and event reception. When a vehicle switches from a close view to a distant view, what really happens is a set of eligibility changes: which updates continue to execute, which updates are downgraded, which status is represented by a summary instead, and which events need to be deferred until the entity is reloaded.

LOD should not be compressed into a single axis from “close” to “far”. At least the following dimensions need to be observed separately:

• Representation level: full model, simplified model, distant proxy or invisible;
• Simulation levels: full physics and tasks, simplified movement, low-frequency abstract or pause;
• Residency status: loaded, loading, not loading or rebuilding;
• Network synchronization level: local authoritative, remote synchronization, low-frequency digest or not participating in synchronization.

“Inactive storage” is a lifecycle and resident state, not a presentation LOD. The above dimensions can be combined independently: the model is no longer visible, but the task summary may still be advanced; the full tire physics has been stopped, and the network identity may still be retained; the entity is loading, and resume requests must wait for resource and life cycle thresholds. This explains why different subsystems of the same vehicle do not have to switch in the same frame.

The core of LOD switching is state projection

From the complete state to the simplified state, high-precision information needs to be projected into a low-precision representation. For example, tire contact points can be compressed into vehicle speed, orientation, and road surface relationships; the skeletal states of multiple doors can be compressed into door damage and opening and closing summaries; and complete routes can be compressed into current road segments, target directions, and remaining distance intervals.

Projection is not a lossless copy, nor is it an arbitrary discard. Each omitted field must have a recovery strategy: restored by snapshot on reload, recalculated by the route service, reconverged by the physical system, or reconfirmed by the mission system. If a state is neither saved nor recomputed, there will be unexplained jumps after LOD switching.

The update frequency of vision vehicles can be reduced, but the life cycle cannot disappear Vision vehicles do not need full driving control every frame, but still need to handle task completion, route exhaustion, area migration, entity destruction and network status changes. Updates can be time-sliced, event-awakened, or batched, but the vehicle cannot logically stay at a point in the past.

This is also the specific meaning of “the vision vehicle still belongs to the world”: it does not have to move with the same precision, but it must continue to participate in state changes related to identity, mission and recovery.

Streaming loading determines when full entities can be restored When the vehicle re-enters the close-up view, the model, collisions, road nodes, attached entities and task dependencies may not have finished loading at the same time. Streaming systems need to distinguish between “the resource has been requested” and “the entity can participate in a complete update”.

While waiting, the vehicle can remain in agent status or use limited security updates. Only after the vehicle type, base collisions, necessary road space and current control sources have all passed the check should the full physics and vehicle tasks be taken over again. Otherwise, the route will point to a road that doesn’t yet exist, the physics will produce incorrect speeds in the absence of collision resources, and the mission may misjudge that the target has been reached.

Double entities need to be avoided for close-up recovery Streaming loading and network reconstruction may require the creation of the same vehicle at the same time. If the system only creates requests in the order they arrive, you will end up with two entities with the same appearance, similar location, and different object identities. Players may see the vehicle flashing, while the network layer may see repeated registrations.

Recovery requests must first query the identity table and the current lifecycle before deciding to reuse the existing entity, wait for the entity being created, or reject the repeated request. After creation, you need to bind the waiting routes, tasks and performance requests to the same runtime instance.

3. Network authority and vehicle status submission

Source of control does not equal network authority

Live vehicle commands can come from players, AI, scripts or recovery tasks; the network authority answers which entity, which node or which state version is eligible to submit and confirm results. Replay mode provides an independent source of time driving and state reconstruction; unless the source code explicitly records and re-injects driving commands, playback should not be treated as a normal driving control source by default. The two are related, but cannot be combined.

A local player may have input qualifications but not necessarily final confirmation of all network states; a remote entity may be driven by network states, but its local vehicle mission still requires interpretation of routes, seating, and physical feedback. The network layer should not cover all vehicle behavior through a global priority, but should provide submission qualifications, status versions, and conflict handling rules.

Registration, capacity and life cycle of network objects

Network object registration management usually needs to deal with object types, object identification, registration capacity, reservation and quantity thresholds. The responsibility of the population or capacity manager is not to generate traffic vehicles, but to determine whether the current set of network objects still has a registration and synchronization budget.

Such capacity boundaries affect whether a vehicle can enter the network state, but do not directly determine how the vehicle should be driven. Vehicle local tasks continue to maintain behavior; the network object manager maintains synchronizable identities; the two are connected through registration, release, and state submission interfaces.

Authority switch is not an instant replacement When a vehicle is transferred from one network node to another, the old node cannot just stop sending, nor can the new node just start writing from the next frame. Both ends need to go through stages such as request, confirmation, status freezing or incremental submission, authority taking effect, and old source release.

During the switch, vehicles may still be affected by local physics, mission events, or player input. The system needs to be clear about who will stage these changes, which changes can be committed early, and which changes must wait for confirmation by the new authority. Otherwise there will be issues with the same collision being applied to both ends, the route being rewritten back by the old node, or the player taking over but the network still retains the old AI control source.

Authoritative handoffs must also handle failures. Rejection of the target node, unloaded entity resources, lagging state versions, or broken connections can cause the migration to be stuck in an intermediate stage. At this time, the vehicle can maintain the old authority, enter the waiting state, or fall back to the safe proxy, but it cannot allow both the old and new nodes to think that they have the final submission right at the same time.

Prediction, Validation and Recycling Network status does not always arrive with complete physical results. Some states can be temporarily predicted locally and later corrected by the authoritative state; some events must wait for confirmation before the task can be advanced; some far-sighted states only need to save trends and be reconstructed by the authoritative entity when they are approached again.

The lifetime of prediction results needs to be limited. It must carry the source, starting version and validity time, and it must be replaced, merged or discarded after the confirmation result arrives. The vehicle cannot continue to use an expired speed, route, or control source upon recovery just because an old prediction still exists.

The authoritative state and the performance state can be temporarily out of sync It is usually impossible for the vehicle performance seen by the player to be completely consistent with the remote authority at the same moment. Network latency, interpolation, and local predictions can all create transient differences. The key is not to eliminate all differences, but to specify which differences can be smoothed by the presentation layer and which differences must immediately trigger a state correction.

Position and orientation are often allowed to be interpolated over a small range; tire contact and suspension can be reconverged based on current physics; mission completion, vehicle deletion, transfer of control, and severe damage are lifecycle facts that cannot be masked by visual smoothing alone. The presentation layer can hide short-term errors but cannot change state ownership.

Separation of authoritative status confirmation and local materialization conditions What the network authority confirms is whether a certain set of status facts is legal; when the local vehicle is running, it still needs to determine whether these facts can be materialized immediately. If resources, physics, or lifecycles are not yet ready, applications can be delayed, performance degraded, or resynchronization requested, but local old capability status alone cannot negate authoritative facts. If injury and sport status come from different authoritative fields, they should be merged by field ownership and version.

Status submission requires version and source Vehicle status submission requires at least knowledge of:

• Which entity’s state is this?
• Which authoritative source or simulation instance the status is generated from; if diagnosis is required, its original driving command source is attached;
• which time or sequence number it is based on;
• which fields it covers;
• Whether the recipient is still in the allowed application life cycle;
• If a conflict occurs, should it be rejected, merged, or deferred.

Without versioned state synchronization, it is easy for the old state to overwrite the new state. The vehicle has just completed player takeover, and the late AI state may be rewritten to the old route; the vehicle has just collided, and the old lossless snapshot may overwrite the damage facts; the vision agent has just completed migration, and the old node may still submit invalid positions.

Status sync is grouped by field ownership, update frequency and vehicle type Different fields have different ownership and update frequency. Entity position, speed, attitude, wheels, doors, lights, damage, modifications, seats, and mission status should not be unconditionally packaged into an undifferentiated snapshot.

A more appropriate approach is to group them by responsibility: base entity states provide identity and spatial location, vehicle-generic states provide motion and performance summaries, vehicle-specific states provide tires, rudders, rotors, flight parts or track relationships, and event states provide damage, weapons, tows and temporary interactions. When restoring, apply in dependency order to avoid applying fields that depend on entities or car models first.

4. Playback is not video recording, but another kind of time drive

Vehicle playback requires a dedicated adaptation boundary

The vehicle the playback system faces is not a simple location point. Vehicle creation, deletion, base updates, tires, doors, transformations, lights, audio, modifications and vehicle-specific states have different envelopes and update times. It can be observed in the source code material that the vehicle replay interface handles general vehicle updates separately from specialized data such as cars, motorcycles, boats, helicopters, aircraft, submarines, trailers and trains.

This represents an important boundary: the replay system is responsible for recording and reconstructing the vehicle facts in time, and the vehicle runtime is still responsible for understanding how these facts entered the current world. The Replay Adapter can create replay-owned vehicles, load models, restore appearances and states, handle seats and affiliations, but should not be understood as a substitute for ordinary driving tasks.

The creation package is the state anchor of the playback entity

Creation information in replays is often responsible for rebuilding anchor points: car type, initial transformation, livery, modifications, license plates, colors, alarms, player vehicle markings, etc. Subsequent updates will overlay speed, steering, throttle, braking, lights, alarms, damage, door and vehicle-specific data on this anchor point.

If the creation package is missing a car model or initial configuration, subsequent updates will not be interpreted correctly even if the complete location is recorded. On the contrary, if you only save the complete creation snapshot and do not save subsequent changes, the playback will only show a static vehicle.

Vehicle playback needs to distinguish between general data and vehicle-specific data Cars, two-wheelers, boats, helicopters, airplanes, submarines, trailers and trains share entity identities, underlying transformations and partial motion states, but their observable states are different:

• Cars need wheels, suspension, steering, doors and deformations;
• Two-wheeled vehicles require tilt, chain, pedal and wheel status;
• The ship needs feedback related to rudder, propeller, water surface state and buoyancy;
• Helicopters require rotor, lift, attitude and rope or mount status;
• The aircraft requires landing gear, engines, flight attitude and body parts status;
• Submarines require propulsion, rudder surface, depth and underwater status;
• Trains need track index, carriage relationship, speed and forward and reverse information.

What is shared is the playback life cycle and basic envelope, not the motion semantics of all vehicles. Playback systems therefore require dedicated adapters, but these adapters should still adhere to the same set of create, update, interpolate, delete and cleanup contracts.

Interpolation cannot create new world facts Playback often requires interpolation between previous and later data to avoid jumps in vehicle position, speed, and attitude. Interpolation is only responsible for generating continuous representations between recorded facts. It cannot treat the predicted position as a new task target, nor can it overwrite subsequent confirmed damage, deletion, or control source status.

Vehicle tire, door and deformation data may also be recorded differently: some fields hold the complete state, some record changes relative to a reference value, and some components are only written if the state is sufficiently meaningful. The purpose of this is not to reduce logical accuracy, but to allow high-frequency changes and low-frequency structural changes to use different data costs.

Forward and reverse playback require different state readings Reverse playback requires the system to be able to obtain the interpretable state at an earlier time point. If the update package only saves increments, keyframes, reversible increments, or other reconstruction anchors are needed; if complete samples are saved, evaluations can be performed directly between adjacent samples. The specific method depends on the playback package structure and calling path. The vehicle creation package therefore cannot only play the role of “birth data”, it may also serve as a reconstruction anchor point after deletion, saving enough information to return the entity to an interpretable previous state.

Tires, doors, deformation and other states cannot all use the same fallback method. Tires may need to recover contact and compression from adjacent samples, car doors may need to be interpolated based on the state of the front and rear doors, and damaged bones may need to retain their last valid deformation until a new sample confirms the change in state. Reverse playback does not simply reduce the time by one, but reads the corresponding historical facts according to the recording granularity of each state family.

Deletion and reconstruction need to know each other If you only record “deletion occurrence” when playing back a deleted package, you will not know what state it should be reconstructed from when playing it back. On the contrary, if the deletion information retains the creation frame, entity ownership, and previous creation status, the playback entity can be re-created when the playback cursor returns, and subsequent forward updates can be applied.

This is why the playback deletion process usually requires first processing the occupants, trailers and attachments, then deregistering the world, and finally destroying the vehicle object. The deletion action itself is a fact on the timeline and cannot be treated as an ordinary object release operation.

5. Entity reconstruction and world state restoration

The reconstruction order determines whether the state is interpretable

When a vehicle re-enters the full world due to network migration, replay creation, streaming loading, or vista restoration, the rebuild cannot just set a Transform. For migration and verification, the process can be organized as:

1. Confirm the entity identification, vehicle model and life cycle ownership;
2. Create or obtain the corresponding vehicle runtime instance;
3. Restore basic transformation, speed and posture;
4. Apply appearance, modification, painting and additional configurations;
5. Restore the relationship between seats, trailers, tasks and control sources;
6. Apply damage, door, wheel and vehicle-specific status;
7. Reacquire routes, local goals and execution qualifications based on current world conditions;
8. Let the physics and presentation layers continue to converge from their restored state.

Failure in any of these steps should not result in a silently generated vehicle that “looks correct”. The system needs to record missing items and decide whether to delay activation, downgrade to a vision agent, enter a safe state, or end the entity’s life cycle.

Clone re-creates a runnable entity using identity, type and state envelopes

Cloning in a network or replay usually means recreating a runnable entity based on its identity, type, and state envelope, rather than copying the memory address of the original object. The new entity must be re-registered into the current world, re-establishing tasks, seats, control sources, physics and presentation layer relationships.

Therefore, the cloning process should distinguish three categories of data: facts that can be restored directly, relationships that must be revalidated against the current world, and runtime results that can only be recomputed. The vehicle’s current position may come directly from the snapshot; seat permissions may need to be re-confirmed; tire contacts and local routes may need to be recalculated by physics and routing services.

The first frame after reconstruction is not a normal update frame The newly restored vehicle may be missing complete neighbor entities, road collisions, physics constraints, or presentation resources. The first frame needs to perform additional readiness checks to prevent tasks from immediately consuming a state that has not yet been fully established.

For example, the vehicle has restored the target relationship, but the target entity has not yet been loaded; the vehicle has restored the route, but the current road node is not yet available; the vehicle has restored damage, but the corresponding execution capability restrictions have not yet been applied. A more reasonable behavior at this time is to suspend the commit, maintain a safe state, or wait for the dependency to complete, rather than executing the old command directly.

Recovery of basic space state. Position and orientation may seem like the easiest fields to restore, but actually also require context. The positions in the snapshot may come from the physical world, a network authority, a distant proxy, or a replay sample; their coordinate systems, time points, and collision conditions may be different. Restoration requires confirmation of whether the position is still in the available world area, whether the orientation is compatible with the vehicle type and route relationship, whether the speed can be applied directly, or whether it should wait for physics to reconverge.

For cars, speed and orientation can be used as physical initial conditions; for trains, position must also be mapped to track and carriage relationships; for airplanes and helicopters, attitude and height must simultaneously meet the conditions of flight mode; for boats, water surface, buoyancy and heading dependencies cannot be replaced by a plane coordinate. The base space state becomes an executable initial state only after it passes type and world condition checks.

Restoration of task status. The task status cannot only restore “current task name”. Tasks also require target entities, route versions, local goals, task phases, pause reasons, control sources, and end conditions. A chase mission may still be active after the player leaves the car; a navigation mission may have been completed during the vista; an in-car interactive mission may end or wait due to seat release.

When restoring, you should first confirm whether the task still belongs to the current vehicle, then confirm whether the target and route are valid, and finally reselect the executable stage of the task. If reconstructed based only on the mission name, the system might restart a chase that has already been completed, or allow the vehicle to continue along the old route toward a target that has expired.

Recovery of damage and ability status. Damage conditions have at least two levels: observable component consequences and limitations on operating capabilities. Dented doors, broken glass and body deformation mainly affect performance; tire failure, restricted steering, engine failure and damage to propulsion components will change the vehicle’s qualifications. The two cannot be uniformly squashed into a health percentage just because they enter the vista.

When restoring a complete entity, the presentation layer can reconstruct the appearance based on the damage summary, the actuator needs to read the capability constraints, and the physical layer can establish a new runnable state based on the current contact conditions. This way, the vehicle can continue to exist from a “still able to move but with limited steering” state, rather than suddenly reverting to a damageless vehicle upon reloading.

Resumption of seat and affiliation. Seat relationship, passenger relationship and towing relationship need to be reconfirmed after the entity is restored. The saved relationships may point to entities that have been deleted, or to new objects that have been reconstructed by network nodes. The recovery process needs to check the relationship version, the identities of both parties, and the current permissions before deciding to rebuild, wait, or release the relationship.

Crew rebinding may also affect mission and weapon status. After an occupant leaves the vehicle, the in-vehicle weapon task cannot continue to reference the old seat; after a trailer parent entity is restored, the child entity must re-confirm the hitch point and direction; when a player re-enters the vehicle, the driving relationship of P1 needs to be re-established on the current restoration result instead of reusing the old seat pointer.

Recovery of performance status. Lights, alarms, doors, windows, audio, stains, and special effects can be restored at a lower priority than the core running state, but they still affect the player’s ability to determine whether the vehicle is the same vehicle. Performance state can be applied lazily and cannot be lost indefinitely.

During network or streaming loading, the vehicle might restore identity and mission first, then model and sound; during playback, the vehicle might create base entities and then gradually apply wheels, doors, and deformation data. As long as the presentation layer is clear about its delayed status and fills it in when resources are available, “not yet loaded” will not be misjudged as “status does not exist”.

Time and events after leaving the field of vision

LOW FREQUENCY UPDATES STILL REQUIRE CHRONOLOGICAL SEQUENCE LOD and network migrations will reduce update frequency, but vehicle events will still be sequential. Damage occurs before the player leaves the vehicle, mission completion occurs after the damage, and route failure occurs before the mission is completed. These relationships determine what state the vehicle should be in when it reappears.

If the Vision system only saves the last position, it won’t be able to tell what happened during reloading. The solution could be to save event summaries, state versions, or limited timelines, rather than requiring distant entities to run full physics forever.

The difference between event summary and full playback

World continuation does not require that each vision vehicle record its complete frame-by-frame history. Ordinary traffic vehicles can only retain route stages, location trends, and mission summaries; important mission vehicles may need to retain damage, target relationships, control source changes, and key events; the playback system needs to save higher-precision vehicle data based on the lens and recording range.

All three share the goal of “state continuity” but have different budgets. All world entities cannot be required with replay precision, nor can a normal vista summary be used in place of a mission vehicle being observed by the player.

Critical entities require longer state retention windows. Ordinary traffic vehicles can quickly compress their status after leaving the observation range; mission vehicles, vehicles recently used by players and vehicles that are still bound to mission relationships usually require longer retention windows. They may continue to affect the outcome of the mission after the player leaves, or they may reenter the camera for a short period of time.

The retention window should not be determined by distance alone, but also needs to take into account entity importance, current mission, damage, source of control, network participation status, and recent player interactions. A long-shot vehicle in a pursuit mission, even if it temporarily leaves the camera, cannot be treated as a minimal summary of an ordinary traffic vehicle.

Event summary needs to be retained with reason. “Vehicle stopped moving” can result from parking, mission waiting, physical stuck, network freeze, vision time slice pause, or damage out of control. If the summary only records a speed of zero, the correct recovery task cannot be selected when reloading.

Therefore, the summary needs to preserve the cause or status category of the results. For example, the wait state allows the task to continue observing the target, the physical loss needs to enter recovery, the network freeze needs to wait for authoritative updates, and the entity pause needs to re-examine the surrounding world when recovering. Identical values ​​do not have the same runtime meaning.

Late events must have a lifetime threshold. Target relationships, damage events, network snapshots and replay packages may all be late. The receiver needs to check whether the entity still exists, whether the event source is still valid, whether the version is out of date, and whether the event is applicable to the current LOD and control source.

Rejection of late events does not mean that the system has lost information, but rather that it has crossed the current life cycle boundary. The log needs to record the reason for rejection in order to distinguish between “the event has not arrived” and “the event has arrived but no longer has the right to change the status”.

6. Multi-vehicle continuation: shared identity, not shared motion semantics

Vehicle type affects reconstruction content

A multi-vehicle system cannot use just one unified snapshot. The tires and doors of a car, the buoyancy and rudder of a boat, the attitude and landing gear of an airplane, the rotor and ropes of a helicopter, the track and carriage relationships of a train all determine what special data is needed for entity recovery.

The shared layer can be responsible for entity identity, life cycle, basic transformation, control source, network registration and playback sequence; the vehicle-specific layer is responsible for explaining its own motion status and affiliation. In this way, the recovery process can be consistent and the specific data still follow the respective motion semantics.

Trailers, carriages and attachments need to be dealt with independently. Trailers, train cars, suspension objects, and crew relationships are not subsidiary fields of a single vehicle Transform. They have their own entity identity, connection order, parent-child relationship, and deletion conditions.

When restoring a vehicle, you must first confirm whether the subsidiary entity exists, whether the connection relationship is still valid, and whether the parent entity has been rebuilt. Otherwise, there will be problems such as the vehicle is displayed but the towing direction is wrong, the car is detached, the passenger coordinates are invalid, or the network object is repeatedly registered.

Bottom line for multi-vehicle compatibility. P2 discusses shared input contracts and P8 discusses type-specific executors. P12 continues to use the same boundaries: the lifecycle and recovery protocols are shared, not the status fields of all vehicles.

Whenever a system attempts to compress cars, boats, planes, and trains into the same set of “position, speed, direction” fields, recovery loses vehicle semantics. The unified interface should describe the stages of creation, update, verification, downgrade, recovery and cleanup; the vehicle type then supplements the actual state through dedicated extensions.

Type extensions also need to handle missingness and degradation. Vehicle-specific status does not necessarily exist at every point in time. A vision summary may have no tire contact, a network snapshot may temporarily have no ship rudder details, a playback sample may only record the base attitude of the aircraft, or a train car relationship may wait for the track entities to finish loading.

Therefore, specialized extensions need to declare whether the state exists, whether it has expired, and whether it can be recomputed by the current runtime. Suspension contact can be re-established when a car lacks tire details; an airplane may only enter a safe attitude when it lacks landing gear; and a train cannot directly claim that the complete train has been restored when it lacks car connections. Missing states should go into an explicit degradation path, rather than being silently filled in with default values.

Identity of ancillary entities cannot rely on spatial proximity Trailers, carriages, suspended objects, and occupants may appear in similar locations during recovery, but spatial proximity does not prove that they belong to the same group. Rebuilding requires the parent entity ID, subordinate index, join version, and relationship validity period.

If you only look for attached objects based on distance, multiple trains, trailers, or vehicles appearing at the same time will be incorrectly bound to each other. Relationship restoration must first confirm identity and then apply spatial correction; spatial location can only be used as a verification condition and cannot be used as the sole basis for attribution.

7. Responsibility boundaries and final abstraction in source code reading

Vehicle Runtime, Factory and Storage

It can be observed from the vehicle core material that the continuous operation entrance, vehicle factory and storage recovery of a single vehicle do not share the same responsibility. The vehicle instance maintains its own control, intelligence, and physical processing; the factory is responsible for type assignment, creation, registration, and entry into the world; and the storage auxiliary is responsible for the snapshot and recovery of the reconstructable state.

This provides an important judgment for P12: Network, playback and LOD need to call the life cycle entry of the vehicle runtime, but the vehicle instance should not be transformed into a pure data container. The vehicle is still a live runtime entity, and external systems simply change its visibility, how state is committed, or when it is rebuilt.

Network object management and world layer boundaries. The Network Object Manager maintains network object registration, types, and lookups; the Capacity and Reservation Manager maintains registration thresholds, object quantities, and bandwidth targets; the world and script layers can trigger registration or cleanup, but do not replace the Network Registration Center.

This boundary means that “network object exists” and “vehicle task is executing” can be temporarily out of sync. The system needs a clear intermediate state to handle registration delays, permission transfers, remote agents, and rebuild waits, rather than forcing all layers to complete changes in the same frame.

Playback vehicle interface with dedicated envelopes. The playback vehicle adapter can be abstracted as a layer of time data interface. It is responsible for vehicle creation, basic update, deletion, recording and application of tires, doors, deformation, lights and vehicle-specific data, and enters the current scene through vehicle factory and world registration.

The existence of this type of adapter does not mean that playback becomes the vehicle’s new permanent controller. It is only time-driven in certain playback modes and needs to adhere to the lifecycle contract of creation, interpolation, deletion and cleanup.

The same vehicle may have multiple observers at the same time. A vehicle in the open world may be observed by players, network nodes, mission systems, replay cameras and distant agents at the same time. Different observers do not necessarily need the same information, nor do they necessarily have permission to modify it.

Players need to see the vehicle’s current perceived speed, steering, damage, and interaction status; network nodes need to confirm synchronizable entity facts; playback cameras need continuous time sampling; and distant agents need only a summary sufficient to maintain route, identity, and task relationships. They both reference the same car, but each consumes a different state projection.

Therefore, state projection should not be designed as a “low-precision version” of a one-way path. It is closer to the different views provided to multiple observers from the vehicle’s runtime: the full close-range entity is usually a highly accurate runtime representation of the vehicle’s state, but does not need to be the state authoritative in all modes. The current authority may come from a local simulation, a remote network node, a replay timeline, or a distant simulation; the recovery process is responsible for rematerializing the currently valid facts into a complete vehicle runtime.

This relationship can be abstracted as:

*Figure 11: Logical identities pass through state authorities and field-level state facts, and are ultimately projected into the current runtime representation. *

The “same vehicle identity” mentioned in this article means that different systems can be mapped back to the same logical world entity. It does not mean that the network, playback, runtime, and vision agents must share the same numerical ID or object pointer.

State sources need to be layered instead of covering each other

When multiple systems provide vehicle status simultaneously, the most dangerous approach is to override in order of arrival. Correct judgment needs to consider at least the state source, version, time, field ownership and current life cycle.

For example, a network snapshot can update the vehicle position, but it should not clear the local confirmed damage; the replay data can drive the attitude in the movie, but should not change the task relationship in the ordinary game; the perspective agent can provide the approximate position of the vehicle, but should not overwrite the driving control just submitted by the player; the task result can end the route, but cannot directly erase the physical collision facts.

State merging therefore requires field-level semantics. Base transformations, control sources, mission phases, and damage states may be maintained separately by different systems. The role of the merger is not to select a “latest big snapshot”, but to apply legal changes according to the ownership and version of each set of state.

Deletion is also a state change When a vehicle is removed from the world, the deletion event cannot only be understood as releasing memory. It could mean mission completion, network logout, replay deletion, vista state cleanup, player vehicle replacement, or world reset. Different reasons determine whether to retain snapshots, whether to notify seat relationships, whether to clean up trailers and passengers, and whether to release network objects.

Therefore, deletion needs to carry the source and reason. A temporary deletion from playback should not accidentally damage ordinary world vehicles; a destruction from task completion should not allow the vision agent to be regenerated at the next load; network logout requires confirmation of whether the current node still has the right to delete.

Timeline and version in state continuation

The timeline is not a single clock. When the vehicle is running, it will be exposed to at least several times: physical update time, task update time, network submission time, playback time and perspective simulation time. They may advance at different frequencies, or may be temporarily detached during pauses, loads, replay rewinds, or network delays.

Therefore, the vehicle status cannot only take a “current time”. The state record needs to state what kind of time it is advanced by, which sequence it belongs to, whether interpolation is allowed, and how to establish a new baseline when switching time sources.

Vehicles in the normal game may advance by world time; vehicles in replay may advance by the replay cursor; network entities may advance by received server status and local predictions; and vision agents may advance by time slices. They all need to be converted back to a state stage that the vehicle can understand, rather than directly treating their respective timestamps as physical time.

version is used to prevent incorrect overrides. Version is not a concept exclusive to network systems. Route requests have versions, target relationships have versions, control sources have versions, damage and task results can also have versions. Whenever a result may be late, the receiver needs to know whether it still belongs to the current lifetime.

When the vehicle changes from a close view to a long view, the distant view summary should carry the entity version when it was generated; when reloading, if the entity has experienced new collisions or task transitions, the old summary can only be used as a historical reference and cannot directly overwrite the new state.

The sequence of events is more important than the individual results. Player disembarkation, vehicle damage, mission completion, network migration, and entity uninstallation may occur consecutively within a short period of time. The same final state does not mean that the intermediate process can be ignored.

For example, the player leaves the vehicle first, then the vehicle takes damage, and finally enters the distant agent. The vision summary needs to record that player relationships have been released, damage has been confirmed, and entities still exist. If the system only saves the last “far vehicle” marker, there’s no way to know if it should restore the AI, limit speed, or trigger a mission outcome when returning to the closer view.

Common boundaries between network, playback and LOD

All three consume vehicle status, but for different purposes The network cares about how the state is submitted and confirmed; the playback cares about how the state is recorded and reconstructed over time; the LOD cares about how the state is represented and restored at different costs. All three require the identity and life cycle of the vehicle, but they should not share the same set of responsibilities.

Three questions can be used to distinguish them:

• Network: Who is qualified for other nodes to accept this change?
• Playback: To what time position does this change belong, and how does it behave between previous and later samples?
• LOD: What information must be retained given the current observation and budget conditions?

If the three are combined into a “synchronization manager”, there will be problems with network status being overwritten by replay time, vision summaries being treated as authoritative snapshots, or replays saving excessive data for each unimportant entity.

Common use of lifecycle thresholds Although the responsibilities are different, all three need to check whether the vehicle has been created, whether it still belongs to the current world, whether updates are allowed, whether sufficient type information exists, and whether it is safe to proceed to the next stage.

Such thresholds can explain many seemingly incidental problems: replay updates precede model creation, vista restoration precedes road data loading, network state registers precedes entity registration, or damage events arrive later than vehicle deletion. The system does not simply throw the event to the downstream, but first determines whether the current life cycle allows it to be consumed.

Common use of cleanup protocols Create, update and delete must form a symmetric protocol. Network objects, playback extensions, physical entities, seating relationships, drag-and-drop relationships, and presentation resources registered at creation time all require clear cleanup actions when the entities end or switch ownership.

The cleanup order also affects the results. Deleting the vehicle first and then clearing the occupants may leave invalid seat references; releasing the network object first and then processing the attached entities may turn the trailer into an orphan object; closing the playback extension first and then deleting the dedicated data may prevent the deletion package from finding the corresponding entity. P12 continuity occurs not only during the creation and run phases, but also during the exit phase.

8. Continuity failure, recovery export and verification

Regenerate the default vehicle after the player leaves the vehicle

On the surface, the vehicle is destroyed after the player leaves the vehicle, and the system generates a vehicle of the same model when returning. Visually, the replacement seems to be completed. Vehicle identity, damage, mission phases, route relationships, seat relationships, and network objects are actually lost. Players will think the world has lost memory of this car.

A more robust approach is to retain entity digests or rebuildable snapshots. Even if the vehicle temporarily does not exist as a full Actor, it should retain enough state to explain its next recovery.

Network late status overrides player control. The player has just taken over the vehicle and the status package for the old AI node has just arrived. If the receiver only compares arrival times, the old route and old control source will be revalidated. Vehicles may experience brief direction reversals, route jumps, or player input failure.

The solution is to make the state submission carry the control source version and the entity life cycle version. Even if the status of the old source arrives late, it cannot override the completed control transfer.

LOD toggle clears damage and ability limitations. After the vehicle is damaged and enters the distant view, the distant view agent only saves the location and model. When the vehicle reenters close-up view, the complete entity is created with default capabilities, and steering, braking, and appearance return to normal. Although such an implementation saves vision costs, it destroys the facts of the world that the player has just established.

At a minimum, the vision summary needs to preserve the state that affects the mission, eligibility for execution, and player perception. Tire contact details can be recalculated, and whether the vehicle has lost steering ability cannot be lost silently.

Replay interpolation covers real events. The replay cursor is playing old frames and the vehicle receives a new damage or deletion event at the same time. If the playback adapter does not differentiate between time sources, the interpolation results may redisplay the vehicle as lossless, or even allow deleted vehicles to continue to appear in the shot.

The playback mode needs to clarify who is the source of the current state driver, as well as which events belong to the playback track and which events must block the playback application. Interpolation can only serve the currently active timeline.

The final abstraction obtained from reading the source code

Persistent Entities, Variable Representation and Restoration Entrance By integrating vehicle runtime, network objects, playback vehicle adapters and world state management materials, the structure of P12 can be abstracted into three layers:

• Persistent entity layer: maintains vehicle identity, type, life cycle and key relationships;
• Variable presentation layer: Provides full entities, simplified entities or vision summaries based on player distance, network mode, replay mode and budget;
• Restoration entry layer: Re-validate state and restore vehicle operation upon representation switching, control transfer, network rebuilding and replay creation.

These three layers do not require the existence of three fixed classes in the source code, but a summary of the responsibilities of creation, update, registration, snapshot, cleanup and reconstruction. The article uses them to illustrate how state moves between different runtimes.

Who creates, who registers, who updates, who cleans up. When reading this type of source code, the more reliable questions than class names are: who creates the entity, who registers the entity into the world, who owns the running entry for each frame, who provides state snapshots, who restores when switching, and who cleans up relationships when deleted.

The vehicle factory may be responsible for creation and type dispatch, the vehicle instance is responsible for continuous operation, the network object manager is responsible for network registration, the playback adapter is responsible for time data, the streaming system is responsible for resource loading, the task system is responsible for goals and routes, and the final cleanup needs to be completed collaboratively across these boundaries.

If all issues are assigned to a “vehicle manager” it usually means the title has not been taken apart. The value of P12 is not in proposing a larger manager, but in identifying which states must be continuous across layers and which states should be maintained by dedicated systems.

Check ownership using three paths: create, update, and delete. When reading the source code related to vehicle continuation, you can put each system back into the three paths for inspection. The creation path answers where entities come from, who selects car models, and when world and network objects are registered; the update path answers who writes locations, tasks, physics, and representations; the deletion path answers which relationships are released first, which snapshots are retained, and which registrations are eventually cleared.

If a system only appears in the update path without explicit creation and deletion entries, it may be a state consumer rather than an entity owner. If a system is able to create vehicles but does not handle dependencies and network logouts, it is closer to a factory or adapter than a full runtime. This approach prevents misinterpretation of a similarly named packaging layer as an entire vehicle system.

Focus on call edges across files rather than isolated class names. Vehicle networking and playback code often spans vehicle, world, script, streaming and render directories. Reading a class in isolation, it is easy to mistake a local cache, adapter or wrapper for the global owner. A more reliable approach would be to record who created it, who handed it results, who consumed its output, and who was responsible for cleaning up when exiting.

For example, the playback vehicle adapter can save special packages, but model creation still needs to go through the vehicle factory; the network object manager can register objects, but vehicle tasks still run in vehicle instances; the streaming system can load models, but cannot determine damage and task relationships. Calling edges across files tells more about actual responsibilities than class names.

Retain the stage during migration and do not copy the source code structure. If you migrate this mechanism to another engine, the most important thing is not to copy the class hierarchy of the network object manager, the playback interface, or the vehicle factory, but to keep several stages: entity creation and registration, state snapshot, state projection, control source confirmation, dedicated state application, physical ready, performance ready, and delete cleanup.

The engine can use its own world subsystem, object handles, network components, and resource asynchronous loading methods, but it cannot compress all stages into a single generation function. As long as the lifecycle stages remain clear, the underlying class names can change; if stages are merged, subsequent network migrations, LOD switches, and playback rebuilds will all lack verifiable seams.

Mechanistic conclusion of P12. From GTA5 vehicles, networks and replay materials, four conclusions can be abstracted relatively stably:

1. The vehicle instance is a continuously running entity, not a display object that only stores the location;
2. Network registration, playback adaptation, and LOD representation all work around the same entity identity but do not have the same behavioral responsibilities;
3. State reconstruction must distinguish between facts, relationships and runtime calculation results;
4. Deletion, downgrade and migration require clear version, source and recovery exit.

These four conclusions connect the content from P1 to P11 to the world continuation layer: the seat relationship needs to be reconstructed, the control source needs to be reconfirmed, the route and mission need to be restored, the physics and damage need to be preserved, and the in-car interaction and chase results also need to have a clear end state.

P1-P11 state processing in world continuation The following table is an architectural abstraction of the previous state, not a fixed field table in the source code. What it does is distinguish which relationships must be persisted and which results should be recomputed on recovery:

Previous-series state	P12 handling
P1 Seat relationships	Preserve identity references; revalidate both entities and permissions during restoration.
P2 Input and control views	Do not persist them as world state; rebind them when the player approaches again.
P3 Driving commands	Expire old commands instead of restoring them directly; form new commands from the current goal.
P4 Control sources	Preserve source relationships and versions; re-arbitrate submission eligibility during restoration.
P5 Routes	Preserve route summaries and goal relationships; validate or replan during restoration.
P6 Policy	Preserve stable driver configuration and task overrides; recompute policy query results.
P7 Local avoidance	Do not preserve stale candidates; recompute from the current spatial relationships.
P8 Control and physics feedback	Clear old control requests, restore transform and velocity, then converge again.
P9 Damage	Preserve critical component states and capability restrictions.
P10 In-vehicle interaction	Preserve required seat, weapon, and mode state; clear expired fire requests.
P11 Chase	Preserve target relationships, pursuit state, and termination reason; revalidate the target and route during restoration.

This table also delineates the boundaries of P12’s responsibilities: world continuation is responsible for saving and revalidating state, and is not responsible for alternative inputs, strategies, avoidance, or the executors themselves.

Failure handling: Continuity must have an interpretable exit

Network registration failed. If the vehicle has been created but the network object registration failed, the system cannot directly assume that the network status exists. It can remain running locally, await registration, be demoted to a non-network entity, or end the entity based on task rules. Which path is chosen depends on whether the vehicle is mission critical, the current network mode, and the world lifecycle.

Vision recovery failed. The vision agent may be missing vehicle model resources, road nodes, target entities, or physical dependencies. When recovery fails, the system needs to explicitly retain the agent, delay rebuilding, enter a safe state, or clear the entity, rather than generating a default vehicle that lacks damage and mission relationships.

Replay creation failed. Replaying the vehicle may fail because the model has not been loaded, the creation budget is insufficient, affiliations are missing, or the dedicated envelope cannot be applied. The playback system should record the failure stage and allow subsequent packets to be rejected or delayed; entities that have not completed creation should not be allowed to continue to consume subsequent updates.

LOD switches repeatedly. The vehicle repeatedly enters and exits the close-up view near the observation boundary, which will cause repeated creation, status jitter and repeated installation of tasks. Hysteresis, minimum dwell time, request sequence numbers, and explicit transition status are needed to ensure that a switch is not interrupted by the next opposite request before it is completed.

Recovery check should cover four types of results A recovery check must at least distinguish: complete recovery, partial recovery, waiting for recovery and non-recoverable. Complete recovery means that the identity, resources, relationships, physics, and tasks are all available; partial recovery means that the entity can be displayed or run at low frequency, but there are still dependencies that are not completed; waiting for recovery means that the system still retains the entity, only waiting for resources, authority, or affiliation; unrecoverable means that the reason needs to be recorded and the entity needs to be ended or transferred.

This classification is more informative than a Ready flag. The task can decide whether to allow partial recovery, the network can decide whether to keep the object, the presentation layer can decide whether to display a proxy, and the vehicle actuator only submits motion requests when its own conditions are met.

How does player experience verify world continuity?

Leaving and Returning Verify that the player leaves the vehicle after driving, waits for the vehicle to enter AI, vision or network hosting state, and then returns from a different direction. Check vehicle identity, position trends, damage, mission results, seating relationships and route status for reasonableness.

Network authority conversion. Verify that the entity transitions from local control to remote state and then back to local observation. Check whether the status submitted by the old node was rejected, whether the new authority is able to rebuild the vehicle, and whether the control window can be re-established when the player re-approaches.

Replay creation and deletion. Validates creation, update, interpolation, deletion and affiliation of cars, two-wheelers, boats, planes, helicopters, submarines, trailers and trains. The point is not whether the picture is complete, but whether the status is restored in the order of creation package, general update package and special package.

LOD boundaries. Verify vehicle switches between close, medium, long and reload. Observe the vehicle for teleportation, damage clearing, mission reset, seat duplication, control source loss, or model and status mismatch.

Record evidence of status for continuity testing. This type of test cannot only capture the scene after the vehicle reappears. Entity identification, status version, current control source, mission stage, route version, network registration, LOD level and recovery results need to be recorded simultaneously. Only by putting the states before and after restoration on the same timeline can we judge whether the vehicle has been correctly continued or whether a replacement entity with a similar appearance has happened to be generated.

It is recommended to retain at least the following sets of evidence:

• Snapshots of seats, control sources, tasks and damage when exiting the vehicle;
• Entity version and summary fields before and after entering the vision;
• Submission sources and acceptance results before and after network authority switching;
• Play back the application sequence of creation packages, general update packages and vehicle-specific packages;
• Resource ready, physical ready and task ready status when close-up recovery;
• Source, reason and cleanup results in case of deletion or failure.

When these evidences can be connected by entity identity, the system will have the ability to diagnose “why the same car became the current state.” Otherwise, the test can only answer whether the vehicle appears, not whether it still belongs to the original world relationship.

Split “looks correct” into multiple acceptance questions Just because the vehicle visually appears on the correct road does not mean the recovery is complete. It is necessary to confirm separately: whether the identity is consistent, whether the damage is consistent, whether the task relationship is consistent, whether the control source is consistent, whether the route is still interpretable, whether the affiliated entity is correctly bound, whether the network status can be submitted, and whether the physics has reached executable conditions.

These questions can allow for different answers. For example, the vehicle has restored its identity and damage, but the road resources have not yet been loaded, and you should keep waiting at this time; the vehicle has restored network registration, but the player has not regained the control window, and you should retain remote or AI control at this time; the playback model has been created, but the door and wheel packages have not yet been applied. At this time, the presentation layer can temporarily display an incomplete state, but it cannot announce in advance that the playback entity is fully ready.

The verification focus of P12 is therefore not “whether the vehicle is generated successfully”, but whether each recovery stage has clear entry conditions, output status and failure exit. A temporarily unrecoverable entity is more reliable than a system that silently generates default vehicles as long as the reason can be explained, the status can be cleared, and subsequent retries can be made.

Conclusion: What the player leaves is the control window, not the world entity

The player vehicle driving series begins with seating relationships in P1, progresses through inputs, commands, control sources, navigation, strategy, avoidance, execution, damage, combat and chase, and finally returns to a larger question in P12: how a vehicle continues to exist outside of the player’s field of vision.

The vehicle does not need to maintain the same simulation accuracy at all times, nor does it need to be driven by the same control source at all times. What it requires is stable identity, clear ownership, verifiable versions of state, clear de-escalation paths, rebuildable private data and recovery egress after failure.

The network allows state submission to be authoritative, replay allows past vehicle facts to re-enter the world, LOD allows representations of different costs to share the same identity, and multi-vehicle adapters allow cars, boats, planes and trains to retain their own motion semantics under a unified life cycle.

After the player leaves the vehicle, the vehicle can leave the player’s control window, but cannot leave the continuity of the world.

P12 thus completes the line of player vehicle driving mechanics: how players enter the vehicle, how to submit inputs, how to form commands, how to interface with AI, how to drive routes and strategies, how to face collisions and tasks, and how the vehicle continues to exist as a world entity after changes in control.

At the experience layer, these mechanisms converge into a few observable results: after the player leaves, the vehicle does not disappear; when the player returns, the vehicle retains the state it previously established; after the vehicle enters a distant representation, the task does not remain frozen in the past; after network switching or replay reconstruction, the vehicle can still be recognized as the same runtime entity. Players do not need to see the network registry, replay packages or LOD state machines to perceive whether the result is consistent.

From an engineering perspective, world continuity is not about “save all data permanently.” What really needs to be preserved long-term are the minimum facts needed for identity, relationships, mission results, capability constraints and recovery; what can be recalculated are tire contact, local routes, audio-visual performance and partial physics results; what can be downgraded on a budget are update frequency, collision accuracy, animation and distant view performance. Distinguishing these three types of states can simultaneously satisfy the scale of the open world and the player’s continuous perception of the same car.

This is also the conclusion that the previous twelve articles pointed to: the complexity of the runtime lies not in each system having more functions, but in the need for the same entity to continuously migrate state between multiple systems while retaining identity, ownership and recoverability. The player’s driving ends when the input is released, but does not end with the vehicle state; the mission ends when the goal is completed, but does not end with the world relationship; the entity leaves the camera, but does not end with the world time.