Documentation
Frameworks, targets, clothing resources and inventories supported by the Outfit Bag, how each is detected, how outfits persist, and how to add your own bridge.
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.
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.
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 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 |
|
|
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.
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.
Frameworks live in client/custom/framework/ and server/custom/framework/, targets in client/custom/targets/. Copy the file closest to what you run and give it a new name.
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:
if not Config.Framework or Config.Framework ~= 'mycore' then return endAdd your resource to the frameworks or targets list at the top of shared/config.lua — ['my_core'] = 'mycore' — or pin it with Config.Framework = 'mycore'.
Bridge | Functions |
|---|---|
Client framework |
|
Server framework |
It also registers the usable item and the |
Target |
Each option carries |
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.