How detection works#
Nothing here is configured by hand. While the resource boots it asks the server which resources are running and picks a bridge file for each layer. A layer with no match falls back to standalone, which means the feature either does without or quietly disappears.
Every bridge lives in a folder you can open and edit — custom/, client/custom/ and server/custom/. If your resource is not on these lists, copying the closest file and changing a few lines is the whole job.
Frameworks#
Resource | Notes |
|---|---|
| ESX. Money, jobs with grades, admin groups and the society accounts used for billing. |
| QBCore. Jobs and gangs, both read with their grade. |
| Qbox. Detected separately so the newer grade shape is read correctly. |
None | Standalone. Shops still work, but there is no money and no job system, so paid work and job-run shops are unavailable. |
Inventories#
The inventory carries the four items, the shop stashes and the parts counters.
Supported |
|---|
|
With no inventory the resource still runs, but items cannot be required or consumed and the stashes and parts shops do not appear.
Adding the four items is a separate step — see Inventory Items.
Billing#
Used when a mechanic invoices a customer instead of taking payment on the spot, and when an engine swap is charged after the fact.
Supported |
|---|
|
With none of them running, invoicing is simply not offered and payment happens immediately. Where an invoice is paid to — the shop's own funds or a society account — is a setting.
Vehicle keys#
So a car that comes out of the shop garage, or off the flatbed, is one the driver can actually start.
Supported |
|---|
|
Clothing#
For the shop wardrobe: a mechanic changes into work clothes and back into their own afterwards.
Supported |
|---|
|
Vehicle prices#
Some figures — a car's value, used for insurance-style pricing — are read from whichever vehicle shop your server already runs, so you are not maintaining a second price list.
Supported |
|---|
|
With none of them present, a default vehicle price is used instead. It is a setting.
Interaction and prompts#
This is the one place where the answer is probably not what you expect.
If qs-textui is running, those prompts are drawn through it so they match the rest of your server. Otherwise they are drawn natively. Either way the text says the action and the key badge is added for you, which is what keeps it readable in all 41 languages.
Notifications#
Where every message from the resource appears, chosen in config/config.lua:
Config.Notification = 'ui'
-- 'ui' this resource's own notifications (default)
-- 'qs-interface' qs-interface's notify
-- 'ox_lib' lib.notify
-- 'native' the GTA feed above the minimapEvery notification in the resource, client and server side, goes through one function in custom/client.lua — so wiring in a system that is not on that list means editing one place, not hunting through the code.
Skill checks#
Repairs, washes and the other radial jobs can ask for a skill check first. With ox_lib running — which it is, since it is required — ox_lib's own skill check is used. Each action's difficulty is a setting, and the whole thing can be switched off.
Writing your own bridge#
All of these folders are shipped unencrypted and are meant to be edited:
Folder | Holds |
|---|---|
| The framework bridges and the two functions every other file goes through. |
| Inventory item use, clothing, vehicle keys, billing prompts, and the tuneshop visuals. |
| Inventory, billing, vehicle shop prices and the Discord webhooks. |
A bridge is small by design: each file answers the same handful of questions, and
standalone.luain each folder is the empty reference to copy. An update will not overwrite your edits — these paths are excluded from the encrypted part of the resource.