onex-bodyAttachments auto-detects the active framework and inventory system on your server. No manual wiring is required — the resource checks which resources are running and routes to the appropriate adapter automatically.
Unlike most scripts, there is nothing to configure here. Detection order is fixed in code, there is no database to install, and no dependency beyond the FiveM server itself.
| Symbol | Meaning |
|---|---|
| ✅ | Supported — works out of the box |
| ☑️ | Supported — requires configuration |
| ⚠️ | Partial — limited functionality |
| ⛔ | Not supported |
The framework is used for exactly two things: resolving the player's job (for job-gated profiles) and checking admin permission for the editor. Everything else in the resource is framework-agnostic.
Detected in a fixed order — the first resource found running wins.
| Order | System | Status | Notes |
|---|---|---|---|
| 1 | qbx_core | ✅ | Player data loaded directly from qbx_core/modules/playerdata.lua |
| 2 | qb-core | ✅ | Auto-detected via GetCoreObject() |
| 3 | es_extended | ✅ | Auto-detected via getSharedObject() |
| — | Standalone | ⚠️ | Fallback — no job source, see below |
This order is not configurable. If you run both qbx_core and qb-core, qbx wins.
On standalone, every player reports as unemployed. Job-gated profiles simply never match — the resource still works fully, you just can't gate anything by job. Editor admin must be granted via ACE (see Admin Access).
Job changes are picked up instantly from framework events (QBCore:Client:OnJobUpdate, esx:setJob, and equivalents), with a hydration fallback that self-heals if a resource restarts mid-session.
The inventory layer answers three questions for each attachable object:
Each inventory is a drop-in adapter with a numeric priority. The highest-priority adapter whose detection passes is used, and the result is cached.
| System | Priority | Status | Notes |
|---|---|---|---|
| ox_inventory | 100 | ✅ | Detected on resource state — wins over the framework adapters |
| qb-inventory | 60 | ✅ | Used on qb / qbx. Includes a self-healing re-seed for forks |
| esx (default) | 60 | ✅ | Weapons read from the ped loadout, items from the inventory |
| Standalone | 0 | ⚠️ | Weapons only — items are never detected, see below |
ox_inventory takes precedence. It detects on resource state independently of the framework, so a qb-core server running ox_inventory resolves to the ox adapter, not qb-inventory. This is intentional — ox owns the item data on those servers.
⚠️ Standalone cannot support item objects. With no inventory resource running, there is nothing to query for items, so objects of type item never appear. Objects of type weapon (read from the ped loadout) and manual (toggled by command) work normally.
⚠️ esx reads weapons from the ped, which assumes the default esx loadout behaviour. If your esx server uses a custom item-based weapon inventory, weapons won't be detected — add an adapter for it (see Adding Your Inventory).
All three real inventory adapters push updates rather than polling: they keep a local ownership mirror synced from inventory events, so props appear and disappear the moment an item changes hands. Config.UpdateInterval (default 300ms) is only a safety poll — the standalone adapter is the one case that relies on it.
Copy _framework/lib/inventory/_template.lua, fill in the four functions, and drop it into _framework/lib/inventory/. Nothing else needs editing — the registry picks it up automatically. The template's comments explain each function and how to choose a priority.
The entire _framework/ tree is escrow-ignored, so these files stay editable on escrowed builds.
No database required. There is no oxmysql or MySQL dependency of any kind.
| Data | Stored in | Notes |
|---|---|---|
| Definitions (objects, slots, groups) | data/definitions.json | Written on admin save |
| Weapon model overrides | data/weapons.json | Written on admin save |
| Player preferences & hidden objects | KVP | One key per player, for atomic writes |
Players are keyed by their license: identifier, falling back to their server ID if no license is present.
Two independent paths grant editor admin — ACE is checked first, then job name.
| Method | Config key | Default |
|---|---|---|
| ACE permission | Config.Editor.AcePermission | onex-bodyAttachments.editor |
| Framework job | Config.Editor.AdminJobs | { "admin" } |
On standalone, the job path is unavailable (everyone is unemployed), so ACE is the only way to grant admin.
| Requirement | Notes |
|---|---|
| FiveM server build 7290+ | |
| OneSync | Required for prop sync between players |
Nothing else. No framework, no inventory, and no database is strictly required — the resource runs standalone with the limitations noted above.
Last updated about 5 hours ago