The recipe downloads Quasar Framework from GitHub (imnotquasar/qs-core) and five pinned dependencies (cfx-server-data twice, bob74_ipl, hospital_map, pma-voice) through GitHub's API, plus oxmysql and ox_lib as release files. When a download_github task fails, it is almost always one of these:

• GitHub rate limit. GitHub allows 60 anonymous API requests per hour per IP address. Several failed attempts in a row, or a shared hosting IP, use them up and the next download is refused. Wait an hour (or deploy from another machine) and run the recipe again.

• Private repository. txAdmin downloads without logging in to GitHub, so a private repository answers as if it did not exist. If you point the recipe at your own fork of qs-core, the fork must be public.

• Network or firewall. The server must be able to reach github.com, api.github.com and raw.githubusercontent.com.

The recipe URL for Setup → Server Deployer → Remote URL Template is:

https://raw.githubusercontent.com/imnotquasar/qs-core/main/qs-recipes/recipe.yaml

qs-core, qs-coreinventory and qs-police declare oxmysql as a dependency, so without it they refuse to start — and every other Quasar Framework resource depends on qs-core. Put oxmysql in resources/[standalone]/oxmysql (the recipe installs 2.14.3) and keep ensure oxmysql above ensure qs-core in server.cfg.

Quasar Framework itself does not use ox_lib. The recipe installs it because many ESX and QBCore scripts load @ox_lib/init.lua, and those scripts fail to start without it. If the console warns that it cannot find ox_lib, either install it in [standalone] or remove ensure ox_lib if none of your scripts need it. pma-voice is the voice chat; without it players cannot talk in proximity. Install it or remove ensure pma-voice.

If [qs-core] Database connection established. never appears, oxmysql could not reach your database. Check the line written by txAdmin (or by you on a manual install):

set mysql_connection_string "mysql://user:password@localhost/database?charset=utf8mb4"

The user, password, host and database name must be correct and MySQL 8.0+ or MariaDB 10.4+ must be running. An error such as Table 'database.players' doesn't exist means the schema was never imported: the recipe does it for you, but on a manual install you import [core]/qs-core/sql/qscore.sql yourself. It creates players, bans, player_colors, player_groups, vehicles, the inventory tables and the banking tables; the ESX bridge creates users and owned_vehicles on its own.

The recipe's server.cfg enforces game build 3751 with sv_enforceGameBuild 3751, the same build as txAdmin's default recipe. Your FXServer artifact must be recent enough to support it — update the artifact if the server refuses to start with that build. Keep the line: several weapons in the catalogue (for example the WM 29 Pistol, Tactical SMG and Battle Rifle) only exist on recent builds, and with a lower build their items equip nothing.

Quasar Framework needs OneSync. Server-side features such as /givemoney, /goto, /bring, the police and EMS proximity checks and server-spawned vehicles read player and vehicle positions on the server, which only works with OneSync. The recipe turns it on; on a manual install enable OneSync in txAdmin's settings.

Resources start in the order of the ensure lines, and the boot flow depends on it: loadingscreen, then qs-intro, then qs-coremulticharacter. If you replace the list with ensure [core], resources start alphabetically and qs-coremulticharacter starts before qs-intro, so the character selection opens without waiting for the intro. Keep the ensure list from the recipe's server.cfg as it is, with ensure [bridge] last and your own scripts after it.

To turn the intro off instead, set Config.Enabled = false in qs-intro/config.lua; the character selection then opens on its own.

qs-corechat replaces FiveM's built-in chat. Make sure server.cfg contains set resources_useSystemChat false and that you do not ensure chat anywhere.

The bridges in [bridge] already answer as es_extended, qb-core, esx_society, qb-management, qb-vehiclekeys, progressbar and LegacyFuel. A second resource with the same name means two cores fighting over the same players, with their own tables, money and inventory. Delete the real es_extended / qb-core folders (and their copies of those resources) and keep only the [bridge] versions. Do not install the real esx_identity either: the ESX bridge already provides esx_identity:registerIdentity and creates characters through Quasar Framework.

That is basic-gamemode (or another gamemode resource) turning on spawnmanager's auto-respawn, which respawns the player before Quasar Framework's downed state can take over. Remove ensure basic-gamemode from server.cfg. Quasar Framework only needs mapmanager and spawnmanager from cfx-server-data, which is all the recipe installs.

Set the language with setr, not set:

setr qs:locale "es"

setr replicates the value to every player. With a plain set, server messages change language but the client side — HUD, inventory, menus, notifications — keeps English. Valid codes are en, es, fr, de, it, pt, pl, ru, tr and ar; anything else falls back to English. Restart the server after changing it. Third-party ESX and QBCore scripts keep their own language settings.

qs-core admin commands check the ACE command.qs of the player who types them. Two things must be true:

1. server.cfg grants it to the admin group: add_ace group.admin command allow (the recipe writes this line).

2. The player is in group.admin. txAdmin adds its master account automatically; add other admins with add_principal identifier.fivem:<id> group.admin in server.cfg, or type setgroup <id> admin in the server console.

The player can check it right away — /setgroup applies the group at once and the player gets You have been set to group: admin. /adminkeys uses the ACE command.adminkeys, which the same add_ace group.admin command allow line covers.

The menu uses the same permission as the admin commands (Config.Permission = 'command.qs' in qs-admin/config.lua). Fix it exactly as for No permission. above.

setgroup and removegroup answer in the server console, not in chat: use them from the console or check its output ([qs-core] Usage: setgroup <serverId> <group> means an argument is missing). A player without command.qs gets no reply at all. qs-core applies groups by running add_principal / remove_principal, so server.cfg must allow the resource to do that:

add_ace resource.qs-core command.add_ace allow
add_ace resource.qs-core command.remove_ace allow
add_ace resource.qs-core command.add_principal allow
add_ace resource.qs-core command.remove_principal allow

/setgroup <id> user or /removegroup <id> removes the group saved by qs-core immediately. A principal written in server.cfg (add_principal identifier.… group.admin) cannot be removed by a command — delete that line and restart. txAdmin's own admin accounts are managed in txAdmin.

/setgroup <id> mod puts the player in group.mod, which only has the permissions server.cfg gives it. Grant it the admin commands with add_ace group.mod command.qs allow, or use admin as the group.

The limit is enforced by Config.MaxCharacters in qs-core/shared/config.lua (default 5). qs-coremulticharacter/config.lua has its own Config.MaxCharacters, which only sets how many slots the selection screen shows. Change both to the same number and restart.

The loading screen is closed by the character selection (or by the intro when it plays), with an automatic fallback 12 seconds after the player spawns. If it stays up or the screen stays black, check in order: qs-coremulticharacter is started; the server console shows Database connection established. (without the database the character list never arrives); F8 shows no script errors; and the ensure order is the one from the recipe.

Leaving the creator confirms the character with the appearance it had at that moment. Nothing is lost: change the look later at any clothing store or barber, or delete the character from the selection screen and create it again.

The downed state is saved with the character, so logging out does not escape it. After 20 seconds the player can press E to respawn at the nearest hospital, or press G to call EMS. Admins can use /revive <id> or the Heal button in the txAdmin menu, which also revives.

Appearance is applied by qs-clothing when the character loads, so it must be started (it is in [core]). In the editor, Cancel or Esc discards the changes; only Save keeps them. A character created while qs-clothing was not running has no saved appearance — open a clothing store, or let an admin use /clothing.

Characters are saved every 5 minutes (Config.SaveInterval), when a player disconnects or logs out, and when qs-core stops. If the server process crashes, changes since the last autosave are lost. Lower Config.SaveInterval in qs-core/shared/config.lua if you want more frequent saves.

Online characters live in memory and are written back on every save, so an SQL edit to players while the player is online is overwritten. Edit characters while they are offline, or use the commands (/addmoney, /setjob, /giveitem) and exports for online players.

The inventory and the item wheel do not open while you are downed — that is intended, and dying closes them. Otherwise check the key: F1 by default, but every player can rebind it in Settings → Key Bindings → FiveM, and a player who bound inventory to another key keeps that key.

For an item to do something it needs two things:

1. Its definition has useable = true (exports['qs-core']:RegisterItem('pizza', { label = 'Pizza', weight = 500, useable = true })). Without it the inventory shows Not usable.

2. Something handles it: exports['qs-core']:RegisterUsableItem(item, handler), an ESX ESX.RegisterUsableItem / QBCore QBCore.Functions.CreateUseableItem, or a listener on qs:server:usedItem. Food and drinks are handled by qs-needs once they are listed in NeedsConfig.Consumables.

The inventory never removes a used item by itself: a consumable handler must remove it. Items are also briefly blocked while a progress bar runs or after many uses in a row.

Shops hide products whose item is not in the catalogue. Register the item first (with RegisterItem, or through the resource that adds it) — icepack and burn_cream, for example, only exist while qs-ambulance is running.

Players carry up to 50 kg (Config.MaxWeight = 50000 grams) in 30 slots (Config.Slots), set in qs-coreinventory/shared/config.lua. Weapons and unique items take a whole slot each; other items stack to 64 unless their definition sets stack.

That is intended: weapons are items, and when the last item of a weapon leaves your inventory — dropped, given, moved to a trunk or stash, sold — the weapon is taken from your hands too. Note that dropping an item destroys it; give it to a player or put it in a stash to keep it.

Intended: each throwable you throw uses one item, and the number you can throw always matches the number of items you carry. Throwables stack to 10.

Ammo items load the weapon in your hands if it matches, otherwise the first weapon of that category you carry: ammo_pistol for pistols, ammo_smg for SMGs, ammo_rifle, ammo_shotgun, ammo_sniper, ammo_mg and so on. Equip a weapon of the right category first. Melee weapons and throwables use no ammo.

The admin menu's Give Weapon and ESX xPlayer.addWeapon give the ped a game weapon, not an item, so it is not saved. Give the weapon item instead: /giveitem <id> weapon_pistol 1, or AddItem / xPlayer.addInventoryItem from a script.

The vehicle is locked or you have no keys means exactly that: the trunk needs the vehicle unlocked and its keys, and the glovebox needs the keys. Open the inventory on foot right behind the vehicle for the trunk, or from a seat for the glovebox.

qs-core always uses qs-coreinventory while it is started. Run qs-inventory instead of it: remove ensure qs-coreinventory from server.cfg and ensure qs-inventory before [bridge]. The console line [qs-core:warn] Inventory backend not available means neither inventory is running.

A driver without the vehicle's keys cannot start it (Config.RequireKeysToDrive). Owned vehicles give you their keys automatically the first time you sit in the driver seat, and so do cars from the dealership, a garage, /car and the admin menu. For any other vehicle: share keys with /givekeys, let an admin use /adminkeys, or hotwire it. Keys are kept for the session, so after reconnecting owned cars hand them out again when you get in.

Hotwiring (G) only works in the driver seat of a vehicle you have no keys for, and needs a lockpick in your inventory (sold at the Hardware Store). A failed attempt breaks the lockpick and sets off the alarm, and the police may be alerted.

The script spawned the vehicle without giving keys. Give them after spawning, on the client with exports['qs-corevehiclekeys']:GiveKeys(plate) or from the server with TriggerClientEvent('vehiclekeys:client:SetOwner', source, plate) — QBCore scripts that already use that event or qb-vehiclekeys work as they are. As a stopgap set Config.RequireKeysToDrive = false in qs-corevehiclekeys/config.lua.

A vehicle belongs to the garage where it was last stored and is listed only there. A vehicle whose garage is not one of the configured garages — every car bought at the dealership, or one stored in a garage you later removed from the config — appears in every garage and can be taken out from any of them; storing it assigns that garage.

A vehicle with that plate exists in the world, so it cannot be taken out twice. Find it, or delete it with /dv and try again. If the car was destroyed, lost or deleted, there is nothing in the world with its plate and it can be taken out again — no impound needed.

Only vehicles owned by your character (in the vehicles table) can be stored. Cars from /car, the admin menu or job garages are not owned by anyone.

/impound removes the vehicle from the world. The owner takes it out again from the garage where it was last stored — or from any garage if it was never stored.

The bundled LegacyFuel bridge only consumes fuel; it has no pumps or jerry cans. Replace it with a fuel script that has gas stations. If that script's resource or export is not LegacyFuel / GetFuel, point the HUD at it with Config.Vehicle.fuelResource and Config.Vehicle.fuelExport in qs-corehud/config.lua.

Paychecks go to the bank every 30 minutes (Config.Paycheck.interval) for every player whose job grade has a salary above 0, with the notification Paycheck received. Check that Config.Paycheck.enabled = true in qs-core/shared/config.lua and that the grade's salary in shared/jobs.lua is not 0. The timer restarts when the server restarts.

The job must exist in qs-core/shared/jobs.lua (or be registered by a script). For an unknown job the console prints [qs-core:error] setJob: invalid job "name" grade "0" and nothing changes. A grade that does not exist falls back to the job's lowest grade.

The accounts are cash, bank and black_money (Config.Accounts). ESX calls cash money, but the qs-core commands use cash: /addmoney 1 cash 500. An unknown account prints [qs-core:error] addMoney: unknown account.

Bank account numbers (QS followed by 9 digits) are created the first time a character opens a bank or an ATM. Ask the recipient to open one once and read you the number shown there.

Shops charge cash (Config.PayAccount = 'cash' in qs-coreshops/config.lua). Withdraw at an ATM, or set it to 'bank'. The dealership tries the bank first and then cash.

The Job Center only lists the jobs named in Config.Center.jobs in qs-jobs/config.lua that also exist in qs-core/shared/jobs.lua. Add the job's name to that list and restart qs-jobs.

Police tools need the job police and EMS tools the job ambulance — the job name, any grade. Set it with /setjob <id> police 0 or from the admin menu.

Something is parked on every delivery van spawn point at the depot. Clear the spot and try again; the deposit was refunded.

The script uses an item or job Quasar Framework does not know: xPlayer.getInventoryItem() returns nil for unknown items, and unknown jobs get generic grades. Define everything the script ships with — items in the qs-core catalogue, in es_extended/config/items.lua (BridgeItems) or qb-core/shared/items.lua; jobs in qs-core/shared/jobs.lua or qb-core/shared/jobs.lua; gangs in qb-core/shared/gangs.lua. Then restart the server.

The script started before the bridges. server.cfg starts [bridge] last on purpose: put every third-party script after the ensure [bridge] line, never before it.

The script calls an inventory resource directly instead of going through the framework. Quasar Framework does not provide ox_inventory or qb-inventory exports, so those calls are not covered. Use a version of the script that uses the framework's item functions (xPlayer.addInventoryItem, Player.Functions.AddItem, QBCore.Functions.HasItem), or adapt those calls to exports['qs-core']:AddItem / RemoveItem / HasItem.

Scripts written only for Qbox (qbx_core, exports.qbx_core) are not supported. Scripts that support QBCore work through the QBCore bridge — pick the QBCore version of the script when there is one.

ESX.UI.Menu needs a menu resource, exactly as on ESX. The console line [es_extended bridge] no menu resource registered for type "default" — install esx_menu_default tells you which one. Install it after [bridge].

Owned vehicles live in qs-core's vehicles table. The ESX owned_vehicles table exists but stays empty and QBCore's player_vehicles does not exist, so scripts that read those tables with SQL see nothing. Use qs-garage and qs-vehicleshop, or adapt the script to exports['qs-core']:GetCitizenVehicles(citizenid) (or GetPlayerVehiclesQBShape for QBCore-shaped rows).

The users table is a copy that qs-core keeps up to date, in one direction only. A script that edits money or jobs there with raw SQL changes nothing in game. Use the framework functions (xPlayer.addAccountMoney, xPlayer.setJob) instead.

On the client, QBCore.Shared.Items contains the items listed in qb-core/shared/items.lua. If a script reads labels from it on the client, add its items to that file.

Weapons are inventory items in Quasar Framework, so xPlayer.getLoadout() is always empty. Check for the weapon item with xPlayer.hasItem('weapon_pistol') or xPlayer.getInventoryItem('weapon_pistol').

Config.Debug = true is the default in qs-core/shared/config.lua and prints extra lines such as every autosave. Set it to false on a live server.

Check the optional world settings in qs-core/shared/config.lua: Config.DisablePeds and Config.DisableTraffic run every frame while they are true, so turn them on only if you need an empty city. The HUD refreshes every 250 ms (Config.UpdateInterval) and the speedometer every 90 ms while driving (Config.Vehicle.interval) in qs-corehud/config.lua; raise those values for lighter clients.

Look for scripts that fetch the player on every tick. QBCore.Functions.GetPlayer rebuilds the player's data from Quasar Framework on every call, and exports['qs-core']:GetPlayer returns a fresh copy each time. Call them when needed — on an event or a command — rather than in a loop every frame.

Restarting qs-core on a live server unloads every character: players stay in the world without a loaded character, and every resource built on it loses them. qs-core saves everyone before it stops, so nothing is lost, but restart the whole server instead — or ask players to reconnect.

The recipe downloads Quasar Framework from GitHub (imnotquasar/qs-core) and five pinned dependencies (cfx-server-data twice, bob74_ipl, hospital_map, pma-voice) through GitHub's API, plus oxmysql and ox_lib as release files. When a download_github task fails, it is almost always one of these:

• GitHub rate limit. GitHub allows 60 anonymous API requests per hour per IP address. Several failed attempts in a row, or a shared hosting IP, use them up and the next download is refused. Wait an hour (or deploy from another machine) and run the recipe again.

• Private repository. txAdmin downloads without logging in to GitHub, so a private repository answers as if it did not exist. If you point the recipe at your own fork of qs-core, the fork must be public.

• Network or firewall. The server must be able to reach github.com, api.github.com and raw.githubusercontent.com.

The recipe URL for Setup → Server Deployer → Remote URL Template is:

https://raw.githubusercontent.com/imnotquasar/qs-core/main/qs-recipes/recipe.yaml

qs-core, qs-coreinventory and qs-police declare oxmysql as a dependency, so without it they refuse to start — and every other Quasar Framework resource depends on qs-core. Put oxmysql in resources/[standalone]/oxmysql (the recipe installs 2.14.3) and keep ensure oxmysql above ensure qs-core in server.cfg.

Quasar Framework itself does not use ox_lib. The recipe installs it because many ESX and QBCore scripts load @ox_lib/init.lua, and those scripts fail to start without it. If the console warns that it cannot find ox_lib, either install it in [standalone] or remove ensure ox_lib if none of your scripts need it. pma-voice is the voice chat; without it players cannot talk in proximity. Install it or remove ensure pma-voice.

If [qs-core] Database connection established. never appears, oxmysql could not reach your database. Check the line written by txAdmin (or by you on a manual install):

set mysql_connection_string "mysql://user:password@localhost/database?charset=utf8mb4"

The user, password, host and database name must be correct and MySQL 8.0+ or MariaDB 10.4+ must be running. An error such as Table 'database.players' doesn't exist means the schema was never imported: the recipe does it for you, but on a manual install you import [core]/qs-core/sql/qscore.sql yourself. It creates players, bans, player_colors, player_groups, vehicles, the inventory tables and the banking tables; the ESX bridge creates users and owned_vehicles on its own.

The recipe's server.cfg enforces game build 3751 with sv_enforceGameBuild 3751, the same build as txAdmin's default recipe. Your FXServer artifact must be recent enough to support it — update the artifact if the server refuses to start with that build. Keep the line: several weapons in the catalogue (for example the WM 29 Pistol, Tactical SMG and Battle Rifle) only exist on recent builds, and with a lower build their items equip nothing.

Quasar Framework needs OneSync. Server-side features such as /givemoney, /goto, /bring, the police and EMS proximity checks and server-spawned vehicles read player and vehicle positions on the server, which only works with OneSync. The recipe turns it on; on a manual install enable OneSync in txAdmin's settings.

Resources start in the order of the ensure lines, and the boot flow depends on it: loadingscreen, then qs-intro, then qs-coremulticharacter. If you replace the list with ensure [core], resources start alphabetically and qs-coremulticharacter starts before qs-intro, so the character selection opens without waiting for the intro. Keep the ensure list from the recipe's server.cfg as it is, with ensure [bridge] last and your own scripts after it.

To turn the intro off instead, set Config.Enabled = false in qs-intro/config.lua; the character selection then opens on its own.

qs-corechat replaces FiveM's built-in chat. Make sure server.cfg contains set resources_useSystemChat false and that you do not ensure chat anywhere.

The bridges in [bridge] already answer as es_extended, qb-core, esx_society, qb-management, qb-vehiclekeys, progressbar and LegacyFuel. A second resource with the same name means two cores fighting over the same players, with their own tables, money and inventory. Delete the real es_extended / qb-core folders (and their copies of those resources) and keep only the [bridge] versions. Do not install the real esx_identity either: the ESX bridge already provides esx_identity:registerIdentity and creates characters through Quasar Framework.

That is basic-gamemode (or another gamemode resource) turning on spawnmanager's auto-respawn, which respawns the player before Quasar Framework's downed state can take over. Remove ensure basic-gamemode from server.cfg. Quasar Framework only needs mapmanager and spawnmanager from cfx-server-data, which is all the recipe installs.

Set the language with setr, not set:

setr qs:locale "es"

setr replicates the value to every player. With a plain set, server messages change language but the client side — HUD, inventory, menus, notifications — keeps English. Valid codes are en, es, fr, de, it, pt, pl, ru, tr and ar; anything else falls back to English. Restart the server after changing it. Third-party ESX and QBCore scripts keep their own language settings.

qs-core admin commands check the ACE command.qs of the player who types them. Two things must be true:

1. server.cfg grants it to the admin group: add_ace group.admin command allow (the recipe writes this line).

2. The player is in group.admin. txAdmin adds its master account automatically; add other admins with add_principal identifier.fivem:<id> group.admin in server.cfg, or type setgroup <id> admin in the server console.

The player can check it right away — /setgroup applies the group at once and the player gets You have been set to group: admin. /adminkeys uses the ACE command.adminkeys, which the same add_ace group.admin command allow line covers.

The menu uses the same permission as the admin commands (Config.Permission = 'command.qs' in qs-admin/config.lua). Fix it exactly as for No permission. above.

setgroup and removegroup answer in the server console, not in chat: use them from the console or check its output ([qs-core] Usage: setgroup <serverId> <group> means an argument is missing). A player without command.qs gets no reply at all. qs-core applies groups by running add_principal / remove_principal, so server.cfg must allow the resource to do that:

add_ace resource.qs-core command.add_ace allow
add_ace resource.qs-core command.remove_ace allow
add_ace resource.qs-core command.add_principal allow
add_ace resource.qs-core command.remove_principal allow

/setgroup <id> user or /removegroup <id> removes the group saved by qs-core immediately. A principal written in server.cfg (add_principal identifier.… group.admin) cannot be removed by a command — delete that line and restart. txAdmin's own admin accounts are managed in txAdmin.

/setgroup <id> mod puts the player in group.mod, which only has the permissions server.cfg gives it. Grant it the admin commands with add_ace group.mod command.qs allow, or use admin as the group.

The limit is enforced by Config.MaxCharacters in qs-core/shared/config.lua (default 5). qs-coremulticharacter/config.lua has its own Config.MaxCharacters, which only sets how many slots the selection screen shows. Change both to the same number and restart.

The loading screen is closed by the character selection (or by the intro when it plays), with an automatic fallback 12 seconds after the player spawns. If it stays up or the screen stays black, check in order: qs-coremulticharacter is started; the server console shows Database connection established. (without the database the character list never arrives); F8 shows no script errors; and the ensure order is the one from the recipe.

Leaving the creator confirms the character with the appearance it had at that moment. Nothing is lost: change the look later at any clothing store or barber, or delete the character from the selection screen and create it again.

The downed state is saved with the character, so logging out does not escape it. After 20 seconds the player can press E to respawn at the nearest hospital, or press G to call EMS. Admins can use /revive <id> or the Heal button in the txAdmin menu, which also revives.

Appearance is applied by qs-clothing when the character loads, so it must be started (it is in [core]). In the editor, Cancel or Esc discards the changes; only Save keeps them. A character created while qs-clothing was not running has no saved appearance — open a clothing store, or let an admin use /clothing.

Characters are saved every 5 minutes (Config.SaveInterval), when a player disconnects or logs out, and when qs-core stops. If the server process crashes, changes since the last autosave are lost. Lower Config.SaveInterval in qs-core/shared/config.lua if you want more frequent saves.

Online characters live in memory and are written back on every save, so an SQL edit to players while the player is online is overwritten. Edit characters while they are offline, or use the commands (/addmoney, /setjob, /giveitem) and exports for online players.

The inventory and the item wheel do not open while you are downed — that is intended, and dying closes them. Otherwise check the key: F1 by default, but every player can rebind it in Settings → Key Bindings → FiveM, and a player who bound inventory to another key keeps that key.

For an item to do something it needs two things:

1. Its definition has useable = true (exports['qs-core']:RegisterItem('pizza', { label = 'Pizza', weight = 500, useable = true })). Without it the inventory shows Not usable.

2. Something handles it: exports['qs-core']:RegisterUsableItem(item, handler), an ESX ESX.RegisterUsableItem / QBCore QBCore.Functions.CreateUseableItem, or a listener on qs:server:usedItem. Food and drinks are handled by qs-needs once they are listed in NeedsConfig.Consumables.

The inventory never removes a used item by itself: a consumable handler must remove it. Items are also briefly blocked while a progress bar runs or after many uses in a row.

Shops hide products whose item is not in the catalogue. Register the item first (with RegisterItem, or through the resource that adds it) — icepack and burn_cream, for example, only exist while qs-ambulance is running.

Players carry up to 50 kg (Config.MaxWeight = 50000 grams) in 30 slots (Config.Slots), set in qs-coreinventory/shared/config.lua. Weapons and unique items take a whole slot each; other items stack to 64 unless their definition sets stack.

That is intended: weapons are items, and when the last item of a weapon leaves your inventory — dropped, given, moved to a trunk or stash, sold — the weapon is taken from your hands too. Note that dropping an item destroys it; give it to a player or put it in a stash to keep it.

Intended: each throwable you throw uses one item, and the number you can throw always matches the number of items you carry. Throwables stack to 10.

Ammo items load the weapon in your hands if it matches, otherwise the first weapon of that category you carry: ammo_pistol for pistols, ammo_smg for SMGs, ammo_rifle, ammo_shotgun, ammo_sniper, ammo_mg and so on. Equip a weapon of the right category first. Melee weapons and throwables use no ammo.

The admin menu's Give Weapon and ESX xPlayer.addWeapon give the ped a game weapon, not an item, so it is not saved. Give the weapon item instead: /giveitem <id> weapon_pistol 1, or AddItem / xPlayer.addInventoryItem from a script.

The vehicle is locked or you have no keys means exactly that: the trunk needs the vehicle unlocked and its keys, and the glovebox needs the keys. Open the inventory on foot right behind the vehicle for the trunk, or from a seat for the glovebox.

qs-core always uses qs-coreinventory while it is started. Run qs-inventory instead of it: remove ensure qs-coreinventory from server.cfg and ensure qs-inventory before [bridge]. The console line [qs-core:warn] Inventory backend not available means neither inventory is running.

A driver without the vehicle's keys cannot start it (Config.RequireKeysToDrive). Owned vehicles give you their keys automatically the first time you sit in the driver seat, and so do cars from the dealership, a garage, /car and the admin menu. For any other vehicle: share keys with /givekeys, let an admin use /adminkeys, or hotwire it. Keys are kept for the session, so after reconnecting owned cars hand them out again when you get in.

Hotwiring (G) only works in the driver seat of a vehicle you have no keys for, and needs a lockpick in your inventory (sold at the Hardware Store). A failed attempt breaks the lockpick and sets off the alarm, and the police may be alerted.

The script spawned the vehicle without giving keys. Give them after spawning, on the client with exports['qs-corevehiclekeys']:GiveKeys(plate) or from the server with TriggerClientEvent('vehiclekeys:client:SetOwner', source, plate) — QBCore scripts that already use that event or qb-vehiclekeys work as they are. As a stopgap set Config.RequireKeysToDrive = false in qs-corevehiclekeys/config.lua.

A vehicle belongs to the garage where it was last stored and is listed only there. A vehicle whose garage is not one of the configured garages — every car bought at the dealership, or one stored in a garage you later removed from the config — appears in every garage and can be taken out from any of them; storing it assigns that garage.

A vehicle with that plate exists in the world, so it cannot be taken out twice. Find it, or delete it with /dv and try again. If the car was destroyed, lost or deleted, there is nothing in the world with its plate and it can be taken out again — no impound needed.

Only vehicles owned by your character (in the vehicles table) can be stored. Cars from /car, the admin menu or job garages are not owned by anyone.

/impound removes the vehicle from the world. The owner takes it out again from the garage where it was last stored — or from any garage if it was never stored.

The bundled LegacyFuel bridge only consumes fuel; it has no pumps or jerry cans. Replace it with a fuel script that has gas stations. If that script's resource or export is not LegacyFuel / GetFuel, point the HUD at it with Config.Vehicle.fuelResource and Config.Vehicle.fuelExport in qs-corehud/config.lua.

Paychecks go to the bank every 30 minutes (Config.Paycheck.interval) for every player whose job grade has a salary above 0, with the notification Paycheck received. Check that Config.Paycheck.enabled = true in qs-core/shared/config.lua and that the grade's salary in shared/jobs.lua is not 0. The timer restarts when the server restarts.

The job must exist in qs-core/shared/jobs.lua (or be registered by a script). For an unknown job the console prints [qs-core:error] setJob: invalid job "name" grade "0" and nothing changes. A grade that does not exist falls back to the job's lowest grade.

The accounts are cash, bank and black_money (Config.Accounts). ESX calls cash money, but the qs-core commands use cash: /addmoney 1 cash 500. An unknown account prints [qs-core:error] addMoney: unknown account.

Bank account numbers (QS followed by 9 digits) are created the first time a character opens a bank or an ATM. Ask the recipient to open one once and read you the number shown there.

Shops charge cash (Config.PayAccount = 'cash' in qs-coreshops/config.lua). Withdraw at an ATM, or set it to 'bank'. The dealership tries the bank first and then cash.

The Job Center only lists the jobs named in Config.Center.jobs in qs-jobs/config.lua that also exist in qs-core/shared/jobs.lua. Add the job's name to that list and restart qs-jobs.

Police tools need the job police and EMS tools the job ambulance — the job name, any grade. Set it with /setjob <id> police 0 or from the admin menu.

Something is parked on every delivery van spawn point at the depot. Clear the spot and try again; the deposit was refunded.

The script uses an item or job Quasar Framework does not know: xPlayer.getInventoryItem() returns nil for unknown items, and unknown jobs get generic grades. Define everything the script ships with — items in the qs-core catalogue, in es_extended/config/items.lua (BridgeItems) or qb-core/shared/items.lua; jobs in qs-core/shared/jobs.lua or qb-core/shared/jobs.lua; gangs in qb-core/shared/gangs.lua. Then restart the server.

The script started before the bridges. server.cfg starts [bridge] last on purpose: put every third-party script after the ensure [bridge] line, never before it.

The script calls an inventory resource directly instead of going through the framework. Quasar Framework does not provide ox_inventory or qb-inventory exports, so those calls are not covered. Use a version of the script that uses the framework's item functions (xPlayer.addInventoryItem, Player.Functions.AddItem, QBCore.Functions.HasItem), or adapt those calls to exports['qs-core']:AddItem / RemoveItem / HasItem.

Scripts written only for Qbox (qbx_core, exports.qbx_core) are not supported. Scripts that support QBCore work through the QBCore bridge — pick the QBCore version of the script when there is one.

ESX.UI.Menu needs a menu resource, exactly as on ESX. The console line [es_extended bridge] no menu resource registered for type "default" — install esx_menu_default tells you which one. Install it after [bridge].

Owned vehicles live in qs-core's vehicles table. The ESX owned_vehicles table exists but stays empty and QBCore's player_vehicles does not exist, so scripts that read those tables with SQL see nothing. Use qs-garage and qs-vehicleshop, or adapt the script to exports['qs-core']:GetCitizenVehicles(citizenid) (or GetPlayerVehiclesQBShape for QBCore-shaped rows).

The users table is a copy that qs-core keeps up to date, in one direction only. A script that edits money or jobs there with raw SQL changes nothing in game. Use the framework functions (xPlayer.addAccountMoney, xPlayer.setJob) instead.

On the client, QBCore.Shared.Items contains the items listed in qb-core/shared/items.lua. If a script reads labels from it on the client, add its items to that file.

Weapons are inventory items in Quasar Framework, so xPlayer.getLoadout() is always empty. Check for the weapon item with xPlayer.hasItem('weapon_pistol') or xPlayer.getInventoryItem('weapon_pistol').

Config.Debug = true is the default in qs-core/shared/config.lua and prints extra lines such as every autosave. Set it to false on a live server.

Check the optional world settings in qs-core/shared/config.lua: Config.DisablePeds and Config.DisableTraffic run every frame while they are true, so turn them on only if you need an empty city. The HUD refreshes every 250 ms (Config.UpdateInterval) and the speedometer every 90 ms while driving (Config.Vehicle.interval) in qs-corehud/config.lua; raise those values for lighter clients.

Look for scripts that fetch the player on every tick. QBCore.Functions.GetPlayer rebuilds the player's data from Quasar Framework on every call, and exports['qs-core']:GetPlayer returns a fresh copy each time. Call them when needed — on an event or a command — rather than in a loop every frame.

Restarting qs-core on a live server unloads every character: players stay in the world without a loaded character, and every resource built on it loses them. qs-core saves everyone before it stops, so nothing is lost, but restart the whole server instead — or ask players to reconnect.