Framework & Bridges

All the framework-specific code is tucked into bridge/, so the rest of the script never has to care whether you're on QBox or ESX. There are three bridges.

framework.lua

Identity, money, vehicle spawning, vehicle value, notifications. It auto-detects qbx_core or es_extended at boot and exposes a plain Framework.* table the rest of the code calls.

storage.lua

This is the interesting one. Instead of inventing its own table, the garage writes into the framework's existing owned-vehicles table:

• QBox → player_vehicles. Nothing to add — it already has garage, state (0 out / 1 stored / 2 impounded), fuel, engine, body, mods and coords. Reads and writes go through the qbx_vehicles exports.
• ESX → owned_vehicles. Fuel, health and mods already live inside the vehicle JSON blob. The garage adds three columns (parking, pound, last_position) via the migration so it can remember which garage a car is in, whether it's impounded, and where to put it back.

Because it uses the native tables, cars you buy from a dealer or another shop just show up — no syncing required.

fuel.lua

A thin adapter over the common fuel scripts: ox_fuel, LegacyFuel, cdn-fuel, ps-fuel, qb-fuel, lj-fuel, with a native fallback. It auto-detects which one is running, or you can name it in Config.Server.FuelResource. Adding your own is a one-line entry.

keys.lua

Same idea for vehicle keys: adapters for qbx_vehiclekeys, wasabi_carlock, qb-vehiclekeys, mk_vehiclekeys and Renewed-Vehiclekeys, picked automatically or set with Config.Keys. Set it to 'none' if something else already handles keys, or add your own adapter at the top of the file.