DEV Community

Tack k
Tack k

Posted on

Building a Custom Ambulance Job Script for QBCore — Why I'm Replacing the Default One

#fivem #qbcore #lua #gamedev

This time it's QBCore-only, but I want to talk about an ambulance job script I'm currently building.

For my new server, I want to use as many of my own custom scripts as possible. And out of all of them, the ambulance job is by far the most work.

The basic flow sounds simple:

An EMS player diagnoses a downed player → transports them to the hospital → treats and operates on them → revives them.

Simple on paper. But three parts of this flow turned out to be deceptively complex:

  • The UI
  • The transport
  • The revival

The UI — Going Fully Custom

I built a completely original NUI for this. It handles X-ray imaging, injury locations, injury types, symptom categories, treatment options, and the items required for each treatment.

For the X-ray images themselves, I had ChatGPT generate them. Honestly, when it comes to image generation, ChatGPT still produces the cleanest output and draws the best — illustrations and photorealistic images, it's just on another level.

When it comes to actual scripting and code, though, Claude Code is still the strongest in my experience. That hasn't changed.

The injury system works like this: an X-ray image is shown, and the injured body parts are highlighted in red as overlays on the image. Click a highlighted area, and a panel pops up showing the injury type, symptoms, what treatment is required, and which items are needed to perform it.

Once treatment is complete, it's time for revival.

The Revival — Rewriting Default Dependencies

I'm using qb-target for the revival action itself. Since it's the final step, I wanted the next interaction to feel snappy and immediate.

Here's where it gets messy: by default, revival logic depends on qb-ambulancejob. And it's not just that resource — qb-adminmenu revival, txadmin revival, all of them route through the same dependency.

So I had to track down every one of those functions and rewrite them to work with my custom system. Tedious, but necessary if you want to fully replace the default behavior without leaving broken admin tooling behind.

The Down State — Trickier Than It Looked

The screen and behavior when a player goes down was the part I underestimated the most.

Three things needed to happen:

  1. The player needs to go down on the spot
  2. A down animation needs to play while they're incapacitated
  3. They need to stay there

That third one — making sure the player stays where they fell — was surprisingly difficult. Without proper handling, players would respawn on top of mountains, or get teleported into the middle of the street. Claude Code (or as I call her, Kurako) did a lot of the heavy lifting fixing those edge cases.

For the down screen NUI, I wanted it to feel more dramatic than just a static "you're injured" message. So I added heart rate and blood pressure displays, plus that classic ECG line you always see in medical dramas — the one that ticks up in sync with each heartbeat. The data is static for now, but visually it sells the moment.

If players just stared at a list of symptoms while waiting to be treated, it'd be boring. The vibe matters.

Where I'm At Now

That's where the project stands today. I'll write a follow-up once the script is fully complete.

Thanks for reading.

— Tack K

Top comments (0)