RedM Fireworks Troubleshooting

Sanity check before anything else: both the server console and the client F8 console must print a green rm_fireworks started on boot. If only one does, the other side failed to load.

The item does nothing when used

No animation, no console output.

Cause	How to confirm	Fix
The item row does not exist	VORP: missing from the items table. RSG: missing from shared/items.lua	Run the SQL, or paste the four entries
VORP: the server was never fully restarted	You added the row while the server was running	vorp_inventory caches the items table when it starts. A brand-new row needs a full server restart — restarting rm_fireworks is never enough
The item is not flagged usable	VORP usable is 0; RSG useable = false	Set them. Note the RSG spelling
VORP: vorp_inventory is not started	Read the boot log or txAdmin	The server bridge needs both vorp_core and vorp_inventory at started. Until then it loops forever, prints nothing, and registers no usable item — while the client looks fine
Framework forced to the wrong one	"vorp" on an RSG server, or the reverse	Set it back to "auto". Forcing does not skip detection; a wrong value loops forever with no error
A framework folder is renamed	Your core is not exactly vorp_core, vorp_inventory or rsg-core	Detection matches those literally
The item name does not match the config	Compare against Fireworks[n].item	Make them identical, character for character
Another resource registered the same item name	Search for firework_1	Rename in both places. Last registration wins, and which one depends on start order
The client is stuck mid-sequence	You died, teleported, or a run never finished	Start returns silently when a sequence is already running. Restart the resource or reconnect — there is no automatic recovery
The server has no user object for you	Nothing at all in either console	Removal is wrapped in if user then. If your character is not loaded, the item is never removed, no abort is sent, and you get a full local show with no broadcast and no refund

Check framework state read-only

Do not type ensure vorp_inventory to find out whether it is running. ensure starts a stopped resource and restarts a running one — and restarting an inventory under players is its own incident. Read the boot log or the txAdmin resource list.

The prompt never appears

Cause	Fix
You did not wait long enough	Plant plus three hauls take ~13.9 s, then a 2 s turn. The prompt appears at roughly the 16 second mark
ui/dist is missing or was emptied	F8 shows 404s for the bundle. Restore or rebuild — see UI Reference
base was changed in vite.config.js	Set it back to './' and rebuild — see UI Reference
Another resource is drawing a full-screen opaque NUI page	Stop it and retry. This resource never calls SetNuiFocus and cannot fight another layer

"Place" never lights up

The use prompt renders at 35 % opacity until you are far enough from the crate.

The script never moves your ped

The only task it issues is a scripted 2-second turn. There is no pathing anywhere in the resource — you walk away under your own control. If you stand still, the distance number stays at 0 forever.

Cause	Detail
Not far enough	15 m outdoors, 5 m indoors, measured in 3D
Not walking	See above
The game does not consider you indoors	Most RDR2 buildings are not real interiors, so you need the full 15 m inside them. Game data, not a config bug
You rebound the key	The label and the hash are independent. The plaque may say G while the code listens for something else
The rope made you think you ran out of slack	The rope gates nothing. Only the distance number matters

Opposite symptom: if "Place" lights up instantly and the distance jumps to a huge number, another resource deleted the planted crate. The distance is then measured against the map origin — and detonating plays the show there.

Rope invisible or detached

Cause	Detail
Rope textures are not loaded	The resource never calls RopeLoadTextures(). On most servers another resource already has. If yours renders invisible, add that call before the rope is created — a source edit, re-apply after updates
Other players cannot see it	Expected. The crate, spool and detonator are networked; the rope is a local physics rope on your client only
It snaps twice	Expected. It is re-attached to your hand during wiring, then to the detonator
It goes straight and rigid	You walked past its 50.0 initial length
It detached after an interruption	The sequence is driven by timers, not animation events. Another resource clearing your tasks breaks the attachments while the timeline runs on. There is no interruption handling

Rockets launch but bursts are invisible or wrong

Two independent particle layers: the global Effects.trail / .sound, and each entry's own effects list.

Symptom	Likely cause
Nothing launches at all, clean console	A misspelled dict in Effects.trail. The loader waits forever with no timeout, so every rocket thread hangs before becoming visible
Rockets climb then hang in the air	A misspelled dict in that entry's effects list
Rockets pile up and never disappear	A misspelled dict in Effects.sound. The burst plays, then the thread hangs loading the sound dict — so the rocket is never deleted and its trail never stopped. They accumulate for the whole show
Rockets burst but you see nothing	A valid dict with a misspelled name. The asset loads, the effect just does not appear

Full detail including the commented alternatives and the missing-comma trap: Configuration → particle dictionaries.

Why are the fireworks silent?

Because nothing in this resource plays audio. There are zero audio natives in the whole thing.

The key that looks like audio is not: Effects.sound is handed to a particle helper, so it spawns a second particle at the burst point — a powder flash, not a bang. The key is misnamed in the shipped config, and this is the single most common misreading of the file.

There is no volume key, no distance falloff and no audio config of any kind. If you want audible bangs, add them yourself off the detonation hook — and remember that receivers of a synced show never get that hook.

The item is lost after a restart

The item leaves the inventory the moment you use it, before the plant animation.

Situation	What happens
Clean restart / stop mid-sequence	The server refunds every in-flight item. You get it back
The player disconnects mid-sequence	The item is lost. The drop handler clears the record without refunding
The server crashes mid-sequence	The item is lost. The stop handler never runs
You tried to cancel during an animation block	You cannot — see the stage table in Configuration
You detonated	No refund, by design
The refund fired but nothing arrived	Your inventory was full. The refund does not check the result

Other players do not see the show

Cause	Fix
SyncFireworks is false	Set it to true
You used the fixed-coords path	LaunchFireworks is never auto-broadcast. Trigger it from the server with -1
The server refused the broadcast	It only re-broadcasts when it recorded that you actually consumed that exact item. This is the anti-exploit check and it is intentional
Nobody is near a coords-driven show	The show plays at the entry's coords, not at the player
You expected identical bursts everywhere	Each client runs its own copy from the broadcast coords. Direction and burst choice are randomised per client

Other players do see the crate, spool and detonator regardless — those are networked objects, independent of this setting.

Console errors on start

Error	Cause
SCRIPT ERROR: @rm_fireworks/config/config.lua	Lua syntax error from your edit. It is a shared script — if it fails, both sides are dead
Duplicate entry 'firework_1'	The SQL was already run once. Harmless
RSG unexpected symbol near '['	The entries were pasted outside the items table, or a comma was dropped
attempt to index a nil value (global 'RM_CORE')	The script order in the manifest was changed. Restore the shipped order
attempt to index a nil value (global 'RM_Config') in your resource	You tried to read RM_Config from outside. Every resource has its own Lua state — see Developer API
unknown firework id (red)	Your code called Start with an index not in the config. Start returns false
Nothing at all, but no items work	The framework was never detected. There is no error printed for this

The folder must be named exactly rm_fireworks — the export name and your ensure line depend on it.

Performance

Each rocket runs in its own thread, ticking every 10 ms and re-applying velocity. A rocket lives about 1.5 seconds, so the shipped item entries keep about 3 alive at once and the coords entry about 7–8.

The three knobs are number, randomWait and offSetZ. Two things before you crank them:

The sync broadcast has no distance filter. A player on the other side of the map still spawns and ticks the whole show. If that matters, add a distance check at the top of the sync handler:

local myCoords = GetEntityCoords(PlayerPedId())
if #(myCoords - vector3(coords.x, coords.y, coords.z)) > 500.0 then return end

That is a source edit — re-apply it after an update.

Nothing prevents simultaneous detonations. Two entry-5 shows at once means roughly 15 live rockets, 15 looped trail effects and 15 threads per client.

Known limitation: the abort is not enforced

You will hit this while testing, so it is worth stating plainly.

When a client starts the sequence the server tries to remove the item. If removal fails, the server sends an abort and the client calls Stop(). But the start chain is a straight-line blocking sequence with no re-check after that point — the abort lands inside the ~16 s committed window, and the next step simply recreates the spool, rope and prompt. That player can walk the fuse, press the plunger, and see a local firework show.

What it costs you, precisely:

• No item is duplicated. Nothing was removed, so nothing can be gained.
• No refund is paid. The refund checks the same server record.
• Nothing is broadcast. Other players see no show.
• The detonation still writes a log line, because the server logs every occurrence without validating it.

So the worst case is a cosmetic, single-client show that costs the server nothing.

A side effect of the same path: because Stop() clears the in-progress flag, the guard that blocks a second concurrent sequence is cleared too. An aborted player still holding a real item can start a second sequence while the first chain is running — the two share prop handles and the result is visually broken until both finish. Restarting the resource clears it.

Adding permissions, cooldowns or usage limits

There are none in the resource. Any player holding an item can use it, as often as they have items, anywhere, in any state.

Option A — a small source edit (recommended). Put your check in the CreateUsableItem callback in server/rm_server.lua. Returning early costs the player nothing, because the item is not removed until the client asks a moment later:

RM_CORE.CreateUsableItem(firework.item, function(source, args)
    if not IsPlayerAceAllowed(source, "rm_fireworks.use") then return end
    -- your cooldown check here
    TriggerClientEvent("rm_fireworks:UseFireworks", source, id)
end)

An ACE object is denied by default, so nothing passes until you grant it:

add_ace group.admin rm_fireworks.use allow
# or, to let everyone use fireworks but keep the cooldown:
add_ace builtin.everyone rm_fireworks.use allow

This keeps item removal, the cancel refund and the broadcast working as shipped. It needs the Open Source edition, and it is a source edit — re-apply after updates.

Option B — drive it from your own resource. Set item = false on those entries, register your own usable item, run your checks, remove the item yourself, then trigger rm_fireworks:UseFireworks.

Read this before choosing Option B

With item = false the server never records a consumption, so the show is not broadcast to other players — only the detonating player sees it. The cancel refund also does nothing; you own removal and refund entirely.

What this resource deliberately does not do

Listed so you can rule it out before you install, not after.

• No FiveM / GTA V support. It declares game 'rdr3'.
• No ESX / QBCore support, and no RedEM:RP or standalone inventory bridge. VORP and RSG only.
• No commands. The resource registers zero.
• No sound. Not a single audio native.
• No damage and no fires. The crate is invincible; rocket collision is disabled.
• No state guards. Mounted, in a wagon, swimming, in combat, falling, dead — none of it is checked.
• No ACE, cooldown, rate limit or per-player cap.
• No admin menu, shop, crafting, blips, target system or MLO.
• No library dependencies. JD_logsV3 is optional and skipped when not started.
• No interruption handling. Death and teleports do not stop the sequence; the timers run to the end.
• No database use beyond the four VORP item rows.

Updating

Updates ship as a full resource folder. Keep the old one until the new one is verified.

Files that carry your edits — do not blindly overwrite: config/config.lua, ui/src/* and ui/dist/* if you restyled, replaced icons, and any client/server file you patched.

Every source edit these docs suggest, in one place:

Edit	File
RopeLoadTextures() before the rope	client/rm_functions.lua
Distance filter on synced shows	client/rm_init.lua
ACE check / cooldown	server/rm_server.lua
State guards	client/rm_init.lua
Audio, if you added any	client/rm_functions.lua
Your own detonation hook body	client/rm_init.lua

Do not copy your old config over the new one

A new version can add keys, and an old config missing a key the new code reads throws a nil-index error at runtime rather than falling back to a default. Compare the two key by key and move your values across.

Stop the resource cleanly rather than killing the server — a clean stop refunds every in-flight item; a hard kill does not.

Things an update never touches: the VORP items rows and RSG items.lua entries, the icon copies in your inventory folder, and your server.cfg lines including any add_ace. If an update adds a new item, you add the row and icon yourself — and on VORP that needs a full server restart.

Reporting something

Include the startup lines from both consoles, your framework and its version, what you changed in config/config.lua, and the full console output around the failure.

Then open a ticket in Discord.