Documentation
How Scoreboard connects to ESX, QBCore and Qbox, reads levels from Quasar job resources and shows real on-duty counts from your own job scripts.
Scoreboard talks to three kinds of resources: your framework, for players, jobs and names; the Quasar job resources, for levels and experience; and any job script that knows who is on shift. Everything framework-specific sits in small open bridge files; the rest is read through the database or through exports.
Layer | Supported | Without it |
|---|---|---|
Framework |
| Required — the list is built from the framework's players. |
Library |
|
Required — the keybind and the server callback. |
Database |
| Required. |
Job levels | Twelve Quasar jobs — miner, garbage, dog walker, newspaper, taxi, bus, truck, hunter, treasure hunter, fishing, lumberjack, lifeguard | The Job Progress panel stays hidden. |
Duty | Any job script with the two duty exports | Active Jobs counts everyone online with the job; badges use |
The optional pieces degrade silently. A stopped job resource is skipped; an export that fails counts as
0or Off — nothing errors.
The framework is chosen when the resource starts, from the first of these found running:
-- config/config.lua
Config.Framework = dependencyCheck({
['es_extended'] = 'esx',
['qb-core'] = 'qb',
['qbx_core'] = 'qb',
}) or 'standalone'If your core runs under another name — es_extended renamed to my_core, say — add it with the bridge it should use: ['my_core'] = 'esx'. Qbox runs on the QBCore bridge through its compatibility layer.
standaloneis only the name used when nothing is found. There is no standalone bridge, so the scoreboard will not open — ESX, QBCore or Qbox must be started before it.
server/framework/esx.lua and server/framework/qb.lua are left open so they can follow a modified core. The scoreboard relies on four of their functions:
Function | ESX | QBCore / Qbox |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
The job is read from getJob().name on ESX and PlayerData.job.name on QBCore. The identifier is what the Quasar job tables are matched against, so if your core stores a different one, GetPlayeridentifier is the function to change.
The Job Progress panel needs no setup beyond running the jobs. On every refresh the scoreboard checks which of the twelve supported resources are started, and for each online player reads level and experience from that job's table where identifier matches. The resources and tables are listed in Installation.
Each resource must keep its original folder name — qs-fishingjob, not qs-fishing — and its experience curve must be copied into Config.JobsProgress so the bar is right, as described in Usage.
Out of the box, Active Jobs counts everyone online with a job, and duty badges fall back to Config.DefaultDuty. To show who is really working, point the job's entry in Config.DisplayedJobs at two exports of the script that runs that job:
Field | Export it calls | Used for |
|---|---|---|
|
| The count on that job's Active Jobs card. |
|
| Each player's On Duty / Off badge. |
truck_driver = {
order = 8,
label = "Truck Drivers",
icon = "fa-solid fa-truck",
onDutyExport = { resource = "qs-truckjob", fn = "getOnDutyCount" },
playerDutyExport = { resource = "qs-truckjob", fn = "isPlayerOnDuty" },
},resource is the resource's folder name and fn the export's name; both are needed. The two fields are independent — use one, both or neither. How to write the exports is in Keybinds and Exports.
Every icon field takes a Font Awesome 6 Free class, such as fa-solid fa-shield or fa-solid fa-truck-medical. The interface loads the icon set itself, so any free solid icon works without installing anything.