How Integrations Work#
The core of Outfit Bag does not know which framework or target you run. Everything that depends on another resource goes through a small, unencrypted bridge file in client/custom/ and server/custom/, and the one for your server is picked by looking at what is already started:
Layer | Supported | Without it |
|---|---|---|
Framework | es_extended · qb-core · qbx_core | Runs standalone: a bag is placed with the |
Target | ox_target · qb-target · qs-textui | A drawn prompt over the bag: E to open, G to pick up. |
Inventory | Any inventory that honours the framework's usable items — ox_inventory, qs-inventory, qb-inventory, the ESX default | Standalone only: there is no item. |
Clothing | illenium-appearance · fivem-appearance · qb-appearance · qb-clothing · qbx-clothing · skinchanger | Applied outfits last until the player reconnects. |
Notifications | The framework's own: ESX.ShowNotification, QBCore Notify, qbx_core Notify | Printed to the F8 console. |
Database | oxmysql | Required. The only one. |
Every optional integration degrades silently. A missing resource makes the script fall back to its own version of that part, and nothing errors.
Frameworks#
Each framework bridge answers the same questions — who is this player, what is their job, how is an item given and taken — in its own way. The answer that matters most is the identifier, because it decides whose outfits a bag opens on:
Framework | Outfits are saved against | Items given and taken with |
|---|---|---|
ESX |
|
|
QBCore |
|
|
Qbox |
|
|
Standalone | The player's first identifier. | No item. |
The job used by uniform bags comes from the same place: job.name in the framework's player data. The usable item is registered through the framework too — ESX.RegisterUsableItem, QBCore.Functions.CreateUseableItem or qbx_core's CreateUseableItem — which is why any inventory that respects them works without its own bridge.
Targets#
Target | How players interact |
|---|---|
| Use Bag and Pick Up Bag as options on the bag itself. |
| The same two options on the bag, within 2 m. |
| A 3D prompt visible from 6 m. E opens within 2 m, G picks up. |
Built-in | Text drawn over the bag within 2 m: |
The labels come from the locale file (TARGET_USE_BAG, TARGET_PICKUP_BAG), so they follow Config.Language.
Clothing Resources#
Clothing resources only come into play when Config.PersistOutfitToClothing is on — see Usage → Persisting Outfits. The first one found wins, in this order:
Order | Resource | How the outfit is saved |
|---|---|---|
1 — every framework |
|
|
2 — every framework |
| The same exports, then |
3 — ESX |
|
|
3 — QBCore |
| The player's current skin with the outfit merged in, through |
3 — Qbox |
|
|
Overriding Detection#
Detection looks for a started resource from its list and takes the one it finds. To pin a layer by hand — two targets running at once, a renamed resource — set the value instead of letting it detect:
-- shared/config.lua
Config.Framework = 'qbox' -- esx · qbcore · qbox · standalone
Config.Target = 'ox_target' -- ox_target · qb-target · qs-textui · standalonePinning is worth doing whenever two candidates of the same kind are running — ox_target alongside qb-target, for example — because the lists are not checked in a fixed order.
Adding a Backend#
Supporting something that is not on the list is a small job: the bridge folders are unencrypted, and each file only runs when it is the chosen one.
Copy the closest bridge
Frameworks live in
client/custom/framework/andserver/custom/framework/, targets inclient/custom/targets/. Copy the file closest to what you run and give it a new name.Change the guard and the calls
The first line decides when the file runs. Point it at your own id, then rewrite each function against your resource, keeping its name and arguments:
lua if not Config.Framework or Config.Framework ~= 'mycore' then return endRegister it for detection
Add your resource to the
frameworksortargetslist at the top ofshared/config.lua—['my_core'] = 'mycore'— or pin it withConfig.Framework = 'mycore'.
What each bridge must provide
Bridge | Functions |
|---|---|
Client framework |
|
Server framework |
It also registers the usable item and the |
Target |
Each option carries |
Languages#
28 translations ship in locales/: Arabic (ar), Bulgarian (bg), Catalan (ca), Czech (cs), Danish (da), German (de), Greek (el), English (en), Spanish (es), Persian (fa), French (fr), Hindi (hi), Hungarian (hu), Italian (it), Japanese (ja), Korean (ko), Dutch (nl), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Slovenian (sl), Swedish (sv), Thai (th), Turkish (tr), Chinese Simplified (zh-CN) and Chinese Traditional (zh-TW). Pick one with Config.Language.
To add your own, copy locales/en.lua to a new file, change its first line to Locales["xx"] = {, translate the values and set Config.Language = 'xx'. Every file in locales/ is loaded on its own. A key your file is missing shows as Translation [xx][KEY] does not exist in place of the text.