FiveM Supernatural
ScriptPossession, investigation, and the rite — Veilbreakers: Daemon Protocol
What a FiveM supernatural script is
A FiveM supernatural script adds paranormal content — possession, hauntings, rituals, entities — as a structured co-op event rather than as scenery. The ones worth buying hide the supernatural element so players have to investigate it, keep the outcome server-authoritative so it cannot be forged, and survive their second run. Veilbreakers: Daemon Protocol is Vice Drip's version: in development, not for sale, no release date, and no runtime proof published.
Most supernatural content is a job with a costume on.
Most FiveM event content is a job with a timer on it. Players run it once for the novelty, twice for the payout, and then never again — because nothing about it was a story, and nothing about it was worth clipping. The thing that actually recruits for a server is a moment someone posts, and almost no purchasable content is built to produce one.
Status honesty: Veilbreakers: Daemon Protocol is in development and not for sale. Everything on this page is category argument or design intent — nothing is a shipped capability. There is no runtime proof published — pending Shadow bench, so no performance claim here rests on a number. Key art is illustrated brand art, not gameplay footage. The price shown is a planned band pending the studio pricing lock, not an offer, and the product name is not locked as final.
Hidden first, server-authoritative always, scene over payout.
Four design commitments that decide whether a supernatural event is played twice. These are stated as our reasoning and our design intent — nothing here is a demonstrated capability.
Investigation before confrontation
The interesting half of a possession story is the half before anyone is sure. Something is wrong with a person; the evidence is behavioral and circumstantial; the crew has to decide whether they believe it. Design intent is that the possession is hidden and has to be found — because a script that opens with a monster already visible has skipped straight to the least original part of its own premise.
Server authority over the outcome
An event that lets the client decide whether the rite succeeded is an event where the outcome is a setting. Design intent is that the server owns the state machine — who is host, what stage the rite is at, whether it broke — and validates source, permission, rate limit and argument types on every step. The client asks; it never rules.
The scene is the product, not the payout
Event content is judged on whether players voluntarily do it a second time and whether they clip it. A generous reward can carry an event through its first week and nothing carries it after that. We would rather ship something that pays modestly and gets talked about than something that pays well and plays flat.
One daemon, one loop, done properly
v1 scope is deliberately narrow: a single daemon, one possession-to-banishment loop, no bosses and no corruption map. Event content is exactly the category where a wide feature list hides a shallow experience, and a first release that does one sequence well is more honest than one that does five badly.
Why we are building it
We're building the event we'd want to walk into: an investigation that turns into a confrontation, with enough staging that the crew who survives it tells the story afterward. Cinematic co-op RP is judged on whether the moment lands, not on a feature count — which makes it the hardest thing on our roadmap to fake and the easiest to evaluate honestly.
Designed to
- Designed as investigation first: hidden possession that has to be found before it can be confronted.
- Designed for co-op PvE — the crew, the rite, the shield, and something that tears free and has to be fought.
- Designed around corruption zones and boss events rather than a repeating job loop with a cooldown.
- Designed so the interesting part is the scene, not the payout — an event that pays well but plays flat has failed at the only thing it was for.
What breaks in a typical supernatural script.
Failure modes of the mechanism, described generically. These are not claims about any named product — we have not audited anyone else's code, so we compare criteria and never rivals.
A job with a costume on
Most purchasable event content is a timed loop with supernatural art applied: go here, hold a key, receive a reward, wait for the cooldown. It reads as horror for one run and as a chore by the third, because nothing about its structure was ever a story.
Novelty mistaken for replay value
The first run of anything is carried by not knowing what happens. The question that decides whether an event was worth buying is what the tenth run feels like, and that question is rarely asked before purchase and never answered in a trailer.
Effects-heavy content with no frame budget
Supernatural content leans on particles, lighting and sound, which is exactly where client frame time goes to die. An event that runs at 0.01ms at idle and tanks the server during its own climax has failed in the only moment it existed for.
Client-decided outcomes
If the client reports that the rite completed, a modified client reports that the rite completed. In event content this matters more than usual, because the reward and the story both hang off a single state transition.
The trailer that hides the pacing
A cut trailer can make any event look tense. Pacing is the entire product in this category and a cut removes exactly the information you need. Unedited footage of a full run is the only version of the video worth watching before you pay.
Content that reaches into everything
Event scripts tend to touch inventory, jobs, dispatch, medical and the economy at once. That is fine when the integration points are declared and configurable, and it is a migration problem when they are assumed.
v1 scope, stated plainly
One daemon. One possession-to-banishment loop. No bosses, no roster of entities, no corruption map — those are not withheld features, they are simply not in the first release, and we would rather say so here than let a feature list imply otherwise. The title itself is not cleared as final.
What is not proven
- It is not released and cannot be bought. Everything above is design intent, not a demonstration.
- No runtime proof published — pending Shadow bench. Nobody outside the studio has watched this run, and an event is judged on how it plays, which makes that the gap that matters most here.
- No performance figure exists — [MEASURED-PENDING]. Event content with heavy VFX is exactly the category where that number matters most, and we don't have it yet.
- The $39.99 intro / $44.99 standard figures are planned targets, not commitments.
- We have not published a release date. Marketing a supernatural event with a fake date would be an unusually stupid way to start.
- Runtime proof status, in our own words: no runtime proof published — pending Shadow bench.
Something is wrong → investigate → expose → the rite → what tears free → the receipt.
The intended sequence, in order. Every stage below is design intent for an unbuilt product — none of it is a description of running code, and the shape can still change before release.
- 01Something is wrongA host is chosen quietly. Symptoms surface as behavior and environment rather than as a marker on the map. Design intent is that a crew can be in the same room as a possession and not know it yet.
- 02InvestigationThe crew gathers what they can and argues about what it means. This is the stretch of the event where roleplay carries the load and the script's job is mostly to stay out of the way while providing something real to find.
- 03ExposureThe possession is confirmed. Design intent is that this is a server-side state transition with consequences, not a UI reveal — once the thing knows it has been seen, the encounter changes character.
- 04The riteA co-op sequence with defined roles and a way to fail. The interesting design problem is making failure survivable and story-generating rather than a reset, which is why the rite has stages rather than a single progress bar.
- 05What tears freeThe confrontation. One daemon in v1, server-authoritative, built so the fight is a scene the crew describes afterwards rather than a health bar they grind down.
- 06The receiptThe case closes and leaves a record — designed to land on the MDT and produce a recap card, so the event is legible to the rest of the server rather than an isolated instance that only the participants know happened.
The criteria that decide an event script.
No vendor column and no scores. We have not audited anyone else's code, so ranking rivals would be invented precision — and on the runtime row we would fail our own criteria today. Take these eight questions to every option you shortlist, ours included.
| Criterion | Why it matters for event content | What to ask |
|---|---|---|
| Unedited footage | Pacing is the product, and a cut trailer removes exactly the evidence you need. | Can I watch one uncut run from start to finish, including the slow part? |
| Second-run experience | Novelty carries the first run. Replay value is what you are actually buying. | What is different on the second run, and on the tenth? |
| Frame cost during the event | Effects-heavy content is where the client budget dies, and idle numbers hide it. | What is the resmon figure during the climax, not at idle, with the date and artifact? |
| Server authority | Decides whether outcomes and rewards can be forged by a modified client. | Which side owns the state machine, and what does the server validate? |
| Failure design | An event where failure is a reset teaches players not to risk it. | What happens when the crew fails? Is that a story or a wasted evening? |
| Integration surface | Event content reaches into inventory, medical, dispatch and economy. | What does it require from my framework and inventory, and what is configurable? |
| Player-count behavior | Co-op content tuned for six can be trivial at twelve and impossible at two. | What crew size is it tuned for, and what scales? |
| Runtime proof | Separates a built product from a demonstrated one — including ours. | Has this been run on a live server, and can you show the capture with a date? |
What to verify before buying a FiveM supernatural script.
Six questions, useful even if you never buy from us. For platform facts — asset escrow, the resource manifest, the profiler — read the official Cfx documentation at docs.fivem.net rather than a seller's summary of it.
Ask for uncut footage, not a trailer
Every event looks good in a thirty-second cut. Ask for a full run including the investigation stretch, because that is where a shallow event reveals itself and where a good one earns its price.
Ask what the second and tenth runs look like
If the honest answer is 'the same thing', you are buying a one-week novelty. That can still be worth it — but you should know that is what you are buying.
Ask for the resmon figure during the event
Idle numbers are close to meaningless for effects-heavy content. Ask for the sustained figure during the heaviest sequence, with the artifact version, framework and date attached.
Ask which side decides the outcome
A seller who cannot answer whether the server or the client owns the state machine has not thought about the thing that determines whether rewards can be forged.
Ask what it assumes about your server
Inventory, medical, dispatch, jobs. Get the list of integration points and find out which are configurable and which are hard requirements before you pay, not during installation.
Ask about content sensitivity and your community
Supernatural content sits close to real religious practice, and servers differ in what they want. Ask whether the ritual language, iconography and setting are configurable, and whether anything ships that names a real faith. Ours is written to avoid naming real deities, faiths or scripture at all.
The same discipline applied across the catalogue lives in the Proof Center. How events, announcements and nightlife fit the wider city sits in city culture, and the performance method behind every resmon question above is in our resmon guide.
Supernatural RP, without the overclaim.
What is a FiveM supernatural script?
A resource that adds paranormal content — possession, hauntings, rituals, entities — as a structured event rather than as scenery. The good ones are investigation-first co-op sequences with server-authoritative outcomes; the common ones are a timed job loop with horror art applied.
Can I buy Veilbreakers: Daemon Protocol?
No. It is in development, it is not for sale, and there is no purchase path on this site. Any figure shown next to it anywhere on our pages is a planned band pending the studio pricing lock, not an offer.
When does it release?
There is no release date, and we have not published one because we do not have one. Announcing a date for unbuilt event content would be a fast way to teach you not to believe the rest of the page.
Has it been tested on a live server?
No. The published runtime status is: no runtime proof published — pending our Shadow bench. There is no resmon figure and no performance claim on this page, which matters more than usual for effects-heavy content.
Is the artwork gameplay footage?
No. The key art is illustrated brand art for a product in development. Nothing on this page is a screenshot of a running build, and we will label real captures as such when they exist.
Does it reference any real religion?
No. It is deliberately written to avoid naming real deities, faiths or scripture, and the iconography is not modelled on a specific tradition. Servers vary widely in what their communities want here, so the intent is that the flavour layer is configurable rather than assumed.
How much of it is in the first release?
One daemon and one possession-to-banishment loop. No bosses, no corruption map, no roster of entities. That is a deliberate scope decision rather than a roadmap tease, and the product name itself is not locked as final yet.
Which frameworks will it support?
It is designed to run through the ForgeCore bridge — Qbox and ox_lib first-class, ESX Legacy and QBCore through the same adapter — so your framework choice stays reversible. That is design intent; the tested matrix publishes at release.
Last verified: 2026-09-02 · In development · Runtime proof: pending Shadow bench · Not for sale
Hear when there is something real to watch.
One email when Veilbreakers has uncut footage worth your time — the full run, not a trailer cut, with the measured numbers attached. No drip campaigns, no fake countdowns, no date we cannot keep.
Write to support@vicedrip.com with “Launch signal” in the subject. We reply once to confirm before adding you, then send one email at launch plus occasional release notes. Reply “unsubscribe” any time. How we handle your data.