What renaming a spawn code actually touches
A spawn code is not one string in one file. 20ambocr is the <modelName> a server owner types into /car, and — when a pack follows the ordinary conventions — it is also the <txdName>, the <handlingId>, the handling.meta entry that id points at, the stem of up to four files under stream/, and sometimes a key inside vehicle_names.lua or a framework's own vehicle table.
Renaming only the file you clicked and calling it done is how a vehicle keeps its old physics, loses its mods, or shows a blank name in the menu. This tool reads the pack's own reference graph first — which vehicle owns which handling id, which carvariations row owns which kit — and only edits a field once it is known to belong to the code you asked to rename, in the resource you dropped.
Why find-and-replace breaks a real pack
A tool that greps every .meta in a folder for a whole-word match of your old code has two ways to go wrong, and both show up in real packs. It can rewrite an unrelated resource's <handlingId> because that resource happens to declare the same string for a different reason — a pack whose model name is van, bus or police rewrites the whole drop. And it can miss the underscore rule: a word boundary sits between two letters, never inside 4826_20ambocr_modkit, so a correct rename of 20ambocr must leave that compound id — and 20ambocrew — exactly as they were.
This tool only ever edits a field it has already matched to the vehicle you named, in the resource you dropped, and every match inside that field is still a whole word. Nothing here rewrites a second resource because a string happened to line up.
Why some renames are refused outright
Before a single edit is produced, this tool works out the full set of names every resource in the drop would end up owning — including the 238,359 names the base game already owns. If two different old codes would end up sharing one new name, if a new name collides with a vehicle already in the drop, or if a new name lands on a base-game vehicle like police, the whole batch is refused and named, and nothing is written. That refusal is not a warning beside a live button — replacing a base-game vehicle's name is a silent, permanent, in-game swap, and the tool this replaces validated nothing at all: a 200-character name went straight through.
A second pass checks the same question about files rather than names, because a name check cannot answer it. Every file in the drop is mapped through the renames the plan produced, and if two different files would be written to one path the batch is refused the same way — which is what covers a .ytyp, a .ymap or an .awc landing on one already in the pack, and an sfx/dlc_<old>/ folder merging into an existing sfx/dlc_<new>/. Those files carry no spawn code the name pass can read, so without this they were the one way a rename could still overwrite something and report success.
Swapping two codes — A to B and B to A — still works, because both renames are planned as one batch: the tool sees that each name is vacated by the same batch that claims it. Running the same swap as two separate downloads would not, because the second run would find B already taken.
Reading the dry run before you download
Every rename you type produces a complete plan on this page before anything is built: every file that would move, every line that would change, and every reason a rename was refused or matched nothing. A code that does not appear anywhere in the drop is reported rather than silently ignored, so a typo shows up as an empty result instead of a rename that quietly did nothing.
The download button only builds a zip — a fresh copy, with the renamed and edited files inside it. Nothing on your disk is opened for writing at any point, which is the entire difference between this tool and the one it replaces: that tool wrote into the folder you gave it, and on a name collision it overwrote one file with another while reporting success.
What this tool does not touch
A .gxt2 label, an audio bank (.dat/.rel) and a .ytyp's own internal archetype names are compiled or structured formats this tool has no parser for, and it says so by name in the plan rather than silently leaving them — guessing at a byte layout to save one manual edit is a worse trade than telling you plainly it was not attempted. An audio bank's file name is a path rather than a byte layout, so that much is renamed — but only when the stem spells your old code as a whole word. 20ambocr.dat151.rel matches; dlcambo_game.dat contains nothing that is 20ambocr and is left alone. The plan counts which of your banks fell on each side rather than restating the rule and leaving you to guess, and it says the other half out loud too: renaming the file does not re-point a vehicle's audioNameHash, which names an entry inside the compiled file. A .gxt2 is neither opened nor renamed — it is named after a language, not a vehicle.
It also cannot see inside a .rpf, and it updates a fxmanifest.lua path only where the manifest quotes the exact old path of a file this batch renamed — it does not scan an arbitrary Lua script for a path literal elsewhere in the pack.
Frequently asked questions
What does renaming a FiveM spawn code actually involve?
More than one file. The code is the <modelName> in vehicles.meta, and when a pack follows the ordinary conventions it is also the <txdName>, the <handlingId>, the handling.meta entry that id points at, the carvariations row's modelName, the stem of the files under stream/ and their high-LOD partners, and sometimes a key in vehicle_names.lua or a framework's own vehicle table. Renaming only the files leaves the vehicle with its old physics or no mods at all.
Why not just find-and-replace the old name across the pack?
Two ways that breaks a real pack, and both show up in the tool this replaces. It rewrites an unrelated resource's <handlingId> because that field happens to equal your pack's model name, and it rewrites compound identifiers that merely contain the code. This tool only edits a field once the pack's own reference graph says that field belongs to the code you asked to rename, in the resource you dropped, and inside that field the match is still a whole word — so 4826_20ambocr_modkit and 20ambocrew are left alone.
What happens if the new name is already taken?
The whole batch is refused before anything is written, and the collision is named. Two checks run: one over the spawn names every resource in the drop would end up owning, including the 238,359 names the base game owns, and one over the full set of output file paths, which is what catches a .ytyp, a .ymap or an sfx/dlc_<code>/ folder landing on one that already exists. The tool this replaces had neither and overwrote one file with another while reporting Done.
Can I swap two spawn codes with each other?
Yes. A to B and B to A is two sources resolving to two different targets, so neither collision check fires, and it needs no special case. For a caller writing in place the module also exposes a two-phase rename — everything to temporary names first, then to final names — because a direct one-phase swap is exactly the case that destroys a file.
Does it rename my audio bank?
The file name, yes, but only when its stem spells your old code as a whole word: 20ambocr.dat151.rel matches, dlcambo_game.dat does not and is left alone. The plan counts which of your banks fell on each side rather than leaving you to assume. What it never does is rewrite the compiled contents, and renaming the file does not re-point a vehicle's audioNameHash — that names an entry inside the file. A .gxt2 is neither opened nor renamed.
Does it write into my folder?
No. This version never opens a write handle to your disk at all: it builds a fresh zip and hands it to your browser's own download, so the pack you dropped is byte-for-byte untouched no matter what happens. The tool this replaces wrote into the folder it was given, which is how a collision it did not check for destroyed files.
Does this upload my pack anywhere?
No. Every step runs in your browser tab: there is no request in the page and no server behind it. Only text files are decoded — manifests, .meta, .lua, .sql — and every model, texture and archive is counted by name and size and never read.
Is a clean plan proof the renamed pack works?
No, and the plan says so. This is a static read of the files as supplied. It cannot see inside a .rpf, it does not rewrite the contents of a .gxt2, an audio bank or a .ytyp's internal archetype names, and it updates an fxmanifest.lua path only where the manifest quotes the exact old path of a file this batch renamed. Every one of those is listed by name in the plan's notes rather than passed over silently.