GetHashFromString — RedM's string→hash global (joaat-equivalent), absent from native docs; use it for any Hash param built from a name

Context

Many RedM natives take a Hash argument built from a name — component category, control action, texture asset, blip color modifier, game-event name, model. The canonical RedM way to produce that hash from a string is the global GetHashFromString(str). It does not appear anywhere in the native reference (the only related entry is the inverse, GET_STRING_FROM_HASH_KEY 0xBD5DD5EAE2B6CE14), so agents either miss it or pass a raw string.

The trap

Passing a raw string where a native expects a Hash silently fails — the category isn't found, the control never fires, the texture stays blank. No error is raised.

The fix

Wrap the name first:

PromptSetControlAction(promptId, GetHashFromString("INPUT_RELOAD"))
local cat = GetHashFromString("horse_mane")

GetHashFromString is functionally a joaat (same family as GetHashKey/joaat); jo_libs standardizes on it across its entire codebase rather than GetHashKey.

Verified

jo_libs relies on the global (no local definition/polyfill) and uses it pervasively: control keys prompt/client.lua:123, component categories component/g_client.lua:52,744, texture albedo/normal/material ped-texture/g_client.lua:394-396, palette component/g_shared.lua:313, game-event names game-events/g_client.lua:19. Corpus grep for GetHashFromString returns 0 hits — genuine documentation gap.

Linked natives

• GET_STRING_FROM_HASH_KEY (0xBD5DD5EAE2B6CE14)

Tags: hash, gethashfromstring, joaat, redm, controls, components, idiom
Category: natives
Source: jo_libs-fleet
Created: 2026-05-31T09:38:57.557Z