The command reached the server and the server said no. Three things are accepted: the ace mechanic.admin (or the blanket command ace), an ESX group of admin or superadmin, or a QBCore/Qbox permission of admin or god. Nine times out of ten the ace is in server.cfg but the server was never restarted after adding it, or the group was granted to a different account from the one in game.

Nothing registered, which means the resource did not finish starting. Read the server console from the ensure line down: a missing oxmysql or ox_lib is the usual cause, and so is a renamed folder. The creator is always /mechanic_creator; it is not renameable. The repair command fix_command is, but only at boot — change it in the panel and restart the resource before expecting the new name to work.

Detection happens once, while this resource boots, by asking whether each known resource is already running. A resource that starts afterwards is invisible to it for the rest of the session, which shows up as an inventory that takes no items, invoices that never arrive, or keys that are never handed over. Fix the order in server.cfg so everything this resource integrates with is ensured above it.

Two resources from the same family running at once has the same effect: detection stops at the first match, and which one that is can change between restarts. One inventory, one billing script, one key system, one clothing script.

That file holds the default for each value. Once a setting has been saved from the panel, the saved value wins and the default is never read again. Change it in the panel instead, or press Reset on that section so it follows the file again.

Escape closes the creator, the tablet and the tuning menu. If it does not, the resource was restarted while the panel was open, which leaves the game holding focus for an interface that no longer exists — rejoining, or restarting the resource again, releases it. Avoid restarting the resource while somebody has the creator open; nothing in it needs a restart to take effect anyway.

This is the single most common message, and it is working as intended. The tablet belongs to somebody attached to a shop: its owner, somebody hired into it with open_tablet, or anybody in the job or gang a job-staffed shop was set to. A player who is none of those gets nothing, wherever they stand.

So check, in order: does a shop exist and is it claimed; is this player the owner or on its roster; and if it is job-staffed, does their job name match exactly. Distance is not a factor — the tablet works from anywhere.

The job name is compared exactly as typed, against the name your framework uses internally — mechanic, not Mechanic and not the label players see. Take it from your own jobs file rather than retyping it. For a gang shop the same applies to the gang name, and the player's gang is what is matched, not their job.

Permissions are per shop and per employee, and the owner implicitly holds all of them, so a misconfigured grade can never lock an owner out of their own shop. Open the tablet's employee list and tick what the role is actually meant to do; an employee can never grant a permission they do not hold themselves.

At a job-staffed shop the rules are fixed instead: everybody in the job gets the day-to-day permissions, only the manager grade and above may withdraw money or change the shop's settings, and managing employees is never available, because a job shop has no roster to manage — the job is the roster.

Deliberate. A shop is staffed one way or the other, never both, and an owner outranks a job — otherwise selling a shop would quietly leave a whole department holding the keys. If you want the job back, clear the owner in the creator.

The client asked before the server had answered, and asking again a second later normally works. If it never stops saying it, the shops are not reaching the client at all: look for a database error in the server console, and make sure oxmysql is ensured above this resource.

The inventory never reached this resource. Check the item definition you added: the export name has to match, and the resource it points at has to be spelled qs-mechanic-creator exactly. An inventory calling an export that does not exist usually fails in silence rather than printing anything, which is why this looks like nothing happening.

The definitions for every supported inventory are on the Inventory Items page.

The name in the panel and the name in your inventory are different strings. The item names a radial action asks for live in Settings → Items, and they default to repairkit, sponge and rope. If your items are called something else, say so there rather than renaming your items.

The jerrycan is the one item whose name genuinely differs between inventories, so its default is chosen from the inventory that was detected: WEAPON_PETROLCAN on ox_inventory, weapon_petrolcan elsewhere. If your server uses a plain item instead of the weapon, put its name in Settings → Items.

On qs-inventory an item defined with removeAfterUse = true is taken by the inventory itself. That is accounted for, so the item is only ever removed once — but it does mean the behaviour follows your item definition. If a kit survives every repair, the definition is not removing it and neither side thinks it should; set removeAfterUse or let this resource take it, not both halves of neither.

Stashes and parts shops belong to the inventory, not to this resource, so each one has to be registered with it. On ox_inventory that happens the moment you save the shop, and a new stash works straight away. Every other inventory is told at boot instead, so a shop created while the server is running has no stash until the resource is restarted once.

If no stash appears even after a restart, no inventory was detected at all, or the one you run does not support registered stashes — codem-inventory is one of those. The console with debug on says which inventory was found.

The blip is drawn at the shop's blip point, falling back to its purchase point and then to its first tuning bay. A shop with none of the three has nothing to anchor a blip to. Place at least one point and save.

Correct. Only the purchase point of a shop that is for sale draws a marker on the ground; every other point is silent until you are close enough for its prompt to appear. It keeps a workshop looking like a workshop instead of a field of coloured cylinders.

Stand or stop where you actually placed the point, not where the lift looks like it is. Points are placed with the freecam, which makes it easy to leave one a metre in the air or inside a wall — move the camera to eye height over the spot before saving it.

A tuning bay also expects a vehicle on it, and a lift expects the vehicle to be stopped. If the prompt appears but the menu refuses, that is a permission or a price, not a placement.

Every prop a shop places sits at the height the point was saved at. Nudge the point rather than the prop. If a prop is missing entirely for one player and present for another, that player is beyond its draw distance or their client has not received the shop yet — rejoining settles it.

Intended. A shop with no owner and no job is the public pay-and-drive tuneshop: anybody may use it, the money leaves the customer, and there is no business behind it to receive it. Give it an owner or a job and it starts taking orders, keeping funds and writing a ledger.

It only asks when there is something to choose. The shop needs at least one Dyno Screen point placed in the creator, and the mechanic has to be within thirty metres of it. With no screen in range the pull simply runs on the tablet, which is why a shop without TVs never sees a dialogue it has no use for.

The picture is drawn only within about eighteen metres of the screen; further out the TV is just a prop, which costs nothing. Walk towards it.

It also takes a couple of seconds to light up at the start of a pull: that pause is the browser being given time to load, and the standby card is what you should see during it. Results then stay on the glass for a minute after the pull ends, and clear when another pull starts.

The screen model stands on something rather than hanging, so its origin is at the foot and not at the glass. Placing one flat against a wall leaves it floating by the height of its stand; drop the point by that much. Run /dynoscreens with debug on and it reports the screens near you, lights the closest one, and prints the panel size it worked out.

No billing resource was detected, so there is nothing to send an invoice through and the charge is taken directly instead. Ensure your billing script above this one and restart. One billing script only — detection stops at the first match.

It never was. Each shop keeps its own funds, with every movement recorded as its ledger, and withdrawals go straight to the player who makes them. There is no society or shared account to look in, and nothing to reconcile with your framework's management script.

An engine has to be bought at the laptop and placed on the pallet before a swap can start. Buy one, carry it out, and put it down on the pallet — the prompt at the laptop and the prompt at the pallet are different steps of the same job.

Swapped engines are stored against the plate, so the plate is what has to stay the same. A garage script that respawns a car with a freshly generated plate loses the link, and so does editing a plate by hand in the database.

Two resources both claiming the tuning menu is the one setup that cannot work: whichever writes last wins, and the result changes between restarts. Remove every other mechanic, tuning and performance script before blaming a setting here.

Wheel damage, heated brakes and the off-road system each have their own section in the settings panel with their own thresholds and their own blacklists, and each can be turned off outright. If a section has been edited into a state you would rather forget, mechanicresetconfig wheeldamage — or heatedbrakes, or offroadsystem — puts it back to the shipped defaults from the server console.

That is the point: damage is kept against the plate so a trip through a garage is not a free repair. If your garage script would rather handle it, it can read and reapply the damage itself through the exports on the Commands and Exports page.

A wash clears it, and so does ForceResetVehicleWheels. To see which surfaces are counting as off-road in the first place, turn debug on and run /debug_offroad_zones.

The command reached the server and the server said no. Three things are accepted: the ace mechanic.admin (or the blanket command ace), an ESX group of admin or superadmin, or a QBCore/Qbox permission of admin or god. Nine times out of ten the ace is in server.cfg but the server was never restarted after adding it, or the group was granted to a different account from the one in game.

Nothing registered, which means the resource did not finish starting. Read the server console from the ensure line down: a missing oxmysql or ox_lib is the usual cause, and so is a renamed folder. The creator is always /mechanic_creator; it is not renameable. The repair command fix_command is, but only at boot — change it in the panel and restart the resource before expecting the new name to work.

Detection happens once, while this resource boots, by asking whether each known resource is already running. A resource that starts afterwards is invisible to it for the rest of the session, which shows up as an inventory that takes no items, invoices that never arrive, or keys that are never handed over. Fix the order in server.cfg so everything this resource integrates with is ensured above it.

Two resources from the same family running at once has the same effect: detection stops at the first match, and which one that is can change between restarts. One inventory, one billing script, one key system, one clothing script.

That file holds the default for each value. Once a setting has been saved from the panel, the saved value wins and the default is never read again. Change it in the panel instead, or press Reset on that section so it follows the file again.

Escape closes the creator, the tablet and the tuning menu. If it does not, the resource was restarted while the panel was open, which leaves the game holding focus for an interface that no longer exists — rejoining, or restarting the resource again, releases it. Avoid restarting the resource while somebody has the creator open; nothing in it needs a restart to take effect anyway.

This is the single most common message, and it is working as intended. The tablet belongs to somebody attached to a shop: its owner, somebody hired into it with open_tablet, or anybody in the job or gang a job-staffed shop was set to. A player who is none of those gets nothing, wherever they stand.

So check, in order: does a shop exist and is it claimed; is this player the owner or on its roster; and if it is job-staffed, does their job name match exactly. Distance is not a factor — the tablet works from anywhere.

The job name is compared exactly as typed, against the name your framework uses internally — mechanic, not Mechanic and not the label players see. Take it from your own jobs file rather than retyping it. For a gang shop the same applies to the gang name, and the player's gang is what is matched, not their job.

Permissions are per shop and per employee, and the owner implicitly holds all of them, so a misconfigured grade can never lock an owner out of their own shop. Open the tablet's employee list and tick what the role is actually meant to do; an employee can never grant a permission they do not hold themselves.

At a job-staffed shop the rules are fixed instead: everybody in the job gets the day-to-day permissions, only the manager grade and above may withdraw money or change the shop's settings, and managing employees is never available, because a job shop has no roster to manage — the job is the roster.

Deliberate. A shop is staffed one way or the other, never both, and an owner outranks a job — otherwise selling a shop would quietly leave a whole department holding the keys. If you want the job back, clear the owner in the creator.

The client asked before the server had answered, and asking again a second later normally works. If it never stops saying it, the shops are not reaching the client at all: look for a database error in the server console, and make sure oxmysql is ensured above this resource.

The inventory never reached this resource. Check the item definition you added: the export name has to match, and the resource it points at has to be spelled qs-mechanic-creator exactly. An inventory calling an export that does not exist usually fails in silence rather than printing anything, which is why this looks like nothing happening.

The definitions for every supported inventory are on the Inventory Items page.

The name in the panel and the name in your inventory are different strings. The item names a radial action asks for live in Settings → Items, and they default to repairkit, sponge and rope. If your items are called something else, say so there rather than renaming your items.

The jerrycan is the one item whose name genuinely differs between inventories, so its default is chosen from the inventory that was detected: WEAPON_PETROLCAN on ox_inventory, weapon_petrolcan elsewhere. If your server uses a plain item instead of the weapon, put its name in Settings → Items.

On qs-inventory an item defined with removeAfterUse = true is taken by the inventory itself. That is accounted for, so the item is only ever removed once — but it does mean the behaviour follows your item definition. If a kit survives every repair, the definition is not removing it and neither side thinks it should; set removeAfterUse or let this resource take it, not both halves of neither.

Stashes and parts shops belong to the inventory, not to this resource, so each one has to be registered with it. On ox_inventory that happens the moment you save the shop, and a new stash works straight away. Every other inventory is told at boot instead, so a shop created while the server is running has no stash until the resource is restarted once.

If no stash appears even after a restart, no inventory was detected at all, or the one you run does not support registered stashes — codem-inventory is one of those. The console with debug on says which inventory was found.

The blip is drawn at the shop's blip point, falling back to its purchase point and then to its first tuning bay. A shop with none of the three has nothing to anchor a blip to. Place at least one point and save.

Correct. Only the purchase point of a shop that is for sale draws a marker on the ground; every other point is silent until you are close enough for its prompt to appear. It keeps a workshop looking like a workshop instead of a field of coloured cylinders.

Stand or stop where you actually placed the point, not where the lift looks like it is. Points are placed with the freecam, which makes it easy to leave one a metre in the air or inside a wall — move the camera to eye height over the spot before saving it.

A tuning bay also expects a vehicle on it, and a lift expects the vehicle to be stopped. If the prompt appears but the menu refuses, that is a permission or a price, not a placement.

Every prop a shop places sits at the height the point was saved at. Nudge the point rather than the prop. If a prop is missing entirely for one player and present for another, that player is beyond its draw distance or their client has not received the shop yet — rejoining settles it.

Intended. A shop with no owner and no job is the public pay-and-drive tuneshop: anybody may use it, the money leaves the customer, and there is no business behind it to receive it. Give it an owner or a job and it starts taking orders, keeping funds and writing a ledger.

It only asks when there is something to choose. The shop needs at least one Dyno Screen point placed in the creator, and the mechanic has to be within thirty metres of it. With no screen in range the pull simply runs on the tablet, which is why a shop without TVs never sees a dialogue it has no use for.

The picture is drawn only within about eighteen metres of the screen; further out the TV is just a prop, which costs nothing. Walk towards it.

It also takes a couple of seconds to light up at the start of a pull: that pause is the browser being given time to load, and the standby card is what you should see during it. Results then stay on the glass for a minute after the pull ends, and clear when another pull starts.

The screen model stands on something rather than hanging, so its origin is at the foot and not at the glass. Placing one flat against a wall leaves it floating by the height of its stand; drop the point by that much. Run /dynoscreens with debug on and it reports the screens near you, lights the closest one, and prints the panel size it worked out.

No billing resource was detected, so there is nothing to send an invoice through and the charge is taken directly instead. Ensure your billing script above this one and restart. One billing script only — detection stops at the first match.

It never was. Each shop keeps its own funds, with every movement recorded as its ledger, and withdrawals go straight to the player who makes them. There is no society or shared account to look in, and nothing to reconcile with your framework's management script.

An engine has to be bought at the laptop and placed on the pallet before a swap can start. Buy one, carry it out, and put it down on the pallet — the prompt at the laptop and the prompt at the pallet are different steps of the same job.

Swapped engines are stored against the plate, so the plate is what has to stay the same. A garage script that respawns a car with a freshly generated plate loses the link, and so does editing a plate by hand in the database.

Two resources both claiming the tuning menu is the one setup that cannot work: whichever writes last wins, and the result changes between restarts. Remove every other mechanic, tuning and performance script before blaming a setting here.

Wheel damage, heated brakes and the off-road system each have their own section in the settings panel with their own thresholds and their own blacklists, and each can be turned off outright. If a section has been edited into a state you would rather forget, mechanicresetconfig wheeldamage — or heatedbrakes, or offroadsystem — puts it back to the shipped defaults from the server console.

That is the point: damage is kept against the plate so a trip through a garage is not a free repair. If your garage script would rather handle it, it can read and reapply the damage itself through the exports on the Commands and Exports page.

A wash clears it, and so does ForceResetVehicleWheels. To see which surfaces are counting as off-road in the first place, turn debug on and run /debug_offroad_zones.