gta-v-data-dumps is a lookup table for the data behind GTA V natives

Each dump is named after the native it feeds

The most useful thing about this repository is not the data, it is the organisation. Every dump in the overview is listed with the count of what it contains and the native it is usable with, so you can start from the call you want to make and work backwards to the file.

Take vehicle mod kits. The entry points at vehicleModKits.json and says 602 vehicle mod kits with 36282 mods in total, usable with SET_VEHICLE_MOD_KIT, SET_VEHICLE_LIVERY and SET_VEHICLE_MOD. The vehicles file, vehicles.json, holds 921 vehicle infos and is marked usable with the vehicle natives, and vehicleHandlings.json holds 838 vehicle handling infos which the note says are shared for all existing vehicles, with the handling id to be found in the vehicles dump. That last remark is the kind of detail that saves an afternoon: the handling table alone is not much use, but joined against the vehicles file it becomes the whole handling model of the game.

The same pattern repeats. peds.json holds 1109 peds and is described as useful for the various ped related natives. pedComponentVariations.json holds 33558 component variations and 5883 ped props drawn from 96 collections, usable with the component variation and ped prop natives, and the description notes that this file carries cloth names and translations while pedComponentVariations_free.json is the same data without them. scenariosCompact.json holds 247 scenarios and scenarioGroupNames.json holds 235 scenario groups, both marked as usable with the scenario and scenario group natives. The animations entry is the largest of this family, animDictsCompact.json with 20179 animation dictionaries and 269414 animations, usable with the task play anim native.

So the practical usage is: you know you want a particular native, you look up the file, and you get the identifiers instead of guessing them.

The data is generated, and the game build stamp is the contract

The README states that these are auto generated dumps, and that some are enhanced with data from the author's own GTA V research. The generator is not in the repository. The top level entries are data files, four.ini lists, a few text files, an archive and a handful of directories, and there is no source tree for a generator. The only hint about it is the invitation to create an issue if you find a problem with the data, so the generator can be improved, which implies it lives somewhere else.

That matters because of the version line. The README states that all data is up to date as of GTA V update v3717.0, Online 1.72, with the DLC mp2025_02_g9ec. Those identifiers are the API version of the content in these files, and a script that relies on a model name, a scenario or a mod kit is relying on data extracted from one particular build of the game.

When the game updates, the identifiers can change. Rockstar adds content, renames things and removes things, and the dumps have no stability guarantee attached to them beyond the stamp in the README. That is the difference between this repository and a versioned API, and it is the single most important thing for a consumer to internalise.

The practical consequence is that you pin the game build your tooling targets, and you re-extract when you move to a new one. The data is a snapshot with a label, not a service.

JSON is the default format, but the repository is not JSON only

Most of the dumps are JSON, and the compact suffix on several file names, animDictsCompact.json, scenariosCompact.json, particleEffectsCompact.json, explosionTypesCompact.json, camShakeTypesCompact.json, animPostFxNamesCompact.json, means the file has been reduced to a more compact representation of a larger structure. The naming is inconsistent in a useful way, since some files are plain, some are compact and one is explicitly the free variant of another.

Then there are the other formats. Four files are INI: ObjectList.ini with 21631 createable objects, the objects that can be created with the most commonly loaded ytyps, plus PedList.ini, VehicleList.ini and WeaponList.ini. These are plain lists in a format that the modding tools already read, which is why they exist alongside the JSON.

The navigation data comes in three shapes. nodes.zip is a ZIP containing JSON with 259 node cells and 67454 nodes, mostly useful for vehicle navigation. The ped navigation data is the offroad and ped navigation meshes, delivered as a MEGA MSGPACK download in 7z format, and navigationmesh.md explains the messagepack model, with 4921 navmeshes and 7402946 polygons in total. A separate document, ps3-builds.xml, sits alongside them.

Then there are the text files that do not fit JSON, such as strings.txt, eEventType.txt, peds_directorname_gxtkeys.txt, and a directory named objectslocations holding per object location data. The variety is not inconsistency, it is one dump per consumer, and the README lists the files as the contract rather than describing a schema.

The navigation meshes are the part that hurts to download

Most of the dumps are JSON files you can clone and read. The navigation meshes are a different proposition. The ped and offroad navigation mesh data is 4921 navmeshes with 7402946 polygons, and it is not in the repository. The README links a MEGA download in 7z format and points at navigationmesh.md for the model, and the format is MessagePack, a binary serialisation, rather than the JSON used elsewhere.

That choice has consequences. The navigation mesh is the data that lets a pedestrian or a vehicle path across the world, and it is large enough that the author chose to host it outside git, in a format chosen for compactness. The result is that a consumer needs a MessagePack reader and a 7z extractor, and the file lives somewhere whose lifetime is not tied to the repository.

The vehicle navigation data is lighter by comparison and sits in the repository as nodes.zip, with 259 node cells and 67454 nodes, and the note in the overview makes the distinction explicit: the node dump is mostly useful for vehicle navigation, while the mesh dump is where the ped navigation data is.

If your project is a script that needs a ped to walk to a place, that is the file you need, and it is also the file most likely to break your CI because it is not in the checkout.

Some dumps carry more than the identifiers

A few entries go beyond a name list, and those are the ones that make the repository more than a hash table.

The vehicle colors file is described as containing all Xenon colors, window colors, primary and secondary colors and vehicle plates data, which is a colour model rather than a list of identifiers. The zones entry says it contains all the bounds coordinates for the zones, with 97 zone infos, so it is spatial data that a script can test a position against rather than a name to pass into a native. The MLO and interiors dump gives 385 MLO interiors at 844 locations and also contains the in game locations of interiors, which is a join between an asset and the world position it sits at.

Then there are the files that are not dumps of the game at all but of the modding toolchain around it. flagValues.json, handlingFlagValues.json and drivingStyleFlagValues.json enumerate bit flag values, and the audio family, ambientAudioBankNames.json, missionAudioBankNames.json, scriptAudioBankNames.json, radioStations.json, musicEventNames.json and audioSceneNames.json, covers the sound side, with soundNames.json holding 43428 audio names from 43 unique audio refs.

So the repository spans three layers: identifiers for natives, structural data like zones and interiors, and reference data for the toolchain. Only the first layer is a straight lookup, and it is the layer people come for.

No releases, no stated licence, and no tooling in the box

Three practical constraints are worth stating before you depend on this.

First, the repository has no GitHub releases. There is a version stamp in the README for the game build, but no tagged artefact for the dumps themselves, so there is no way to pin a specific revision through a release mechanism, and the only handle you have is a commit hash.

Second, the licence is not stated. The repository metadata reports it as unknown, and there is no licence file among the top level entries. For data extracted from a commercial game, that is a question a legal team will ask, and the honest answer is that you have to ask the author or work from the terms the hosting platform applies. The author's own projects, the Pleb Masters Forge and the map editor, are linked from the README, so there is a route to the person who can answer it.

Third, there is no tooling here. No generator, no schema, no validator, no library to read the dumps. You are expected to consume JSON files with your own code, and to open an issue when a file looks wrong, which the README explicitly invites, both for problems with the data and for dumps you would like to see. The community channel is a Discord server.

The primary language is also not reported for the repository, which is consistent with a repository that contains almost no code.

Editorial conclusion

gta-v-data-dumps is worth depending on if you script or mod Grand Theft Auto V and you are tired of hand collecting hashes, model names, scenario names and interior lists, because the repository packages all of it as machine readable files with the native each one feeds attached. It is the wrong source for anything outside GTA V, and it is the wrong source if you need a supported API rather than a snapshot, because the licence is not stated and there are no tagged releases. Before you build on it, check that the data stamp in the README, currently v3717.0 with Online 1.72 and the mp2025_02_g9ec DLC, matches the game build you are targeting, and plan for a manual refresh, since the repository has no GitHub releases and the last push was on 2026-09-17.

Frequently asked questions

Official sources

1. DurtyFree/gta-v-data-dumps on GitHub
2. Issues
3. Project website
4. README