GTA-V-ported RedM script: fake Citizen.returnResultAnyway + wrong BLIP_ADD_FOR_COORDS hash + nonexistent SetBlipAsShortRange/BeginTextCommandSetBlipName crash thread before spawn code runs

Context

Debugging a RedM job script where NPCs never appeared and wagon spawn couldn't be verified. The client script's main thread was dying on its FIRST tick, before most of the script ever ran.

The bugs, in crash order (each one revealed by fixing the previous)

1. Citizen.returnResultAnyway() used as a trailing arg in Citizen.InvokeNative(...) calls (CREATE_PED, CREATE_DRAFT_VEHICLE, BLIP_ADD_FOR_COORDS). This function does not exist in RedM/FiveM Lua — SCRIPT ERROR: attempt to call a nil value (field 'returnResultAnyway'). It appears nowhere else in a ~330-resource repo. Root cause looks like a hallucinated/copied pattern, not a real FiveM idiom (the real pattern is Citizen.InvokeNative(hash, ..., Citizen.ResultAsLong()), or just call the Lua-wrapped native directly and skip InvokeNative entirely).
2. Once that crash was fixed, the hash used for BLIP_ADD_FOR_COORDS (0x5A039BB832BA2D03) turned out to be a wrong/unrelated hash — the correct one is 0x554D9D53F696D002 (confirmed via lookup_native({name:"BLIP_ADD_FOR_COORDS"})).
3. SetBlipAsShortRange(blip, bool) — does not exist in RDR3. This is a GTA-V-only native with no RedM equivalent; RedM's range/fade behavior is controlled via BLIP_ADD_MODIFIER instead. lookup_native returns no exact match, closest hits are all irrelevant (SET_BITS_IN_RANGE, SET_PED_ID_RANGE, etc.) — a clean signal the ported code assumed the wrong game.
4. BeginTextCommandSetBlipName / AddTextComponentString / EndTextCommandSetBlipName — the classic GTA V three-call text-command idiom for naming a blip. RDR3 replaces this whole dance with a single native: _SET_BLIP_NAME (0x9CB1A1623062F402), Lua wrapper SetBlipName(blip, name).

Why this was a good multi-symptom bug

All 4 sit inside addBlip() and spawnNpc()/wagon-spawn code, which run in Citizen.CreateThread on resource start. Because Lua aborts a thread on the first uncaught runtime error, bug #1 alone meant NOTHING after the first addBlip() call ever executed — no peds spawned, no wagon logic reachable, even though those subsystems were individually fine. Symptom ("ped invisible / not spawning") was reported as if it were a ped-specific problem (invisible mp_* model, missing outfit preset — which WAS also present as a separate real issue with MP_POST_MULTIRELAY_MALES_01 needing _EQUIP_META_PED_OUTFIT_PRESET + _UPDATE_PED_VARIATION), but the dominant root cause was the thread dying before most peds were ever created.

Verification method

Fixed one crash at a time, restarted (rcon_resource restart), re-read client_logs with errorsOnly:false + pattern:"<resource>" after each restart — each fix revealed the next line's error, confirming a clean linear stack rather than needing to guess all 4 at once. Final confirmation: ch-debug's dbg_carcass showed visible=1 for the spawned NPC at the exact config coords, and client_eval directly proved both CreateDraftVehicle(stagecoach001x, ...) and CreatePed(MP_POST_MULTIRELAY_MALES_01, ...) + outfit-preset-refresh produced a visible, existing entity.

Takeaway for future debugging

When a RedM resource is copy-pasted/ported from GTA V (or LLM-generated from GTA V training data), expect a cluster of GTA-V-only globals/natives/hashes, not just one. Grep the whole file for Citizen.InvokeNative and any suspicious "obviously GTA" idiom (BeginTextCommand*, ShortRange, three-arg blip creation with a sprite hash) up front rather than fixing one crash and assuming the rest of the file is clean.

Linked natives

• BLIP_ADD_FOR_COORDS (0x554D9D53F696D002)
• _SET_BLIP_NAME (0x9CB1A1623062F402)

Tags: blip, createped, invisible, gtav-port, wagon, draftvehicle
Category: natives
Created: 2026-07-24T00:29:20.515Z