Ambulance & Death Scripts
On this page10
Config.DeathSystem = 'auto'The New Life Rule needs one answer: was this a revive or a respawn? A revive keeps memories. A respawn erases the people who watched you go down.
Support and auto order
| System | Support | Auto order | How it is read |
|---|---|---|---|
| our native detector | Supported | always | Down state plus the movement rule. |
| txAdmin heal | Supported | always | txAdmin:events:healedPlayer = an admin revive. |
| wasabi_ambulance_v2 | Supported | 1 | Best with the one-liners below in its open listener file. |
| wasabi_ambulance (v1) | Stub | 2 | Its dead state; optional one-liners. |
| ak47_qb_ambulancejob | Stub | 3 | Its client events, backed up by the movement rule. |
| ak47_ambulancejob | Stub | 4 | Same. |
| brutal_ambulancejob | Stub | 5 | Its client events plus the movement rule. |
| osp_ambulance | Stub | 6 | Its client events plus the movement rule. |
| randol_medical | Supported | 7 | Server events. |
| ars_ambulancejob | Supported | 8 | Observed revive and status. |
| ars_ambulance (AmiRobin fork) | Stub | 9 | Same pattern, different event names. |
| visn_are | Stub | 10 | Export poll plus a one-liner. |
| qbx_medical | Supported | 11 | State bag plus its server-local respawn event. |
| qb-ambulancejob | Supported | 12 | Observed net events. |
| esx_ambulancejob | Supported | 13 | esx:onPlayerDeath, observed revive, server state. |
How exact each route is
| Route | How exact |
|---|---|
Our server exports (ReportDown, ReportRevived, ReportRespawned) called from the ambulance script's server code | Exact — the best you can get. |
| The ambulance script's own server-side events | Exact. |
| Events the ambulance script only sends from the player's game | Good, with the movement rule as a backup. |
| No ambulance script we can read | Our own detector plus the movement rule. |
The movement rule
With Config.Death.UnknownOutcome = 'movement' (the default), when the ambulance
script cannot be read:
While down and on foot, a jump longer than
TeleportJumpMeters(20 m) between two position samples, which starts outside and ends insideHospitalRadius(60 m) of a hospital point, is a respawn. Anything else is a revive.
Your ambulance script's own hospital list replaces our five vanilla points wherever the bridge can read it.
Other options for UnknownOutcome: 'keep', 'forget', or 'admin' (keep until an
admin decides, from the death review list).
Making a script exact — the one-liners
Several ambulance scripts have an open listener file. One line at the top of each existing function turns a guess into an exact signal. Keep their own code below your line.
wasabi_ambulance_v2 (recommended)
wasabi_ambulance_v2/bridge/listeners/server.lua:
-- in onLastStand(source, deathData):
exports['5code-recognition']:ReportDown(source, { stage = 'laststand', killer = deathData and deathData.killer })
-- in onDeath(source, deathData):
exports['5code-recognition']:ReportDown(source, { stage = 'dead', killer = deathData and deathData.killer })
-- in onRevive(source, reviver, method):
exports['5code-recognition']:ReportRevived(source, reviver,
({ player = 'player', item = 'item', hospital = 'npc', admin = 'admin', command = 'admin' })[method] or 'unknown')
-- in onRespawn(source, facilityId, coords):
exports['5code-recognition']:ReportRespawned(source, 'hospital')wasabi_ambulance v1, brutal_ambulancejob, osp_ambulance
Optional, and it beats the movement rule. In their open respawn function:
-- server-side code:
exports['5code-recognition']:ReportRespawned(source, 'hospital')
-- client-side code:
exports['5code-recognition']:ReportDeathSignal('respawned', { method = 'hospital' })visn_are
In its open client OnPlayerRespawn() handler:
exports['5code-recognition']:ReportDeathSignal('respawned', { method = 'hospital' })Any other death script
Call the three server exports from its server code:
exports['5code-recognition']:ReportDown(source, opts)
exports['5code-recognition']:ReportRevived(source, reviverSrc, kind)
exports['5code-recognition']:ReportRespawned(source, method)Add your resource to ServerConfig.Api.TrustedResources first.
kind is one of medic, player, item, npc, admin, or unknown. Which of
those keep memories is Config.Death.KeepOnRevive — all of them, by default. A
confirmed revive of unknown kind always keeps.
txAdmin
Always read, on every ambulance script: txAdmin:events:healedPlayer counts as an
admin revive. It is in KeepOnRevive by default, so an admin heal never wipes
anyone's memory.
Routing buckets
Config.Death.IgnoreBuckets = {} -- e.g. { 7, 8 }Disconnects while down
Config.Death.OfflinePolicy decides:
| Value | Behaviour |
|---|---|
'wait' (default) | Decide when they come back. |
'respawn' | Forget now. |
'ignore' | Never forget. |
'timeout' | Forget if offline longer than OfflineTimeoutMinutes (30). |
A waiting case still open after PendingMaxHours (72) counts as a respawn.
Admin review
Every death is listed on the Deaths page of the admin panel, with its witness
list, its outcome, and how that outcome was decided. The page explains itself, and
each death has Keep memories and Wipe memories buttons (admin level edit,
with a written reason). With Config.Death.AdminRestore = true (the default), a
death that already wiped memories offers Restore memories, which brings them back.
Restores go to the Deaths webhook when it is set.
That page is also where UnknownOutcome = 'admin' parks cases it cannot decide.
Full configuration
Custom
Set Config.DeathSystem = 'custom' and fill the 'custom' branch in
bridge/death_client.lua / bridge/death_server.lua.