Перейти к содержимому
Vehicle & Weapon Merger

Vehicle & Weapon Merger

Merge a pile of single car and single gun resources into one vehicle resource and one weapon resource: what collides, the rule for each clash, and what one big resource costs you.

Эта документация пока на английском.

Open the tool Last updated

The Vehicle & Weapon Merger takes the folder of one car per resource that every server ends up with and gives back one fivemad_vehicles and one fivemad_weapons: one stream/, one data/ of merged metas, a correct fxmanifest.lua and a report of everything that collided. Everything runs in your browser. No file is uploaded anywhere.

What it takes

  • A folder of resources. Point it at your [vehicles] folder, or [cars], or whatever you called it. Nested category folders in brackets are fine.
  • Several resource folders at once. Drag as many as you like onto the page.
  • Zips. One zip per resource, or one zip holding several. Drop them together.

It works out which folders are resources and which half of the merge each one belongs to from what is inside it, not from its name. A folder with vehicles.meta, handling.meta, carcols.meta or carvariations.meta is a vehicle resource; one with weapons.meta, weaponcomponents.meta or weaponanimations.meta is a weapon resource. Anything else is listed and left alone.

.rar and .7z cannot be opened in a browser: unpack them first. A .rpf is a game archive rather than a resource, so run that through the Mod Converter first and merge what comes out.

What you get

code
fivemad_vehicles/
  fxmanifest.lua
  client.lua      AddTextEntry per car
  README.md       the same report
  data/
    handling.meta
    vehiclelayouts.meta
    vehicles.meta
    carcols.meta
    carvariations.meta
  stream/         one flat folder
fivemad_weapons/
  ...same shape

stream/ is flat on purpose: it is the only way a file name clash is visible. Every name in it is unique.

Both names are editable fields on the page. Whatever you type is used as typed.

Installing it

  1. Stop the original resources and take their ensure lines out of server.cfg. This matters: if they keep running, every model name, handling id and mod kit in the merged resource is defined twice, which is the problem you just fixed.
  2. Copy the two folders into resources.
  3. Add ensure fivemad_vehicles and ensure fivemad_weapons.
  4. Restart the server.

Keep the original folders somewhere. Updating one pack later means merging the set again.

Important

Read the Collisions tab before you install. Anything marked “left to you” or “first one kept” is a decision the tool could not make for you, and it is usually two packs that genuinely ship the same car or the same weapon name.

What the tabs show you

Collisions. Everything two packs both claimed, grouped by what kind of thing it was, with what happened to it: written once, renumbered, renamed, merged, first one kept, or left to you. Filter by “Needs you” to see only the ones that are still a decision.

Resources. Which folders went in, how many cars or guns each one contributed, and which were left alone with the reason.

Files. Every file in the output. Click a meta to read it. The stream/ list marks anything that was renamed and what it used to be called.

Limits. The caps that really exist in FiveM, with this pack’s count against each one. See below.

Checks. The merged resources run through the Vehicle Pack Validator, the same checks you would run on the finished folder. What is left there is almost always something the original packs were already missing: a car with no texture dictionary, an oversized .ytd, a mod kit nothing asks for.

The clashes and what happens to each

Mod kit ids

A kit is found by its kitName, but the game keeps kits in one table addressed by the <id value> inside the kit. Two kits on one id are one kit: the parts of the loser stream perfectly and no tuning menu ever lists them, and nothing appears in any console.

Every kit gets an id nothing else uses, the number in front of its name is brought back in line, and every carvariations entry that pointed at it is rewritten in the same pass. Renumbered kits start at 1000 by default, which you can change, because the base game’s own carcols fills ids up to 999. 135_something_modkit is a real and common example: 135 is Rockstar’s own 135_prototipo_modkit.

Two things worth knowing. Id 0 is the engine default (0_default_modkit) and is never handed out, and a pack renumbered above 1023 is a FiveM pack from then on, because plain GTA V overflows past that id.

Siren and light settings

Much tighter than mod kits. sirenSettings is an eight bit field, so there are 254 usable siren settings in the whole game, an id above 255 wraps round and takes over whatever owns the remainder, and no server side setting raises it. lightSettings is 1 to 255 in the same family with no adjuster at all.

So a settings block identical to one another pack already brought is pointed at the one that exists instead of taking a new id. That is what a light setting is for, and it is the difference between a big emergency pack fitting and not fitting. Anything that still needs its own id gets a free one and the cars that used it are rewritten. If the range runs out you are told.

One thing is stated rather than solved: nobody has ever published the base game’s own <Lights> ids, so light ids are kept apart from each other and from the ones your cars ask for, but a clash with a Rockstar light setting cannot be checked here. The game’s kit and siren ids are known and are avoided.

Handling ids

Two packs defining the same handlingName with different numbers both keep their numbers: the second is renamed and the handlingId of its own cars is pointed at the new name. Names are cut to fit the 14 characters the game stores.

One case is different. A pack defining a handling id that belongs to a Rockstar car is retuning that car on purpose, and the vehicle asking for the name is one you cannot edit, so a renamed entry would have nothing behind it. Two packs retuning the same car is a decision: one is kept and you are told. Before the merge, the pack whose resource started last was the one you were driving, because handling is last loaded wins.

Vehicle model names

A model name is the spawn name, so only one can exist. One copy is kept with its model files and the other is listed for you. If they are two different cars, rename one in its own pack and merge again.

A pack defining a base game model name is left exactly as it is and reported. That is a replace pack: it overwrites a Rockstar car for every player and every traffic spawn.

There is an asymmetry here that explains a lot of confusing bug reports: vehicles.meta is first registration wins while handling.meta is last loaded wins. That is how a car ends up with another car’s physics.

Files with the same name

Everything goes into one flat stream/, which is the only way a name clash is visible. Inside one resource the server keys streamed files on the bare file name and the first one it reads wins, with no message and no sorting, so which of two same-named files survives depends on the filesystem and can differ between your test box and the server.

Three rules in order:

  1. The same file byte for byte is written once. Two packs converted from the same base often ship an identical vehshare.ytd.
  2. A tuning part with no texture dictionary of its own is renamed and the <modelName> in its own mod kit is rewritten to match, so both parts survive.
  3. Anything else keeps the first copy and says so. A part that ships its own .ytd is deliberately not renamed: the dictionary name lives inside the model file, so renaming the pair would leave the part untextured. Rename it in one of the packs instead.

The output folder is always stream/ in lower case. The server reads only that exact spelling, so a resource with a Stream/ folder works on a Windows test box and streams nothing on a Linux host. If one of your inputs has that, this fixes it and says so.

Weapons

A weapon name is a hash that every script, loadout and inventory config already uses, so it is never renamed. Two packs shipping the same WEAPON_ name keep one and you are told which. Which one the game itself would pick is genuinely not knowable, so it is not guessed at.

The merge that matters most on this side is quieter. Every single weapon pack writes into the Default block of weaponanimations.meta, and a second Default block replaces the first instead of adding to it, so without a proper merge only the last pack’s weapon has animations. Those blocks are merged entry by entry: one Default, one FirstPerson, one of each set, with every pack’s weapon inside. pedpersonality.meta is merged three levels deep for the same reason.

The weapon wheel order lists are renumbered too. The game sorts the wheel by OrderNumber rather than by position in the file, and every add-on template hardcodes the same number, so merged packs regularly end up with several slots on one number and a wheel order that changes between restarts.

Two weapons sharing a <Slot> is reported and left alone. The base game shares slots, so it is legal, but a slot name is what GetPedWeapontypeInSlot and the wheel order lists are built on and rewriting one would break more than it fixes.

Names in menus

The AddTextEntry lines out of every resource’s own scripts are collected into one client.lua. A key that two packs give different words to keeps the first and is reported. dlctext.meta is left out because FiveM refuses that file type outright, and a .gxt2 string table cannot come across either, so if a car shows a raw label like RMCOUPE that is where its name used to live: add it to client.lua.

Texture dictionary chains

txdRelationships is the one thing in a vehicle merge that really crashes. The game walks the chain from child to parent and a circular reference takes the game down. Two packs can each ship a perfectly fine block and still make a loop between them, because a shared dictionary name is a parent in one and a child in the other. The merged chain is checked for loops and for a dictionary given two different parents, and a link that closes a loop is dropped and reported.

What it will not merge

  • An asset protected resource (one with a .fxap). Its metas are encrypted for everything but the FiveM client, so no tool can read them. It is named and left where it is.
  • Scripts. Only the AddTextEntry lines are taken. A resource shipping a real script with its car is reported: keep that resource for the script, or port it yourself.
  • Engine sounds are carried, not merged. A .dat151.rel is compiled binary. The files come across under names that do not clash and their data_file lines are rewritten, but they stay separate banks, so the roughly 190 bank ceiling where add-on audio goes silent is unchanged. If two packs used the same engine sound name inside their files, one still loses, and that is not something this can read.
  • Map resources. A _manifest.ymf lists the ymaps of the resource it sits in, and two of them cannot be joined.
  • A pack’s own <Colors> table in carcols, after the first. A resource cannot add colours to the game at all, and unioning them would move the indices every carvariations entry counts on.

What one big resource costs you

Merging is a tidiness win, not a performance one. The game streams per model, not per resource, so a player’s memory use is the same either way.

What changes Why
One switch for everything ensure restarts the whole folder. You cannot stop one car any more.
Adding one car re-hashes all of them The server SHA-1s every file in a stream/ folder whenever the file list changes. One car per resource means one car’s worth; 500 in one resource means all 500, on the next start.
One broken meta takes every car down The XML parser fails the whole file, not the bad entry. A stray character in the merged vehicles.meta makes every car disappear at once.
Changing one meta re-ships all of them Metas live in the resource packfile, so editing one line makes every connected player re-download the packfile holding every car’s metas. Stream files are cached per file and are not affected.
Updating a pack means merging again Keep the originals.

The reasons to do it anyway: fewer folders, one ensure line, one set of ids you control, and the id clashes above found and fixed rather than silently breaking three unrelated cars.

The Limits tab

Merging moves exactly one limit. Each weapons.meta mounted is one of 512 CWeaponInfoBlob slots and Rockstar already uses about 150, so folding N weapon packs into one buys back N minus one. Everything else on that panel counts entries rather than files and is the same number whether your cars live in one resource or a hundred:

Limit Number
Streamed assets, per streamer 65,535, and there are three streamers: everything except .ytd, all .ytd, and the player’s own local mods. Past it the client is killed on join.
Add-on vehicle models 2,068 is FiveM’s MaxExtraVehicleModelInfos, and it cannot be raised. Whether an add-on car takes one of those or one of the 1,024 base slots is not documented, so read it as a likely ceiling.
Mod kits 65,534 on FiveM, 1,023 in plain GTA V
Siren settings 254, no way around it
Light settings 255, no way around it
Weapon archetypes 2,048, roughly 250 add-on weapons with components. Past it the game faults inside the mounter of an unrelated file, so the crash report points at the wrong pack.
Weapon components 2,048, raisable with increase_pool_size
Pickup types 300, of which the base game uses 175
Add-on audio banks somewhere above 190 the rest go silent

Type assetscount in the client console (F8) to see the real streamer totals for your server.

Two things people repeat that are not limits. The 16 MB asset “limit” is the lowest of four warning thresholds and blocks nothing (the YTD Optimizer is still the right answer for a fat .ytd). And there is no resource count cap anywhere in FiveM: 220, 320, 440 and 1500 all get quoted and none of them is in the source or the docs. A custom gameconfig.xml is not needed for add-on cars either, and the ones on the mod sites set the vehicle slot count lower than FiveM already ships.

Limits of the tool

  • It does not open the models. A broken mesh, a missing bone or a wrong embedded texture is not something it can see.
  • Which copy wins a duplicate weapon, component, pickup or ammo name, or a duplicate vehiclelayouts layout name, is not knowable from anything published. Those are reported rather than guessed at.
  • Big drops are read in memory, so a multi gigabyte set is better merged in two halves.
  • The sample is made up: invented names, placeholder model files, no game or author data.