_UPDATE_PED_TEXTURE / _RELEASE_TEXTURE / _IS_TEXTURE_VALID take the textureId handle, NOT the ped
Context
Despite "PED" in the name, _UPDATE_PED_TEXTURE (0x92DAABA2C1C10B0E) and _CLEAR_PED_TEXTURE (0xB63B9178D0F58D82) operate on the texture handle returned by _REQUEST_TEXTURE, not on the ped.
The arg map
_REQUEST_TEXTURE(...)→ returnstextureId_IS_TEXTURE_VALID(textureId),_UPDATE_PED_TEXTURE(textureId),_RELEASE_TEXTURE(textureId),_CLEAR_PED_TEXTURE(textureId)— all keyed by the textureId.- Only
_APPLY_TEXTURE_ON_PED(ped, categoryHash, textureId)takes the ped.
Trap
It's natural to assume a "ped texture" native takes a ped handle. Passing the ped where a textureId is expected silently does nothing (or corrupts the wrong handle).
Verified
ped-texture/g_client.lua:498-499 — ApplyTextureOnPed(ped, GetHashFromString(category), textureId) then UpdatePedTexture(textureId).
Linked natives
_CLEAR_PED_TEXTURE(0xB63B9178D0F58D82)_UPDATE_PED_TEXTURE(0x92DAABA2C1C10B0E)
Tags: ped, texture, textureid, updatepedtexture, param-order, handle
Category: natives
Source: jo_libs-fleet
Created: 2026-05-31T09:43:38.467Z