Combined Jobs

Can FD treat and revive players?

Yes. Register your Fire Department's existing job in both Fire Jobs and Ambulance Jobs. The employee keeps their Fire job and gains access to Ambulance's medical features, including Treat patient in the job radial menu (G by default) and the normal treatment/revival flow. Both sky_firejob and sky_ambulancejob must be installed and running with sky_jobs_base and sky_base. Duty, grade/permission rules, treatment items, patient condition and other feature requirements still apply.

For example, your FD employees have the job firefighter, and your SAMS/EMS employees have ambulance. After setup:

The FD employee does not need to switch jobs or receive a second framework job. SAMS/EMS keeps its existing ambulance entry, employees and organization.

Use versions of Jobs Base, Fire and Ambulance that include combined-job support. Older versions can hide actions/apps or overwrite catalogs when the same job is registered twice.

Setup: FD with medical features

The example below uses firefighter as the FD's technical framework job name. Replace it with your actual name, such as jfrd or fire. A display label such as “Los Santos Fire Department” is not the job name. The menu and field names below use the English UI.

1. Check the existing Fire job

Open /jobconfig → Fire Jobs → your FD entry → General.

Check Job name. In this example it is firefighter. Note the Society account and, if used, Off-duty enabled / Off-duty job settings so you can use the same values below.

2. Add that same job to Ambulance

Open /jobconfig → Ambulance Jobs and create a New job, or Duplicate an existing medical entry. In the new entry's General section:

• Set Job name to firefighter — exactly the name from step 1.
• Set Society account to the FD's existing account from step 1.
• Match Off-duty enabled and Off-duty job to the Fire entry, if you use an off-duty job.
• Save the entry.

Keep the original ambulance entry if SAMS/EMS still uses it. Add an extra entry for the FD; do not rename SAMS/EMS's existing entry to firefighter.

Your configuration should now contain:

Adding the FD only to a hospital's additional jobs grants access to that location. It does not replace this Ambulance job registration.

3. Keep Fire in charge of the FD's shared settings

For this FD example, edit the existing table in sky_jobs_base/config/config.lua:

Config.PrimaryJobGroups = {
    ["firefighter"] = "fire",
}

Preserve any entries you already have for other jobs. This says: “For the job firefighter, use Fire's shared settings.” Medical access still comes from step 2.

If the actual FD job is jfrd, the entry is ["jfrd"] = "fire". The left side changes to your job name; the right side stays "fire" because it identifies Sky's Fire group.

This setting stays in Jobs Base's config.lua, even when /jobconfig is enabled. After changing it, restart Jobs Base and its dependent job resources, or restart the server.

4. Test with an FD employee and a patient

1. Keep the employee's job set to firefighter and go on duty.
2. Stand next to another player who needs treatment and look at that player. The default treatment distance is 2 metres.
3. Open the job radial with G (or your configured key) and select Treat patient (Patient behandeln in German).
4. Use Ambulance's normal medical workflow and required items. Revival is available when the patient's condition and your treatment settings allow it.

You do not need to create a new hospital just to treat players. Hospital access, supply shops, garages and emergency-call recipients can be configured separately below.

If Treat patient is missing or unavailable

The Ambulance job's countsAsMedic setting controls whether its on-duty employees count as available medics for systems such as the deathscreen and AI medic. It is not the switch that grants treatment access.

What does PrimaryJobGroups change?

Both registrations remain active. The selected group supplies the shared settings for that one framework job:

Choose "ambulance" instead if the Ambulance entry should supply those shared settings. Without a valid override, the alphabetically first registered group wins: for these two groups, that is ambulance. This is independent of start order once both registrations are loaded. If the selected resource stops, the remaining registration supplies the shared settings until it returns. Matching society and off-duty values in both entries avoids a temporary switch to another account or duty mapping.

This does not merge the separate firefighter and ambulance organizations or move employees between them. It combines features for the same job name registered in two resources.

Optional: hospital access, supplies and vehicles

Use /firecreator for fire stations and /hospitalcreator for hospitals. Assign locations and access to the intended jobs. Treatment access and access to a particular building are separate decisions.

Each location uses its creator group's job definition for shops, vehicles, trunk equipment, garage rules and storage/locker limits. An additional job using someone else's location uses that location owner's offers. Locations in the same group with the same owner job share that job's catalog.

The catalogs are not automatically combined. If FD employees should buy medical supplies at a fire station, add those supplies to the Fire entry's Shop. The same applies to medical vehicles in a Fire garage. Duplicating an Ambulance entry copies its configured offers; review them for the new job.

Existing purchased vehicles and stored items retain their station IDs. No SQL cleanup is needed for combined jobs. Legacy integrations without creator context use the primary entry.

Optional: send medical emergency calls to FD

Medical access does not automatically add FD to the deathscreen's emergency-call recipients. In /jobconfig → Ambulance Jobs → Death Screen → Dispatch, use actual framework job names:

Replace both names with your actual jobs. The fallback decision is made when a patient requests help; the patient does not count as an available responder. An empty fallback list keeps normal routing. Existing calls are not rerouted, and custom dispatch hooks can use their own routing.

Fallback changes who receives the call. FD keeps its medical access even while SAMS/EMS is online. It does not make treatment conditional on SAMS/EMS availability.

For the modern Dispatch App, enable Jobs Base's Config.Dispatch.enabled and configure access for the actual FD job. With Fire selected as primary, configure the combined fleet's Dispatch vehicles, channels and statuses in the Fire job entry. Legacy alert banners alone do not enable the modern app. See the Dispatch setup guide.

If you do not use /jobconfig

With Config.UseJobConfigurator = false in the relevant resource, edit that resource's config/config.lua instead:

1. Keep the FD entry with name = "firefighter" in sky_firejob → Config.Jobs.
2. Add a complete job entry with that same name = "firefighter" to sky_ambulancejob → Config.Jobs. Copy an existing medical entry as a starting point, keep the original SAMS/EMS entry, and adjust the society account, off-duty mapping and catalogs for FD.
3. Set Config.PrimaryJobGroups in Jobs Base as shown above and restart the affected resources.

For optional call routing, the equivalent Ambulance fields are Config.DeathScreen.Dispatch.jobs and Config.DeathScreen.Dispatch.fallbackJobs. When /jobconfig is enabled, save jobs and call recipients there; editing plaintext defaults does not replace saved configurator values. PrimaryJobGroups always remains in Jobs Base's plaintext config.