Natives: the game functions behind every FiveM script

Nearly everything a FiveM script does to the game — spawning a car, reading a position, playing an animation, drawing text — goes through a native: a function built into GTA V (or into FiveM itself) that scripts can call. There are thousands of them. Knowing how to find the right one and read its documentation is the single most useful skill after the language itself.

GTA V’s own scripts (missions, the phone, the Online modes) are written in a scripting language that calls into the game engine through native functions. FiveM exposes those same natives to Lua, JavaScript and C#, and adds its own set — the CFX natives — for things only a multiplayer framework needs, such as player identifiers, resources, state bags and server-side entities.

The Cfx documentation site hosts the native reference, searchable by name. Each entry shows the C-style declaration, the native’s hash, parameters, return value and community notes. Take GET_ENTITY_COORDS:

Vector3 GET_ENTITY_COORDS(Entity entity, BOOL alive);

local pos = GetEntityCoords(PlayerPedId(), true)
print(pos.x, pos.y, pos.z)

• Name: remove underscores and capitalise each word to get the Lua/JS name.
• Types: Entity, Ped, Vehicle and Player are integer handles; Hash is a number (use joaat or backticks); BOOL is true/false.
• Notes: many parameters are named p0, p1… because nobody has worked out what they do. The notes under the entry usually say what values are safe.

In C, some natives write results into pointers. In Lua you simply receive them as extra return values, in order:

BOOL GET_GROUND_Z_FOR_3D_COORD(float x, float y, float z, float* groundZ, BOOL ignoreWater, BOOL p5);

local found, groundZ = GetGroundZFor_3dCoord(x, y, 1000.0, false, false)
if found then print(groundZ) end

The function’s own return value comes first (found), followed by each out-parameter (groundZ). The same pattern applies to natives like GetScreenCoordFromWorldCoord.

Most game natives exist only on the client, because the client runs the game. With OneSync the server gains a set of natives that work on its view of entities — GetPlayerPed, GetEntityCoords, GetVehiclePedIsIn, SetEntityCoords, CreateVehicleServerSetter and others. The reference marks each native’s side; calling a client-only native on the server throws an error that the function does not exist.

Occasionally a native has no name in your runtime yet — new game builds add natives, and some are only known by hash. You can call it directly:

-- Equivalent to SetEntityInvincible(ped, true)
Citizen.InvokeNative(0x3882114BDE571AD4, PlayerPedId(), true)

Return types of natives called by hash are not known to the runtime, so reading return values may need explicit result types (Citizen.ResultAsInteger(), Citizen.ResultAsVector() and friends). Use named natives whenever they exist.

Each native call crosses from the scripting runtime into the game. That is cheap once, and expensive a few thousand times per frame. The common waste is calling the same native repeatedly inside a Wait(0) loop — for example PlayerPedId() five times per frame. Cache values that do not change every frame, and slow the loop down when nothing is nearby. Lua performance optimisation and threads and Wait cover the techniques.