Your server has one namespace, and it is flat
Everything under a folder called stream/, in every resource your server runs, is registered into a single index by its bare file name. Not by its path, not by its resource, not by the vendor who sold it. There are no folders in that index. So these two files:
resources/[vehicles]/vendor-a-police/stream/police.yft resources/[vehicles]/vendor-b-police/stream/parts/police.yft
are not two files as far as the game is concerned. They are two claims on one name, and exactly one of them can be the file the server streams. The same is true of .ytd textures, .ydr props, .ymap, .ytyp, .awc audio and everything else a resource streams — which is why a shared wheel pack two vendors both bundled is a real collision, and why a file called shell.ydr in someone's MLO is a time bomb.
Nothing tells you when one wins
When the server registers a streamed name it already has, it does not warn, it does not error, and it does not log. It replaces the entry and carries on. Your console is clean, your resources all start, and one of the two packs is simply not in the game.
What you see instead is a symptom with no obvious cause: a police car that suddenly has the wrong wheels, a livery that stopped working on one vehicle and only that one, a car whose interior belongs to a different car, a pack you paid £40 for that "doesn't seem to have installed properly". Neither pack is wrong on its own, so no per-pack check can find it — only a view across every resource you actually run, which is why this tool wants the whole folder rather than the pack you suspect.
Load order decides which copy wins
The winner is decided by the order your resources start in, which is the order the ensure lines appear in your server.cfg. That is the whole mechanism, and it is why a collision that was harmless for six months can start breaking things the day you add an unrelated resource above it. The part that catches people out is that the two kinds of collision resolve at opposite ends of that order:
- A streamed file — the later registration replaces the earlier one, so the resource that starts last is the copy in game.
- A vehicle spawn code — the archetype is registered once per name and a second registration is discarded, so the resource that starts first keeps the code.
- A
data_fileregistration — this tool reports the order and refuses to name a winner. Which of two merged table entries the engine keeps is not something we have verified perdata_filetype, and inventing a rule for it would be a confident guess dressed as an answer. Removing the duplicate registration is the fix either way.
What your config can and cannot settle
Give the tool your config and it answers with the resource name and the position in your own ensure order. Without one it says load order unknown — and it means it. Some configs cannot settle it even so, and the tool says which and why: a config that execs another file has ensure lines this page cannot read; an ensure [cars] starts everything in that bracket folder in the folder's own order, which no config states; and two resource folders that share one name cannot be told apart by an ensure line at all.
Identical duplicate: harmless. Different file: a bug
Two resources shipping one name always collide. Whether that matters depends on whether the two files are the same bytes. Byte-for-byte identical is the common, boring case: one vendor bundling the same shared part into two of their own packs. One copy loses the namespace and the game gets the same asset either way. What it costs is the download and the streaming memory for one file shipped twice — a budget question rather than a correctness one, and Stream Budget counts what those duplicated bytes cost every joining player.
Different files is the one worth your evening. One pack's asset is shadowed by another pack's file of the same name: the model, texture or prop that resource shipped never appears in game, and nothing says so. This is where the wrong wheels, the missing livery and the car with another car's interior come from.
How the difference is proved, or refused
The tool proves the difference rather than assuming it. Two copies of different lengths cannot be the same bytes, so that case is answered without reading anything. Otherwise it hashes the colliding files — only the colliding files, in a second pass you can skip — and splits the report in two. If the comparison did not run, the collision says not compared, never "different". A verdict nobody earned is worse than no verdict at all.
The collisions that have no file name to compare
Half of this namespace is not file names. It is the data_file lines in your manifests, and what they register:
data_file 'HANDLING_FILE' 'handling.meta' data_file 'AUDIO_GAMEDATA' 'audioconfig/dlcambo_game'
Every vehicle pack writes the first line, and forty packs writing it forty times is not a fault — the files are merged into one server-wide handling table. The fault is when two of them define an entry under the same handling name: one row lands on the other, one car quietly drives with another pack's physics, and your console says nothing. The second line is the other shape of it — that value is not a path but the name the whole server files that audio data under, and the file behind it is actually called dlcambo_game.dat151.rel. Two resources claiming the name means one registration lands on the other, and no comparison of file names reaches either case.
What the metas are compared on
This tool reads the manifests, opens the metas they register and compares them entry by entry — handling names, vehicle models, carvariations entries and mod kit names. A registered meta it could not open is reported as not checked, by name, rather than counted as a pass.
A duplicate inside one resource
If one resource ships the same streamed name twice — usually stream/ and stream/spares/ holding the same wheel — FiveM does complain, and it is worth tidying. But it is housekeeping, not a conflict between packs: nothing you bought is being shadowed by someone else's file. Those are listed under their own heading with their own count.
The same principle applies to base-game names. A pack that deliberately replaces a stock .ydr is a whole genre of mod, not a bug, so it is reported as context rather than as an error — and where a collision happens to be over a stock name too, the report says so in the same finding rather than filing a second one.
What to do with the report
- Emergency fleet first. A collision on a police, fire, EMS or recovery name is a problem for every unit on the server at once, so those are ranked above everything else.
- Then the different ones. Identical copies can wait for a tidy-up; a shadowed file is an asset you own and cannot see.
- Rename, do not reorder. Moving an ensure line changes which copy wins, which fixes the symptom and leaves the collision for the next person. Renaming the asset — and the spawn code, and the files together — removes it.
- Check a pack before you buy it. Scan the preview alongside the resources you already run, not on its own. A collision found here is a vehicle you would have paid for and not received.
- Take the export. Markdown for a ticket, CSV for a spreadsheet you can sort and assign, JSON for a script.
What this tool does not check
It reports collisions in the streamed asset namespace, in vehicle spawn codes and in data_file declarations. Ped model names, weapon archetypes and script-level conflicts — two resources exporting the same function, two jobs both claiming a blip — are not checked, and a short list here is not a clean bill of health. Anything that was skipped, capped or could not be read is said in words at the bottom of the report and travels into every export.
It also cannot see inside an .rpf. A pack distributed as dlc.rpf is invisible to this, and the tool says so rather than reporting zero. And everything here is a static read of files as supplied: it never starts a server, so it can tell you two resources claim one name and never that the server crashed because of it.
Frequently asked questions
What is the FiveM stream namespace?
Every file under a folder called stream/, in every resource your server runs, is registered by its bare file name into one flat, server-wide index. There are no folders in it. two-packs/stream/parts/police.yft and other-pack/stream/police.yft are the same name as far as the game is concerned, so only one of them can exist at a time.
What happens when two resources ship a file with the same name?
One of them wins and the other is discarded, with nothing written to the server console. For a streamed asset the resource that starts last replaces the earlier registration, so the later ensure line wins. For a vehicle spawn code it is the opposite: the archetype is registered once per name and a second registration is thrown away, so the resource that starts first keeps the code.
How do I know which copy is actually in game?
Only your start order decides it, which is why this tool asks for your server.cfg. Give it the config and it resolves each collision against the real ensure order and names the winning resource. Without a config it says load order unknown and explains what would settle it — it never sorts the copies alphabetically and calls the last one the winner, which is what most conflict checkers do.
Is a duplicate file always a problem?
No, and that is the most useful thing this tool tells you. If the two copies are byte-for-byte the same file — a vendor shipping one shared wheel from two of their own packs — one copy loses the namespace and the game gets the same asset either way. It costs you a download and some streaming memory and nothing else. If the copies differ, something you installed never appears in game, and that is the half worth acting on.
Why do you read the bytes in a second pass?
Because the first pass is instant and the second is not. Comparing names across three hundred resources costs nothing; hashing the colliding models can mean reading hundreds of megabytes. So the names come back immediately and the byte comparison is a button with the file count and the size on it — and if you skip it, every collision says not compared rather than pretending to a verdict nobody earned.
Can two resources clash without sharing a file name?
Yes, and it is common. Two vehicle packs whose handling.meta files both define an entry called police are merged into one server-wide handling table, so one of the two entries never applies and the car drives with the other pack's physics. Two packs registering the same audio bank under AUDIO_GAMEDATA collide the same way. Both files are called what they are supposed to be called, so a checker that only compares file names sees nothing. This tool reads the data_file lines in the manifests and the contents of the metas they register.
Does this upload my resources anywhere?
No. The scan runs in your browser tab and no file you drop leaves it. Only text files are opened — manifests, .meta, .lua and the other plain-text extensions — and binary assets are counted by name and size unless they turn out to collide and you ask for the byte comparison. The page does fetch one thing from us: our own base-game name list, so a mod that deliberately replaces a stock asset can be told apart from two packs fighting.
Two of my packs are both called police. Can you still tell them apart?
Yes. Each resource keeps the folder or archive it came from as its identity, so two vendor zips with identical internal layouts stay two resources and the collision between them is reported. A tool that keys resources on their folder name folds the two into one and reports a clean namespace over the exact input you opened it to diagnose. One caveat it will tell you about: a server.cfg addresses a resource by name, so where two folders share one name no ensure line can be attributed to either and the winner stays unknown until you rename one.