Exports & API Reference

The developer surface of oxide-ems — what other resources can read, call and listen to.

oxide-ems is a consumer of o-link, not a provider. It does not register an o-link namespace, so there is no olink.ems.*. Integration happens through the exports, events and statebags below.

Exports

Server

-- Read one setting's current effective value (the database value, not the file default).
local interval = exports['oxide-ems']:GetSetting('SalaryInterval')

-- Write one setting. Persists to the database, mirrors to clients and applies live.
exports['oxide-ems']:SetSetting('SalaryInterval', 600000)

GetSetting takes any top-level setting key — the same keys documented in Configuration (Revive, Beds, Surgery, Dispatch, and so on) — and returns the whole value, table or scalar.

SetSetting writes it back and always returns true. It performs no validation, so prefer the in-game editor (/ems settings) for anything a human is doing; this export is for scripted setup.

Server (QBCore only)

local doctors = exports['oxide-ems']:GetDoctorCount()

Number of medics currently on duty, across every department. Registered only when QBCore is the detected framework, as the replacement for the export qb-ambulancejob provided.

The matching QBCore callback is also registered:

QBCore.Functions.TriggerCallback('hospital:GetDoctors', function(count) end)

On any framework, the same number is always readable from GlobalState['oxide:ems:onduty'] — that is the portable way to ask.

Global state

Server-written, readable from anywhere.

Global state survives a resource restart, so these are republished at boot.

Player statebags

Replicated, so any client can read them for any player.

oxide:ems:duty

Player(src).state['oxide:ems:duty']
-- { deptId, deptName, gradeRank, facilityId }   -- on duty
-- nil                                            -- off duty

The authoritative duty state. Presence means on duty. This is the right thing for a HUD or a third-party script to read — do not keep your own mirror, because duty can be set and cleared server-side (a firing, a department deletion, a multi-job switch) without the player's client ever asking for it.

oxide:ems:triage

Player(src).state['oxide:ems:triage']
-- { critical, stabilized, paused, expiresAt, serverNow }   -- downed or dead
-- nil                                                       -- otherwise

oxide:ems:downed

Player(src).state['oxide:ems:downed']
-- { phase = 'downed'|'dead', bleedoutEnd?, respawnEnd?, serverNow }
-- nil when alive

Only written on QBCore and ESX, where oxide-ems runs the downed/dead loop. On Qbox, qbx_medical owns that state and this bag stays nil; on Oxide Core, the death provider owns it.

bleedoutEnd is present in the downed phase, respawnEnd in the dead phase, both as Unix timestamps in seconds with the same serverNow countdown pattern.

For a portable downed check across all frameworks, use o-link instead:

if olink.death.IsPlayerDowned(src) or olink.death.IsPlayerDead(src) then ... end

Entity statebags — fleet vehicles

Written by the server on every spawned fleet vehicle. Clients never write these.

Events

Server-side, safe to listen to

AddEventHandler('oxide:ems:server:initialized', function() end)
AddEventHandler('oxide:ems:server:settingsReady', function() end)
AddEventHandler('oxide:ems:server:departmentsChanged', function(reason, data) end)
AddEventHandler('oxide:ems:server:respawnPointsChanged', function(points) end)
AddEventHandler('oxide:ems:medicJobMirror', function(action, charId, jobName, gradeRank, jobLabel) end)

Client-side, safe to listen to

RegisterNetEvent('oxide:ems:departmentsUpdated', function() end)
RegisterNetEvent('oxide:ems:medicDataChanged', function() end)
RegisterNetEvent('oxide:ems:forceClockOut', function() end)
AddEventHandler('oxide-ems:client:configUpdated', function(key) end)

Internal events — do not trigger these

These carry the resource's own state between its server and client sides. They validate their input, so triggering them from outside will not corrupt anything, but they are not an API and their shapes can change:

oxide:ems:client:bedEnter / bedExit / bedHealTick, vehicleEnter / vehicleExit, stretcherAttach / stretcherDetach, xrayEnter / xrayExit / xrayScreen, surgeryEnter / surgeryExit, runRespawnCutscene, openSettings, runDiag, oxide:ems:openAdminPanel, oxide:ems:vehicleRelinked / vehicleUntracked / vehicleDestroyed, and the oxide:ems:server:* net events (distress, reportDeath, reportReinjury, surgeryLeave, xrayLeave, xrayClearScreen, compat:qb:enterLaststand, reportVehicleState, reportVehicleType, fleetDecorated).

Compatibility surface

These are the events your framework's ambulance job used to own. oxide-ems re-registers them so existing resources keep working. Trigger them exactly as you did before.

All frameworks

QBCore only

qb-inventory, qb-phone, qb-hud and qb-radialmenu all read the isdead and inlaststand metadata, and oxide-ems keeps both truthful through every transition.

ESX only

The Player(src).state.isDead statebag is kept accurate throughout, and esx:onPlayerSpawn (plus esx_basicneeds:resetStatus and playerSpawned) is re-fired after every revive and respawn so ESX's own death detection and its add-ons re-arm.

txAdmin

txAdmin:events:healedPlayer is handled on QBCore and ESX — the heal button in the txAdmin panel revives the target, including the "heal everyone" form.

Usable items

The medical items your framework's ambulance job registered are re-registered by oxide-ems, with their original healing behaviour and one improvement: the item is only consumed when the action completes, where the stock resources consumed it up front.

firstaid routes into the normal revive flow on the nearest downed person, and the revive pipeline consumes it itself on success — it is never removed twice.

medical_bag is registered on every framework and unpacks into field supplies.

Integrating a dispatch resource

oxide-ems raises alerts through olink.dispatch.CreateAlert. Among the dispatch adapters o-link ships, oxide-dispatch is the only one that implements the server-side CreateAlert — the others provide a client-side send only.

With any other dispatch resource, alerts are skipped and a debug line is logged; nothing errors. On-duty medics still receive the direct notifications for distress signals, /911e, clinic reception pages and bed-request alerts, because those do not go through dispatch. Only the automatic down and death alerts depend on it entirely.

Alerts are sent with the code 10-52 (or 911 for /911e), a heart-pulse icon, and a job list containing every enabled EMS department name plus the extra jobs configured under Dispatch.