SkyForge Shows

What it is

Scripted firework and light shows synced to a timeline, staged over a venue for holidays, season openers, and finales — the moment a crowd records. The performance claim you will read here is the one we measure: the resmon figure stays [measured-pending] until a real client produces a real number. For owners who want a recurring server event without guessing what it costs the client. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore. Escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.

The problem it exists for

Server events die at the climax. The build-up works — the crowd gathers, the countdown lands — and then the finale is either three default fireworks that impress nobody or a particle storm that drops the whole venue's frame rate at the exact moment everyone hits record. The moment the event exists for is the moment the tooling fails.

Why we're building it

Celebrations are retention events: a new year, a server anniversary, a gang truce, a wedding — the nights players clip and stay for. We think the finale should be a directed thing, staged by an event team with real controls, and that the show is only real if the venue's performance survives it. That second half is a claim we have explicitly not proven, which is why it appears below in notProven and not here.

What it's designed to do

Design intent, not shipped behaviour — none of this has been built yet.

• Designed for staged shows: sequences, cues, and finales an event team fires deliberately — not a consumable players spam.
• Designed with the performance budget as a first-class constraint, because the whole point of a finale is a crowd standing in one place to watch it.
• Designed with event-team controls — who can fire a show, where, and when — so the sky stays a tool for staged moments rather than ambient chaos.
• Designed to hand the moment to CityPulse, so the show that just happened becomes the citywide alert and the recap the rest of the server sees.

What is not proven

The section every product page should have and almost none do.

• In development and not purchasable — authored in the studio repo, with no runtime proof published pending the Shadow bench.
• No resmon figure — [MEASURED-PENDING]. For an effects product this is the entire question, and the number we eventually publish has to come from crowd conditions, not an empty test server.
• The $29.99–34.99 planned band is a target, not a commitment until the studio pricing lock.
• No release date.

What we're building toward

A finale exploding over a crowd — split-screen with a performance graph that never budges.

Current status, stated exactly

• resmon [measured-pending]
• escrow manifest — at release
• framework support — decided at build, published at release
• open-vs-escrowed manifest — published at release, file by file

What to verify before buying any event resource

This applies to every product in this category, ours included, whenever it arrives. Hold SkyForge Shows to exactly these when it launches — and if it fails one of them, don't buy it.

• Ask for the resmon figure during a finale with a crowd present, not one rocket on an empty server. Effects scripts are cheap when nothing is happening (see /guides/fivem-resmon-script-performance).
• Ask who can trigger a show. If the answer is anyone holding the item, you've bought ambient noise, not an event tool.
• Ask what ships escrowed and what stays open — an event team needs to edit sequences without filing a support ticket (see /guides/fivem-asset-escrow-explained).
• Our July 2026 survey collected no fireworks or show-tooling prices — the category has no reference price in our data. With no anchor, vet the seller instead of the number (see /guides/how-to-vet-fivem-script-sellers).

Universally: ask for the measured resmon figure with its method and date, the exact list of which files ship open versus escrowed, a dated changelog, and the refund window. Four answers. Any of them missing is an answer too.