Garage Integration

This update saves confirmed tuning in the same vehicle record that your garage uses. This happens before the vehicle is parked. Simply trying a colour or a part in the preview does not save a purchase.

Use your host's file editor or your usual code editor. Each framework guide shows exactly which block to find and what to paste in its place.

1. Choose your framework

The vehicle functions read a car's colours and parts, then put them back on the car. The official versions checked below need the additions shown in their guides.

These paths were checked in the official repositories on 11 September 2026. The linked instructions use those original files.

Current ESX owners: the functions are in esx_lib. Your garage still uses ESX.Game.GetVehicleProperties(vehicle) and ESX.Game.SetVehicleProperties(vehicle, props). ESX forwards those calls to esx_lib.

Qbox owners: edit ox_lib's vehicle functions. Keep qbx_core as it is.

If you are unsure which framework you use, check which resource your server starts: es_extended means ESX, qb-core means QBCore, and qbx_core means Qbox.

You can find the version in the resource's fxmanifest.lua on the line starting with version. Even when the number matches, compare the blocks before replacing them: servers can have edited files. If your ESX has no esx_lib folder, use instructions matching that older ESX version from support.

2. Back up and update

1. Stop the server.
2. Back up your database and the resource folders you will update. Keep the copies outside the server's resources folder.
3. Update sky_base, sky_jobs_base and sky_mechanicjob together. Follow Installation and keep your server's settings.
4. Continue with the vehicle-function changes below.

With the normal Config.AutoExecuteQuery = true setting, Mechanic prepares its extra database column when it starts. If you disabled this setting, import the updated Mechanic import.sql before starting the server.

Your existing vehicles stay in their usual database table:

ESX calls this column vehicle. Keep that name; you do not need to add a mods column. Mechanic's additional features, such as Stancer, Nitro and custom handling, keep their own data.

3. Copy the changes for your framework

Open the guide for your setup:

Each guide tells you:

1. Which file to open.
2. Which existing block to find with Ctrl+F.
3. Which replacement block to copy over it.
4. When to save the file and return here.

Complete every step in your guide. Both reading and applying the saved vehicle data matter. If a replacement is already present, skip that step. If the shown code does not match your file, send the file and version to support instead of guessing where it belongs.

ESX/QBCore servers that only use ox_lib for menus do not need the ox_lib vehicle changes. If your garage also uses ox_lib for vehicle data, read the MSK/custom-setup notes below.

4. Using MSK Garage?

The vendor's MSK Garage 5.6.0 documentation describes these setups:

MSK 5.6.0 also requires msk_core 4.0.0 or newer. See the vendor's 5.6.0 update instructions and database guide.

On ESX: complete the ESX guide. On Qbox: complete the ox_lib guide. Keep the normal vehicle calls supplied with your matching MSK version.

On QBCore with MSK 5.6.0: have this combination checked by Sky support before using it. MSK uses the ox_lib save format while Mechanic's default QBCore adapter uses the QBCore format. Those formats need to be matched in the integration, including vehicle extras. The copy-and-paste field additions alone do not configure that conversion.

The older propertiesApplied colour replacement is not an instruction for every MSK version. The current garage implementation was not available for a source-code check; the table above is based on MSK's official documentation. If colours are still wrong, send your MSK version, client/nui.lua and client/vehicles.lua to support so the change matches your actual files.

5. Start the server and test

Keep your normal start order. Your framework and database driver must start before sky_base, then sky_jobs_base, then sky_mechanicjob. For Qbox, start ox_lib before qbx_core.

Use a vehicle that belongs to a player:

1. Buy and confirm a clear colour change and a tuning part in Mechanic.
2. Park the vehicle in your garage.
3. Take it out and check the colour before entering the vehicle.
4. Enter the vehicle. Its colour and parts should stay the same.
5. Park and take it out once more.
6. Repeat with a custom RGB colour, then change back to a normal colour. Also test matte/metallic paint, wheels, lights, liveries and a performance upgrade.

Also check fuel and damage. If possible, have another player look at the car too. If custom RGB headlights look different to that player, include this in your support report: saving the colour alone does not synchronize it between players.

For an older tuned vehicle, take it out, let its existing tuning load, check it, then save or park it through the updated setup. Mechanic keeps a backup of its old saved data during the change. Keep the existing Mechanic database table.

Something still does not work

If you need support, include your framework version, ox_lib version if used, garage name/version, the full console error and whether the problem appears before or after entering the car.

Details for custom setups

Most owners can stop after the steps above. These details are for the person maintaining custom garage code or renamed database tables.

Which functions are changed?

ESX's es_extended/client/compat.lua maps its existing ESX.Game calls to xLib.game. For Ox, keep exports.ox_lib:getVehicleProperties(vehicle) and exports.ox_lib:setVehicleProperties(vehicle, props). Editing ox_lib/init.lua is not part of this fix.

In the checked official versions, ESX/QBCore need paint types and separate liveries added. Their setters also need the colour/reset fixes. The Ox getter already captures paint types and separate liveries; its addition is custom RGB headlights. Its setter needs the paint and headlight fixes. The framework guides include the affected extra and toggle fields. Do not copy Sky function bodies into framework core files.

Custom garage saving

Qbox keeps qbx_vehicles:SaveVehicle and its existing vehicle ID. Do not paste either Sky vehicle-property function into qbx_core.

With qb-garages, keep its normal qb-mechanicjob:server:SaveVehicleProps event. Sky Mechanic handles that parking save when qb-mechanicjob is not running.

If a custom garage uses different vehicle functions from Mechanic, check both implementations and their saved-data format. Use the same format when saving and spawning the vehicle. In particular, QBCore uses booleans for extras while Ox uses 0 for enabled and 1 for disabled.

For renamed tables or columns, the server adapter is sky_base/config/vehicle_storage.lua. Both the garage and Mechanic must use the same vehicle record. Garages with a separate vehicle cache also need that cache updated; the included Quasar adapter uses updatePersistentVehicleProps.

For database checks, confirmed tuning must already be present in owned_vehicles.vehicle or player_vehicles.mods before parking. Old Mechanic data is backed up in legacy_properties; /migrate imports into Mechanic and is not a command to move all old tuning into the garage table.

After updating your framework or ox_lib later, check whether its vehicle file still contains the fixes. Use the matching guide again if the update replaced them. Keep Fake Plate Integration configured if you use fake plates.

Official source references

Checked on 11 September 2026:

• ESX 1.15.2 vehicle functions and ESX compatibility calls.
• QBCore 1.3.0 vehicle functions.
• Overextended ox_lib 3.39.0 vehicle functions.

Related pages

• Installation
• Tuning and Orders
• Vehicle Systems
• Troubleshooting