Every script ships with the same bridge layer. It detects what your server runs, picks a target, and tells you which one it picked. Nothing to install, nothing to patch, and the files that do the work are readable.
ESX, QBCore and vRP have a dedicated branch, tested against the real exports. Standalone needs no framework at all, and custom is an empty branch you fill in yourself. Qbox and ox_core run through the standalone or custom path rather than a tested target, and we say so rather than claiming a support we have not verified.
Detection runs at startup and probes the real export, not just whether a resource is started. A framework that boots after us does not pin us permanently: the bridge retries, then gives up and falls back to standalone. Each bridge raises a Ready flag, and the rest of the resource waits on that flag instead of a guessed delay. A guessed Wait once meant that no clothing item registered at all on a slow server.
-- config/config.lua
Config.Framework = 'auto' -- auto | qbcore | esx | vrp | standalone | custom
Config.Notif = 'auto' -- auto | qbcore | esx | oxlib | okok | vrp | standalone | custom
Config.Interact = 'auto' -- auto | avenida_interact | ox_target | qb-target | standalone | custom
Config.Clothing = 'auto' -- auto | qb-clothing | illenium-appearance | fivem-appearance | esx_skin | vrp | standalone-table | custom
Config.Inventory = 'auto' -- auto | ox_inventory | qb-inventory | esx | standalone | customSet Config.Debug = true and restart. The console prints one line per bridge category naming the target that was chosen. Set it back to false once the lines match your server, because the diagnostic commands it unlocks cost a frame hitch.
Replace auto with the name you want. Detection is then skipped entirely for that category, which is what you want on a heavily modified stack where probing gives the wrong answer. The five categories are independent: you can force the framework and leave the notifications on auto.
Every bridge file carries a custom branch with a comment telling you where to plug your own code in. It is never selected automatically, only when you name it, because a fallback that silently lands in an empty branch would be worse than one that lands in standalone.
A hard dependency in the manifest, the @vrp/lib/utils.lua line you see everywhere, stops the resource from starting on every server where vRP is absent. So the bridge talks to the vRP event bus directly. The side benefit is real: the convention differences between vRP forks live in that helper, so going direct removes them all. vRP 2 and vRP 0.5 are not supported, and the resource says so in the console rather than misbehaving quietly.
It runs, through the standalone or custom path, but not through a branch we test against. Qbox is close enough to QBCore that forcing qbcore works on most builds. We would rather write that than claim a support we have not verified.
Nothing breaks. Detection retries rather than pinning a wrong answer on first look, and the resource waits on the bridge Ready flag before touching anything. A resource that is not installed at all is dropped immediately, so other servers do not pay for the wait.
Yes, that is what they are built for. Each one owns its half of the single ped decoration slot and hands the rest back after a redraw. What you must not do is run the separate resources and the bundle at the same time, and the console says so at startup if you do.
No. bridges/compat.lua provides a native implementation of what we use, so ox_lib is picked up when it is there and replaced when it is not. Nothing in the manifest depends on it.
