Mount, ride, drive, and theft

Vehicle objectives join a quest graph to an already authored vehicle. The graph can wait for V or another character to mount it, assign a character to a seat, observe the vehicle inside a trigger, update Journal presentation, and preserve an outcome fact. It does not create the vehicle’s community entry, placement, driving AI, road route, or cleanup policy.

Tested with Cyberpunk 2077 2.31a, WolvenKit 8.19.0, ArchiveXL 1.27.0, RED4ext 1.30.0, and redscript 0.5.31. See Tested versions.

The node shapes below are Observed in vanilla. A new vehicle lifecycle remains Experimental until mount, passenger assignment, arrival, theft, delivery, cleanup, and reload have been tested together.

Name the vehicle before building the graph

A vehicle reference can use different identity domains. Record which one the chosen node expects.

Do not put a community NodeRef into names, an entry CName into reference, or a TweakDB record into either field. See Identifier domains and Quest prefabs and NodeRefs.

For a community-owned vehicle, a typical entity reference has this semantic shape:

The same pair must be used by mount, assignment, arrival, and cleanup logic. Changing only one consumer creates two apparently plausible identities for one vehicle.

Recipe: V enters a named vehicle

Use this shape when completion means that V mounts the designated vehicle. It does not prove that V is the driver unless the role and seat contract require that state.

In1
  -> objective Active
  -> vehicle mappin Active
  -> wait: V OnMount designated vehicle
  -> objective Succeeded
  -> vehicle mappin Inactive
  -> Out1

The waiting node is a questPauseConditionNodeDefinition whose condition is a questCharacterCondition carrying a questCharacterMount_ConditionType.

The focused reduced candidate used a neutral role while the vanilla driving comparison contains role-aware variants. If the objective says “drive,” test the driver-seat condition; a neutral mount condition can also succeed when V enters as a passenger.

Observed in vanilla: extract base\quest\side_quests\sq004\phases\sq004_02_drive.questphase and inspect only its mount conditions, vehicle references, and nearby objective flow. Those nodes remain bound to sq004 identities and are not a copy-ready child phase.

Recipe: V rides with a contact

“Ride with” has two independent facts: the contact occupies the intended seat and V occupies the same vehicle. A single mount wait cannot prove both, while two latched signals do not automatically prove both remain true together.

                 -> wait: V mounted as intended -----------\
In1 -> objective -> assign contact to vehicle seat          AND -> objective Succeeded -> Out1
                 -> wait: contact mounted as passenger ----/

1. Activate the objective.
2. Use questVehicleNodeDefinition with questAssignCharacter_NodeType to bind the contact to the vehicle and seat.
3. Fan out to one player mount condition and one contact mount condition.
4. Join them with questLogicalAndNodeDefinition; use two distinct input sockets.
5. Succeed the objective only after the join fires.

That graph-level AND is only a structurally valid signal join. Its arrival-memory, unmount, cancellation, and reload semantics remain Experimental. If the objective requires both actors to occupy the vehicle at the same boundary, use one waiting questLogicalCondition whose AND tree contains both current mount predicates, or immediately recheck both current states before success. Retain an adversarial test where the first actor unmounts before the second mounts; test this ordering explicitly.

The assignment payload needs four identities plus explicit operation policy:

For a front-right passenger assignment, inspect whether the vehicle supports seat_front_right. Use isInstant: 1 only when instant staging is intended; it does not request a visible entry animation.

Assignment is not readiness. Wait for the contact community and vehicle to be streamed and spawned before issuing it, then retain the contact mount condition. A fast approach can otherwise expose the same readiness class described in Activation, readiness, and acquisition.

Observed in vanilla: compare the player/contact mount conditions and questAssignCharacter_NodeType work in base\quest\side_quests\sq004\phases\sq004_02_drive.questphase. The reduced candidate proves only a structurally valid assignment plus two-way join; it does not provide a road spline, driving command, scene, or interruption route.

Recipe: drive a named vehicle into an area

The arrival trigger must observe the vehicle, not V. Reusing a player-area condition completes when V crosses the boundary on foot.

In1
  -> objective Active
  -> destination mappin Active
  -> wait: designated vehicle IsInside destination trigger
  -> objective Succeeded
  -> destination mappin Inactive
  -> set completion fact = 1
  -> Out1

Use a questTriggerCondition with:

This is arrival, not delivery. If the vehicle must also stop, continue with the speed condition in Vehicle delivery, cleanup, chase, and race. If V must remain inside, add a separate mount condition and join it explicitly.

Recipe: record theft by mount

A minimal theft objective is the enter-vehicle recipe followed by a persistent outcome fact:

objective Active -> mappin Active -> V OnMount vehicle
  -> objective Succeeded -> mappin Inactive
  -> theft fact = 1 -> Out1

The fact records the quest’s interpretation of the event. It does not change vehicle ownership, player-garage availability, police response, lock state, or despawn behavior. Those systems need separately authored and tested resources.

Use distinct facts for “mounted,” “delivered,” and “cleaned” when later logic needs to diagnose partial progress. One overloaded completion fact makes reload repair ambiguous.

Test the complete sequence with the designated vehicles: V mounts the contact vehicle, the passenger takes the correct seat, the vehicle arrives, V mounts the theft vehicle, and that same vehicle reaches delivery before cleanup.

Manual WolvenKit composition order

1. Extract the cited sq004_02_drive.questphase from your own game and inspect only its mount, assignment, and vehicle-activator fields. Record its graph scope; do not copy the phase or its identities.
2. Author or select the vehicle’s actual owner: community/spawn set, placed world entity, player-vehicle record, or scene. Give the mod-owned vehicle, contact, prefab, and NodeRefs unique identities.
3. Verify the vehicle and any contact resolve and become spawned before adding assignment or mount waits.
4. In the child phase, activate the intended objective and mappin, then add one questPauseConditionNodeDefinition per player/contact mount truth.
5. Bind every gameEntityReference with the exact community/world NodeRef and entry name expected by that condition. Choose the player role and passenger seat deliberately.
6. Add questAssignCharacter_NodeType only after readiness. When simultaneous occupation is required, prefer a Boolean condition tree or an explicit current-state recheck over a graph join that can remember old signals.
7. For arrival, place a destination trigger and bind the exact vehicle as its non-player activator. Keep vehicle arrival separate from player presence and stopped-delivery semantics.
8. Succeed presentation, remove mappins, and write distinct mount/arrival/theft facts before handing off to delivery or cleanup.
9. Reopen the phase and inspect handles, sockets, NodeRefs, entry names, seat slots, roles, and journal paths. Round-trip the mod-owned resources with WolvenKit 8.19.0.
10. Pack one exact candidate and run the controlled cases below from separate copies of an untouched pre-install save.

Presentation and lifecycle checklist

Before connecting the child phase, confirm:

• the objective and map-pin paths resolve to the intended entries and share the correct fileEntryIndex;
• the map pin points to the vehicle or destination that the condition uses;
• the parent phase owns every prefab needed to resolve vehicle, community, and trigger NodeRefs;
• the vehicle and contact have explicit activation and spawned-readiness gates;
• completion inactivates presentation without erasing facts needed for later stages;
• interruption says whether the contact unmounts, the vehicle remains, and the objective fails or becomes inactive;
• another child owns delivery, cleanup, or handoff instead of silently assuming it happened.

Controlled runtime cases

Run these cases in separate save slots after the candidate is structurally validated:

Vehicle and device state can be save-backed. Follow Save state and clean retests before changing a NodeRef or entry name and declaring the edit causal.