Permissions

FireScript has three roles. Every one of them is checked on the server, so a modded client cannot skip it.

The three roles

• Firefighter — fire warnings and blips, dispatch calls and the Respond button, incident alerts, rescues and extrications, the tablet (with RestrictToFirefighters on), showing as a unit on the tablet map, and reward payouts (ESX / QBCore)
• Scenario manager — the scenario creator (/firescenarios), starting, stopping, saving and deleting scenarios, the tablet's Command tab (AOP, wind) and /setwind. A manager can always open the tablet
• Admin — /startfire, /stopfire, /stopallfires, /getfires, /setfireaop, /enablerandomfires, /importfires, plus everything a scenario manager can do

Putting fires out is not a FireScript permission. Anyone who gets water on a flame puts it out. Who may pick up a hose is decided by Fire Hose V2 — see the bottom of this page. Fires themselves render for every player.

Who is a firefighter

• ESX / QBCore — anyone whose job is in Config.JobNames. Only the job is checked: aces and identifiers do nothing here
• Standalone with UseFireJobWhitelist = true — an identifier in FireJobIdentifiers, or the FireScript.Firefighter ace (FireJobAcePermission)
• Standalone with UseFireJobWhitelist = false — every player

Who is an admin or scenario manager

• UseWhitelist = false — every player is an admin, and so a scenario manager too. This applies on every framework, not just standalone. Fine for testing; turn it on for a live server
• UseWhitelist = true — an admin is an identifier in Config.Identifiers, or the FireScript.Permission.All ace (Config.AcePermission)
• A scenario manager is any admin, or the FireScript.Scenarios ace (Config.Scenarios.AcePermission). Use it to hand out the creator and the Command tab without the admin commands

Who can open the tablet

Checked in this order — the first match wins:

1. RestrictToFirefighters = false — everyone
2. A scenario manager — yes. With UseWhitelist off only the FireScript.Scenarios ace counts here, otherwise every player would get in as a "manager"
3. ESX / QBCore, or UseFireJobWhitelist = true — firefighters only
4. Plain standalone with UseWhitelist = false — everyone, because every player is a firefighter there
5. Plain standalone with UseWhitelist = true — the FireScript.Tablet ace (Config.Tablet.AcePermission)

The fire_tablet item runs exactly the same check — carrying it does not get anyone in.

Example server.cfg

# Admins: everything
add_ace group.admin FireScript.Permission.All allow

# Fire command: the creator + the tablet's Command tab, no admin commands
add_ace group.firecommand FireScript.Scenarios allow

# Standalone firefighters (UseFireJobWhitelist = true) - the FireScript role and the hose
add_ace group.firefighter FireScript.Firefighter allow
add_ace group.firefighter FireHose.Permission.All allow
add_principal identifier.license:YOUR_LICENSE_HERE group.firefighter

Fire Hose V2

The hose has its own gate, set in firehosev2/config.lua:

• ESX / QBCore — its own JobNames list. Keep it in step with FireScript's
• Standalone — UseWhitelist + Identifiers, or the FireHose.Permission.All ace. With its UseWhitelist off, everyone can use the hose

When a change takes effect

• Admin, scenario manager and tablet checks run every time they are used, so a new ace works straight away
• Firefighter status is worked out when the player joins, and on ESX / QBCore whenever their job changes. Give someone the firefighter ace or add their identifier while they are online, and they need to reconnect
• After restarting firescriptv2 on a running ESX / QBCore server, players get alerts again once they relog or change job