Frameworks
ESX, QB-Core, QBox, ox_core, and a framework of your own.
Config.Framework.name decides which adapter is loaded.
| Value | Framework |
|---|---|
esx | ESX Legacy and older ESX |
qb-core | QB-Core |
qbox | Qbox |
ox | ox_core |
custom | your own, see below |
A stock install needs nothing else here. Identifiers, jobs, money and the vehicle table all come from the adapter. ktx_cases and ktx_fishing want one thing outside it: their items have to be created in your inventory, see Install.
ESX
esxMode decides how the shared object is fetched.
legacy | the getSharedObject export, which is what ESX Legacy ships today |
old | waits for the shared object event that older forks still fire |
esxSharedObjectEvent is the name of that event. Only a fork that renamed it needs this line.
Keys that belong to one resource
Config.Framework also carries the settings that make sense for a single resource.
| ktx_fishing | moneyAccount, where the market pays into: cash or bank |
| ktx_cases | vehicleGarage, the garage a vehicle reward is parked in. ESX ignores it, it has no garage column. |
A framework of your own
Set Config.Framework.name = "custom" and fill in public/framework.lua. The file lists every function it needs with its signature. A missing one stops the start and names itself.
ktx_garages names the first one it misses:
[ktx_garages] Custom framework missing required server function: getPlayer
See public/framework.lua for the template.ktx_cases, ktx_fishing and ktx_dispatch name the file and everything missing in it:
[ktx_dispatch] public/framework.lua is missing: getPlayerJob, getPlayerNameThe adapters under bridge/server/ stay readable in the release, so the one closest to your framework is the fastest starting point.
An adapter has to answer truthfully. removeInventoryItem returning true without removing anything, or addInventoryItem returning false after the item is already in the bag, turns into an exploit rather than a bug.