BLIP_ADD_FOR_COORDS style hash: don't assume an unrecognized decimal is garbage — it may be a real name you just haven't tried, or a sprite hash misapplied to the style slot

Context

Debugging a "blip doesn't show" report for a RedM point blip created via BLIP_ADD_FOR_COORDS (0x554D9D53F696D002).

The trap

The existing code passed 1664425300 as the first (style) argument. That number didn't match any of ~35 hand-guessed BLIP_STYLE_* candidate names hashed via GetHashKey, so it was concluded to be an unrecognized/garbage value and replaced — which broke blip creation entirely (the replacement values either produced a valid-but-inert blip, per the existing BLIP_ADD_FOR_COORDS-first-arg finding, or made the native return no handle at all).

1664425300 was never garbage. joaat('blip_style_pickup_weapon') (RDR3's hash algorithm: sum+left-shift-10+xor-right-shift-6 per byte, then two more mix rounds, all on the lowercased string) equals exactly 1664425300 — it's BLIP_STYLE_PICKUP_WEAPON. A codebase's own shared TS blip helper (Blip.forCoord/forRadius/forArea/forEntity) had this exact value hardcoded as its universal default style with a comment naming it — that comment was the tell, but the number was dismissed as unrecognized before that file was checked.

A related trap in the same debugging session: GetHashKey always succeeds on any input string, including strings that don't correspond to a real engine constant. So "I hashed 35 plausible BLIP_STYLE_* names and none matched" proves nothing about whether the original number is valid — it only proves those particular 35 guesses were wrong. Also fabricated a new style name (BLIP_STYLE_LOCATION) that sounded plausible, hashed it without error, and used it as if verified — it does not exist in the real style table and silently failed to create any blip, every time, indistinguishable from the original "unrecognized" symptom.

A second confusable trap: a sprite hash (from textures/blips/README.md or textures/blips_mp/README.md, e.g. blip_attention = -774688241) looks identical in shape (a signed 32-bit decimal) to a style hash (from blip_styles/README.md). Passing a sprite hash into the style argument slot of BLIP_ADD_FOR_COORDS makes the native return no blip handle at all (false), not an inert one — one step worse than the already-documented "wrong-argument-type gives an inert blip" finding.

Fix / verified facts

• 1664425300 = BLIP_STYLE_PICKUP_WEAPON, a completely valid, commonly-used style hash — confirmed both by direct joaat computation and by live Citizen.InvokeNative(0x554D9D53F696D002, 1664425300, x, y, z) returning a real handle with DoesBlipExist true.
• To identify an unknown blip-related decimal, don't hash-guess names — grep_docs/grep the literal decimal directly against blip_styles/README.md (styles) and textures/blips/README.md + textures/blips_mp/README.md (sprites, two separate files/pools). The three tables are disjoint namespaces; the same-shaped number means something different depending on which table it's actually in.
• BLIP_STYLE_LOCATION is not a real RDR3 blip style — verified absent from the full ~218-entry style table scraped from blip_styles/README.md. Any code using it should be treated as broken.
• Also confirmed while sizing the same blip: SET_BLIP_SCALE (0xD38744167B2FA257) only affects BLIP_ADD_FOR_RADIUS/BLIP_ADD_FOR_AREA blips per its own native doc — it does nothing on a BLIP_ADD_FOR_COORDS point blip. Point-blip sizing goes through BlipAddModifier with BLIP_MODIFIER_SCALE_1 (1.2x) or BLIP_MODIFIER_SCALE_2 (1.5x) instead — no documented sub-1.0x modifier exists.

Linked natives

• BLIP_ADD_FOR_COORDS (0x554D9D53F696D002)
• SET_BLIP_SPRITE (0x74F74D3207ED525C)
• SET_BLIP_SCALE (0xD38744167B2FA257)
• BLIP_ADD_MODIFIER / BlipAddModifier

Linked natives

• BLIP_ADD_FOR_COORDS (0x554D9D53F696D002)
• SET_BLIP_SCALE (0xD38744167B2FA257)
• SET_BLIP_SPRITE (0x74F74D3207ED525C)

Tags: blip, map, ui, minimap, hash, joaat, debugging
Category: natives
Created: 2026-08-27T18:17:29.463Z