FiveM crashes when an add-on car spawns

Someone spawns the car and the game closes. Sometimes with a driver error, sometimes only for one player. The first instinct is to blame the model and re-download it, but more often than not the model is fine and the problem is around it.

Read the log first

FiveM writes a log per session in FiveM.app\logs. Open the newest one and search for:

• compcache:/ lines with the car's model name. They tell you which resource the file actually came from.
• crash and any driver module, e.g. nvwgf2umx.dll on NVIDIA.

The compcache line has solved more of these for us than any mesh cleanup.

Same model in two resources

If two resources define the same <modelName> in vehicles.meta and stream files with that name, the game ends up with a mix of both. Typical case: the new version next to the old one. You think you're testing the fix, the log says compcache:/old-resource-name/. No amount of geometry work fixes that.

Fix

1. Search resources for the model file, e.g. annisronin.yft.
2. Keep one resource with it. Remove the rest and their ensure lines in server.cfg.
3. Clear the server cache and restart.
4. If it only crashes for some players, have them clear their FiveM cache.

yft and _hi.yft don't match

An add-on car streams carname.yft and carname_hi.yft. The _hi one is used up close, the normal one further out. Both need the same parts and the same material list.

This breaks easily in Blender with Sollumz. Each part has separate meshes per LOD: very high goes into _hi.yft, high into the normal file. Add a badge or a new material to very high only and the two files no longer match. On one of our early cars a logo that existed only in _hi.yft crashed the game on spawn, and it came back with every export until we synced the high LOD.

Checking

• Open both files separately in CodeWalker or OpenIV and compare parts, badges and shader count.
• In Blender, make sure high and very high meshes of every edited object use the same materials before export.
• Don't compare by importing both into one Blender scene. Materials with the same name get reused and everything looks identical when it isn't.

Oversized files

FiveM warns in the client console when a streamed asset is too big, and huge car models cause memory trouble on servers with a lot of add-ons. Common reasons:

• Textures embedded in the .yft instead of the .ytd. They get stored again in _hi.yft and in every tuning part that uses them.
• Large uncompressed textures where a smaller one looks the same.
• Full-detail interior back sides and underbody in both LODs.

Move textures to the .ytd and only cut detail where nobody looks. Decimating visible panels just swaps a warning for holes and jagged seams.

Broken geometry

Some models come with zero-area faces (corners sitting on the same point) or duplicated parts stacked on top of each other. They don't always crash, but zero-area faces can produce invalid normals, so clean them out: Merge by Distance and a zero-area check on every part, not only the suspicious one. We once found it in the tyre mesh, which nobody had touched.

Looks like a crash, isn't one

Order we check in

1. Newest log: which resource did the car load from?
2. Only one resource with that model name?
3. Server cache cleared, server restarted?
4. Any oversized asset warnings in the client console?
5. Only then open the model and compare .yft and _hi.yft.

Still crashing on one of our cars? Check troubleshooting and the FAQ, then open a ticket. Every GKModz release, the Benefactor Regalis for example, goes out with matching LOD files and textures in the .ytd.