Skip to content

setPedEnterVehicle

Client-side

A standard MTA API with Neon behavior

Extends MTA's authoritative vehicle-entry lifecycle with a verified native passenger-entry task after server confirmation.

Syntax

bool setPedEnterVehicle(ped thePed [, vehicle theVehicle, bool|int passengerOrSeat])

GTA task mapping

ORIGINAL GTA TASK 05CA / 05CB
CTaskComplexEnterCarAsDriverCTaskComplexEnterCarAsPassenger

SCM equivalent: TASK_ENTER_CAR_AS_PASSENGER / TASK_ENTER_CAR_AS_DRIVER

The selected seat decides which direct GTA task the syncer creates after MTA's server confirmation. Unlike SCM 05CA/05CB, this API keeps MTA's authoritative request lifecycle and does not use the opcode-specific timed wrapper.

Arguments

thePedped

Ped requesting entry.

theVehiclevehicleoptional

Target vehicle; the established MTA inference remains available.

passengerOrSeatbool|intoptional

Passenger flag or explicit MTA seat. Seat 0 is driver; seat 1 is the first passenger/SCM passenger index 0.

Returns

true when the authoritative request was accepted; false otherwise.

Ownership and lifecycle

Low-level ped task calls require the client that simulates the living, streamed ped. Driving tasks also require control of the streamed vehicle. They do not create lifecycle handles; the optional native-task-runtime adds server-owned route epochs and reconstruction for drive_to routes. Gang-tag ownership is resource-exclusive, survives object streaming and recreation, and is released automatically when the owner stops.

OOP aliases

  • ped:setEnterVehicle(vehicle, passengerOrSeat)

Where this comes from

RELATED NEON APIS

Continue exploring

Read the system guide →