Choose recovery behavior before selecting a tow resource
An NPC towing job, a player-requested recovery and police impound are different workflows. Define who requests service, who may accept it, which vehicles may be moved and what happens at the destination. A flatbed animation alone does not establish any of those rules.
List the framework, phone or dispatch, vehicle keys, garage and billing integrations your server uses. Ask which versions the author supports. Keep visual loading, job logic and persistent ownership as separate acceptance paths.
A version-specific qb-towjob configuration example
This guide reviews qb-towjob commit fc72ec04b38d9a3a98bf5f8774ff5f0f23b0569b. Its config selects target use from the UseTarget convar, sets BailPrice to 250, lists flatbed as a job vehicle and separates main, vehicle, dropoff and towspots locations. These are settings for this resource, not universal towing-script options.
The QBCore documentation describes player and NPC calls, a phone service path and radial-menu control of NPC work. Verify those integrations against your installed version instead of assuming every fork registers the same menus or commands.
Treat the deposit and mission reward as different economic settings. Do not label a deposit value as a guaranteed payout. For a configuration change, define the intended charge and refund behavior and test the actual transaction result on staging.
A permitted truck still needs attachment testing
The reviewed client attachment path uses a bodyshell bone and explicit offsets. That makes the geometry a separate concern from the vehicle list. Adding a custom truck’s model name to configuration does not establish that its bed, bones and attachment position match those assumptions.
Test the intended truck and target vehicle together. Record the model names, package versions and exact attach-and-release sequence. Compare a known baseline truck with the custom one before changing several scripts or offsets at once.
A large vehicle, unusual wheelbase or different bed height may require a different supported implementation. Do not present one offset set as a universal fix. This guide has not measured custom-truck compatibility or run the attachment code in FiveM.
Test the full towing journey with an observer
The following is a proposed acceptance matrix. Use a second test player to observe the shared vehicle state, and define the expected behavior from your actual package and server policy.
| Stage | What to verify |
|---|---|
| Job access | Only intended characters can start or accept work |
| Truck checkout | Correct vehicle, keys and deposit behavior |
| Attachment | Target sits in the intended position without unintended collision |
| Transport | Driver and observer see the expected shared state |
| Release | Target detaches and can be used according to policy |
| Drop-off | Destination and completion conditions match the mission |
| Reconnect or restart | Required job, vehicle and saved state recover as designed |
Keep impound and ownership separate from physical movement
Moving a vehicle onto a truck and storing it in an impound database are different operations. If the workflow includes impound, identify which resource updates ownership or storage state and which interface lets the owner retrieve it.
Use a synthetic staging vehicle and record the expected identifier before towing. Compare its state before transport, after handoff and after retrieval. A physically delivered vehicle does not prove the garage or impound system recorded the correct result.
For interrupted work, define what should happen to deposits, the tow truck and the recovered vehicle. Test a cancelled job and a reconnect during the intended workflow. These scenarios need explicit policy rather than assumptions based on a successful demonstration clip.
Diagnose the first failing layer
If the job interface is missing, inspect role access, resource startup and the configured interaction path. If the menu works but attachment fails, inspect the actual truck/target pair and client error. If delivery succeeds but payment or retrieval fails, follow the owning server-side integration.
Retain the first relevant error, exact resource revision and smallest reproduction. Do not change saved vehicle records with SQL from an unrelated garage tutorial. Keep credentials and private player data out of public support reports.
Use the vehicle-resource guide for model checks and the mechanic guide for the repair workflow after recovery. This page does not establish compatibility with GTA VI or benchmark a commercial tow script.
Questions, answered.
Does adding a custom truck to the vehicle list make towing work?
Not by itself. Verify attachment bones, offsets and the complete transport-and-release behavior for the actual truck and target vehicle.
Is towing the same as impounding a vehicle?
No. Physical movement and persistent impound or garage state are separate operations to integrate and test.
Is qb-towjob configuration universal across frameworks?
No. The example is pinned to a QBCore resource revision. Match your framework, fork and supporting integrations.
Sources & editorial notes
Source review: November 7, 2026. Platform announcements can change. This guide separates published facts from Magnate’s original analysis and preparation advice.
- QBCore — Pinned qb-towjob configuration Target selection, job vehicle, deposit and location configuration; reviewed November 7, 2026.
- QBCore — Pinned qb-towjob client attachment flow Attachment bone and offsets; source review, not a custom-truck compatibility test.
- QBCore — Towing job documentation Player and NPC call workflow; match to the installed resource version.
Published by an independent editorial brand. Read our editorial standards.
