An addon car on FiveM is a resource with the vehicle's model and textures in a stream folder and four or five meta files - vehicles.meta, carvariations.meta, carcols.meta, handling.meta, sometimes vehiclelayouts.meta - registered with data_file lines in fxmanifest.lua. It gets its own spawn name and sits beside the base game's cars. A replace car is simpler: you stream a file with the same name as a base-game model, and the original is gone everywhere, traffic included. Addons are the right default. The things that go wrong are names that do not match between files, two cars claiming the same modkit ID, and packs so large that every new player waits ten minutes to join. This guide covers the resource layout, each meta file, the fields that must agree, sizing, framework integration and the errors you will see.
Addon or replace#
| Addon | Replace | |
|---|---|---|
| Spawn name | Its own, such as rmodgtr | A base model's, such as adder |
| Meta files | Required | Optional, for handling only |
| Original car | Still there | Gone, including in traffic |
| Risk | Name and modkit conflicts | Every instance of that model changes |
| Use for | Almost everything | Police fleets, deliberate overhauls |
A replace works because FiveM streams by file name: a resource that ships adder.yft, adder_hi.yft and adder.ytd overrides the game's own Adder for every player. That is exactly what you want for, say, replacing the base police cruisers with a consistent fleet - every NPC cop car changes too. It is exactly what you do not want for a dealership car, because the Adder in traffic and in every script that spawns one becomes your custom model.
Addons add a new model with its own name, so nothing in the base game changes and scripts spawn it by that name. The cost is the meta files, which is where most installation problems live.
The resource layout#
A single addon car:
resources/[vehicles]/rmodgtr/ fxmanifest.lua data/ vehicles.meta carvariations.meta carcols.meta handling.meta stream/ rmodgtr.yft rmodgtr_hi.yft rmodgtr.ytdfx_version 'cerulean'game 'gta5'files { 'data/**/*.meta',}data_file 'HANDLING_FILE' 'data/**/handling.meta'data_file 'VEHICLE_METADATA_FILE' 'data/**/vehicles.meta'data_file 'CARCOLS_FILE' 'data/**/carcols.meta'data_file 'VEHICLE_VARIATION_FILE' 'data/**/carvariations.meta'data_file 'VEHICLE_LAYOUTS_FILE' 'data/**/vehiclelayouts.meta'The files block makes the meta files available to clients; the data_file lines tell the game what each one is. The ** glob lets one manifest cover a pack where every car has its own sub-folder under data/, which is how most combined packs are built. A data_file line pointing at a file that does not exist is harmless, so packs often include the layouts line whether or not any car uses one.
The streamed files: .yft is the model, _hi.yft the high-detail version used close up, .ytd the textures. Some cars add a +hi.ytd for close-up textures and separate .ytd files for modkit parts. Any file in stream is registered automatically - the general rules for streamed content are in FiveM MLOs and streaming assets.
Add it to server.cfg with ensure rmodgtr, after the framework and before anything that needs to spawn it.
vehicles.meta: the names that must agree#
vehicles.meta defines the vehicle. Most problems come from a handful of fields that have to match other files exactly:
| Field | Must match |
|---|---|
modelName | The .yft file name, without extension |
txdName | The .ytd file name, without extension |
handlingId | handlingName in handling.meta |
gameName | The text label for the display name |
vehicleMakeName | The text label for the manufacturer |
<Item> <modelName>rmodgtr</modelName> <txdName>rmodgtr</txdName> <handlingId>RMODGTR</handlingId> <gameName>RMODGTR</gameName> <vehicleMakeName>NISSAN</vehicleMakeName> <type>VEHICLE_TYPE_CAR</type> <vehicleClass>VC_SPORT</vehicleClass> <layout>LAYOUT_STANDARD</layout></Item>type and vehicleClass decide how the game treats it: VEHICLE_TYPE_BIKE for a motorcycle, VC_EMERGENCY puts it in the emergency class, and so on. layout decides seat positions and entry animations; custom layouts come from vehiclelayouts.meta.
The spawn name is modelName. The display name in garages and the vehicle HUD comes from the text label in gameName, and an addon car whose label is never defined shows as NULL or as the raw label. Define it on the client:
CreateThread(function() AddTextEntry("RMODGTR", "GT-R R35")end)handling.meta, carcols.meta and emergency fleets#
handling.meta defines how the car drives. Its handlingName must equal the handlingId from vehicles.meta, and handling names are global: two cars with the same handling name share one entry, and whichever loaded last wins for both. That is how a sedan ends up accelerating like a hypercar.
<Item type="CHandlingData"> <handlingName>RMODGTR</handlingName> <fMass value="1750.000000" /> <fInitialDragCoeff value="8.500000" /> <fInitialDriveForce value="0.340000" /> <fInitialDriveMaxFlatVel value="168.000000" /> <fBrakeForce value="1.100000" /> <fTractionCurveMax value="2.650000" /></Item>Creators tune handling for single-player fun, which on a roleplay server usually means far too fast. Tuning a whole fleet to consistent values is normal, and the fields above - mass, drive force, top speed, brakes, grip - are where to start. Change one value at a time and test.
carcols.meta holds the car's modkit: the list of tuning parts and the kit ID that carvariations.meta refers to.
<Kits> <Item> <kitName>4517_rmodgtr_modkit</kitName> <id value="4517" /> <kitType>MKT_SPECIAL</kitType> </Item></Kits><kits> <Item>4517_rmodgtr_modkit</Item></kits>A simple way to audit: search every carcols.meta for <id value= and sort the results. Duplicates are the cars to fix. Change the ID in carcols.meta, and keep the kit name in carvariations.meta consistent with the new kitName.
Size: the cost every player pays#
Every new player downloads every streamed vehicle before they can play, and the client keeps the textures of cars around it in memory. Addon cars vary enormously in size: a well-made car is a few megabytes, a car ripped with 4K textures on every surface can be thirty or more. FXServer warns at startup about any asset above 16 MiB of physical memory:
Asset rmodgtr.ytd uses 24.0 MiB of physical memory. Oversized assets can and WILLlead to streaming issues (such as models not loading/rendering).On a server with three hundred cars, a few oversized ones in a busy car park are enough to make textures fail to load for everyone standing there.
How to keep a fleet manageable:
- Sort your `stream` folders by size. The top twenty files are usually most of the total.
- Shrink oversized textures. Opening the
.ytdand resizing large textures to 2048 or 1024 usually halves a car's size with no visible difference in a car park. - Cut the fleet. Most servers carry cars nobody owns. Your database knows which models players actually have; the rest are download cost for nothing.
- Split by purpose.
[vehicles-emergency],[vehicles-dealer],[vehicles-donor]- separate resources are easier to measure and to remove than one 4 GB "carpack".
Resource count itself is not a performance problem for cars: they have no scripts and cost nothing on the server's main thread. The cost is download and client memory. How to measure the scripted side is in FiveM server performance.
Emergency vehicles, liveries and extras
Police, EMS and fire fleets are the most common reason a roleplay server adds vehicles at all, and they bring three extra things to manage.
Liveries. Most emergency packs ship several liveries per car - departments, ranks, unmarked versions - either as texture variations inside the model or as livery entries in the meta. A script or a garage selects one with the SetVehicleLivery native. If a livery menu shows the wrong number of options, the model and the meta disagree about how many there are.
Extras. Lightbars, push bars, equipment and partitions are often modelled as extras, numbered parts switched on and off with SetVehicleExtra. Department garages usually set a fixed combination per vehicle so the fleet looks consistent. Extras that are missing in game are a model question, not a script one.
Sirens. Light patterns live in carcols.meta as siren settings, and like modkits they are identified by number. Two packs that use the same siren setting ID conflict, and one car flashes with the other's pattern. When merging emergency packs from different creators, audit siren IDs the same way as modkit IDs.
Emergency packs are also where replace-versus-addon gets interesting. Replacing the base police cars means NPC police and dispatched units use your fleet too, which some servers want for consistency. Most roleplay servers prefer addons, so player police have their own vehicles and ambient police keep the base ones, and they then turn ambient police dispatch off with their own scripts.
Making the framework aware of the car#
Streaming the car makes it spawnable by name. Dealerships, garages and admin menus need to know it exists.
- QBCore keeps its vehicle list in a shared Lua file in
qb-core(shared/vehicles.luain recent versions), one entry per model with its name, brand, price, category and shop. A car missing from it cannot be bought and may not be stored in garages. - ESX dealerships traditionally read a
vehiclestable in the database, with model, name, price and category. Add rows with SQL or through phpMyAdmin. - Qbox keeps a shared vehicle list in its own core; check the current repository for the exact location, since it has moved between releases.
Owned vehicles are stored per player in the database (owned_vehicles on ESX, player_vehicles on QBCore) with the model name or hash. Removing a car from the server leaves those rows behind, and garages then fail when a player tries to take out a model that no longer exists. When you retire a car, decide what owners get - a refund, a replacement model - and update the rows rather than leaving broken entries. FiveM databases and oxmysql covers working with those tables safely, and a backup before any bulk change is not optional.
If you run sv_entityLockdown, vehicles must be created on the server. Modern garages already do this; an old dealership that spawns its preview car on the client will stop working. OneSync and player slots has the server-side pattern.
Game build, sources and licensing#
Some addon cars use parts of base-game vehicles from recent GTA Online updates. They only work on a server that enforces at least that game build with sv_enforceGameBuild. A car that crashes clients on spawn or appears without wheels is often a build mismatch; the creator should state the required build.
Where cars come from matters too. Many free "addon packs" are models ripped from other racing games, which is someone else's intellectual property. Cfx.re's rules forbid selling access to content you do not have the rights to, and paid resources are distributed through Cfx.re's escrow system tied to the buyer's account - FiveM escrow and asset licensing explains how that works and why leaked packs are a risk to your licence key. Donor vehicles are a particular trap; read monetising a game server within the rules before putting a car behind a payment.
Installing a car without downtime#
Adding a car does not need a full server restart:
- Upload the resource folder. On RE:NODE, drag a zip into the file manager and it is unpacked in place, or upload over SFTP for a big pack.
- Add
ensure rmodgtrtoserver.cfgso it survives the next restart. - In the console, run
refresh, thenensure rmodgtr. - Players already online receive the new files; some meta changes only take full effect after they reconnect.
- Spawn it once with an admin command and check textures, handling, tuning and the display name before announcing it.
Back up first if the pack touches meta files of existing cars, and test merged packs on a copy of the server rather than live; a broken carcols.meta can crash every client that enters a mod shop.
Troubleshooting#
"Model does not exist" or nothing spawns. The spawn name does not match modelName, the resource is not started, or the data_file lines do not point at the meta files. IsModelInCdimage(GetHashKey("rmodgtr")) on the client tells you whether the game knows the model.
The car spawns without textures. txdName does not match the .ytd file name, or the .ytd is oversized and failing to stream.
It drives like a stock car. handlingId and handlingName do not match, or the handling file is not registered. Or another car uses the same handling name.
The tuning menu shows the wrong parts or crashes. Duplicate modkit IDs between two cars.
The name shows as NULL. No AddTextEntry for the gameName label.
Clients crash when the car appears. A broken model, an oversized asset, or a game build lower than the car needs.
FAQ#
What is the difference between addon and replace cars in FiveM?
An addon car is a new model with its own spawn name and meta files, alongside the base game. A replace car overrides a base model of the same name, so every instance of that vehicle - traffic included - becomes the custom one.
Do I need all the meta files for an addon car?
You need vehicles.meta and usually carvariations.meta, carcols.meta and handling.meta. vehiclelayouts.meta only when the car has a custom layout. Each must be listed in files and registered with a data_file line.
How many addon cars can a FiveM server have?
There is no fixed number. The practical limit is total download size and client memory, not server CPU. Hundreds work if each car is reasonably sized; a few dozen oversized ones can cause texture loss on their own.
Why do two of my cars have each other's tuning parts?
They share a modkit ID in carcols.meta. Give one a unique ID and update its kit name in carvariations.meta.
Can I add cars without restarting the server?
Yes. Upload the resource, run refresh and ensure in the console, and add the ensure line to server.cfg. Some players may need to reconnect before everything loads correctly.




Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.