One file per character. That's the whole API.
NPC Chat ships drop-in static NPCs with a polished chat-style dialogue UI for FiveM. Persistent, server-spawned, OneSync-synced — two players standing fifty meters apart see the same NPC at the same spot. No per-client stream-in, no duplicates, no edge cases on resource restart.
You want a quest-giver. Not a framework rebuild.
Most static-NPC resources ship as the bottom layer of a bigger system. NPC Chat is the lightweight drop-in — same chat UI as the bigger Intel NPC, none of the ambient stack.
Persona resources are overkill
You need three static characters on a server — a fence, a mechanic, a hot-dog vendor. You don't need the full personality / mood / reaction engine on top. NPC Chat gives you the polished chat panel without the rest of the city.
Per-client spawns desync
Most quick-NPC scripts spawn client-side, so two players see the ped in two different places (or one of them sees nothing). NPC Chat spawns server-side via CreatePed and uses state bags to sync the npc id to every client that ever streams the entity.
A clean chat NUI and a one-file-per-character config and OneSync-correct spawns.
The whole shape of the resource.
Drop a file into config/characters/, add it to shared_scripts, restart. Done.
One file per character
RegisterNpc({ id, model, coords, dialogue… }) is the entire API. Spawn, identity, target, blip, dialogue, server hook — all in one declarative table.
- Ped model + scenario + freeze + blip
- Speaker / tag / mood / body language in the chat header
- Trust track optional, off by default
Recursive topic trees
Topics, followups, topic_bar — the same recursive schema across all three. Tone chips (dialogue / bribe / threaten / flirt …), preview tooltips, cost / skill pills, disabled state with a lock chip.
- Player echo + NPC response with optional pools
- Highlighted words (hl-offer, hl-threat, hl-name …)
- System messages: default / warning / success / error
Framework-agnostic bridge
QBX, QB-Core, ESX or Standalone — auto-detected on first call. ox_inventory, qb-inventory, esx_inventory — the same. Override permanently with one config key if you prefer.
Bridge.GetMoney / AddMoney / RemoveMoneyBridge.HasItem / AddItem / RemoveItem / GetItemCountBridge.GetJob / GetPlayerName / Notify
Server hook contract
The server hook on any topic gets a clean context with src, npc id, topic path and player info. Return values control everything: continue, cancel with reply, or fully override the next menu.
nil / true— continue normallyfalse, 'msg'— cancel with that message- Override table — new response + followups + terminal flag
A polished chat panel — same one as Intel NPC.
The dialogue UI is the same NUI Intel NPC ships. Typewriter responses, choice buttons, mood badge, location chip, witness HUD, optional cinematic over-the-shoulder camera.
One demo character, end to end
One of the seven demos that ship with the resource. Random greeting pool, nested buy menus, tip flow, highlighted words, server-side money charge. The whole character is one file in config/characters/mike_barkeep.lua.
- Buy a beer · charge bridges to your active framework
- Tip flow nudges trust + fires a custom event
- Random pool for greetings keeps revisits fresh
Item-gated topics, in-line
Anya checks your inventory inside her server hook. If you don't have the right item, the topic is locked behind a chip. Bring it and she unlocks a discount sub-menu through a hook override.
disabled+disabled_labelrender a lock chip- Hook returns an override table to swap the next menu
- System messages call out conditions inline
Reference builds across the map.
Seven complete characters ship in config/characters/. Each is a different shape of dialogue tree — greeting pools, item gates, server overrides, custom hooks. Use them as patterns, or delete them.
RegisterNpc(...) and restart.Same chat NUI, same bridge, same exports as the bigger Intel NPC. Drop-in light layer for any RP server.
Server-spawned. State-bag synced.
The most common static-NPC bug is per-client stream-in — two players see two different peds. NPC Chat is built around CreatePed(pedType, hash, x, y, z, h, true, true) on the server, with SetEntityOrphanMode(ped, 2) to keep the entity alive even when no player is in scope.
The server creates each ped and writes the npc id into the lrr_npc_chat:id state bag. Clients listen via AddStateBagChangeHandler and decorate the ped with scenario, ox_target, blip. Persistent across resource restarts, identical across every client. If onesync is off, the server refuses to spawn and logs a clear error.
Exports & events you can lean on.
Runtime API
Add an NPC from any other resource at runtime, or force-open a dialogue. The whole schema is the same as a file-based character.
AddNpcRemoveNpcOpenDialogueCloseDialogueIsDialogueOpenGetNpcPedIsNpcPedGetNpcIdFromPed
Lifecycle events
Hook spawn / despawn from any other resource — e.g. trigger an ambient barker line when your fence streams in.
lrr_npc_chat:client:npcSpawnedlrr_npc_chat:client:npcDespawnedlrr_npc_chat:client:npcsLoaded
The other Last Resort resources.
Intel NPC
NPC Chat is the same NUI as Intel NPC, stripped down. Run both: Intel NPC for the ambient layer (every random ped on the street), NPC Chat for the named, persistent quest-givers and merchants.
Open product page →Account Levels
Gate any NPC Chat topic behind a tier inside its server hook. One RequireLevel(src, n) call rejects with a localized notification when the player isn't ready — you don't write the UX.
Buy once. Own it. Update forever.
One purchase. Lifetime updates.
A production-ready drop-in. OneSync infinity required, ox_target recommended, the bridge handles QBX / QB / ESX / Standalone automatically. License under the standard Tebex EULA — deploy on every server you own.
- Full source — no escrow, no licence-check phoning home
- Seven complete demo characters as reference builds
- Server-side spawn with state-bag identity — OneSync-correct
- Same chat NUI as Intel NPC — consistent art direction across both
The questions worth answering.
No. NPC Chat is a fully standalone resource — it ships its own chat NUI and bridge. They share the same art direction so they look consistent if you run both, but neither depends on the other.
Yes — that's the whole point. The server creates each ped via CreatePed(..., true, true), sets SetEntityOrphanMode(ped, 2) to prevent garbage collection, and broadcasts the npc id through a state bag. Every client that streams the entity decorates it identically.
QBox, QB-Core, ESX or standalone. The bridge auto-detects on first call. For inventory: ox_inventory, qb-inventory, esx_inventory or standalone (no-op). You can hard-pin either via Config.framework / Config.inventory.
Yes. exports.lrr_npc_chat:AddNpc(definition) on the server uses the same schema as a file-based character. RemoveNpc(id) despawns and unregisters.
Recommended but optional. If ox_target is present, NPCs get a clickable interaction with the configured icon. If not, the resource falls back to a DrawText3D E-key prompt — configurable via target.e_key_text per character.