FREE TOOL · RESOURCE MANIFEST
fxmanifest.lua generator
The manifest is twenty lines that decide whether a resource loads at all, and the three mistakes that cost the most time are all invisible: a script in the wrong list, a NUI asset missing from files, and a data_file type with a typo in it. This builds the file and points at those three while you are still typing.
Every key checked against the resource manifest reference and the data files list. 3 of them are deprecated there — they are labelled, and off by default.
fx_version cerulean · gta5 · 3 scripts · 0 files · 0 data_file entries
Resource and version
Loads NUI in a secure context, so WASM and fetch work — at the cost of NUI callbacks having to be https:// rather than http://. This is the current FXv2 version and the one to use.
One game writes game 'gta5', two or more write the games table. Runs on FiveM.
convention author, description, version and repository are not documented manifest entries. The reference says metadata keys can be arbitrary and only ever shows these in its example — they are read by txAdmin and update checkers, not by the loader.
Scripts, in load order
This list runs on the client and on the server, and on each side it runs before that side's own files. That is the whole reason it exists: a config table or a helper function defined here is already there by the time anything else loads. It is also why nothing side-specific belongs in it — the code runs twice, once per side, and it is downloaded to clients, so a database credential in a shared file is a public database credential.
Globbing works in all three — client/*.lua or modules/**/*.lua. A glob loads in filesystem order, so if two files depend on each other, name them so the order falls out right or list them explicitly.
Libraries
It goes in shared_scripts because the library has to define its lib table on both sides, and it has to do it before any of your files run — which is exactly what shared_scripts guarantees. The @ prefix means "load this file out of that other resource", so ox_lib has to be a declared dependency as well, or it may start after you and the table will not be there.
Server side only. This is the pattern qb-core itself uses, with a single dependency 'oxmysql' line to go with it.
dependency vs dependencies. The singular takes exactly one string: dependency 'oxmysql'. The plural takes a table, and it is the only one that can hold the slash-prefixed runtime constraints — /server:BUILD, /onesync, /gameBuild:ALIAS, /policy:NAME and /native:HASH. Those are not resource names, and putting one in the singular form gives you a resource that waits forever for a resource called "/onesync".
NUI
Why a blank NUI page is almost always this. ui_page only tells the game which URL to open inside the resource. It does not make a single file reachable — that is what files does. So a manifest with a ui_page and an empty files list opens a URL that resolves to nothing, and you get a transparent black rectangle with no error you would think to look for. The same applies one level down: the HTML loads a stylesheet, a bundle, a font, an image, and every one of those has to be in files too, or the page renders unstyled with a handful of 404s buried in the CEF console.
For a built front end, prefer globs over a hand-written list. A bundler that puts a hash in the filename will change it on every build, and a stale explicit list is a NUI page that worked yesterday.
Streaming — data_file entries
A stream/ folder is picked up automatically; you do not list ydr, ytd or ymap files anywhere. data_file is for the metadata that tells the game what those assets are — and the type name has to be exact, because a wrong one fails without a word in the console. Your add-on car simply gets stock handling and you spend an evening on the handling file.
Everything else
Anything that declares a dependency on the named resource is satisfied by yours instead. This is how qbx_core lets qb-* resources run on Qbox at all.
The reference is blunt about this one: “This setting is deprecated and you do not need to enable it. As of June 2025, Lua 5.3 has been deprecated and all Lua scripts now use the 5.4 version.” It is off here by default. It does no harm — it just does nothing, and a manifest that still carries it is a manifest nobody has looked at since mid-2025.
Save it as fxmanifest.lua in the root of the my_resource folder — not in a subfolder, and not named __resource.lua, which has been superseded.
-- my_resource/fxmanifest.lua
-- Built with fam-tools.com/free-tools/fxmanifest-generator
-- cerulean is the current FXv2 version. Each version inherits the
-- previous one, so cerulean is bodacious plus the NUI secure context.
fx_version 'cerulean'
game 'gta5'
-- Metadata. These three are convention, not documented entries:
-- the manifest reference says metadata keys can be arbitrary.
author 'PiTyUs C'
description 'What this resource does, in one line.'
version '1.0.0'
-- shared_scripts loads on BOTH sides, and on each side it loads
-- before that side's own list. Config tables and pure helpers go
-- here. Anything that touches a native or the database does not,
-- because this code also runs on the client.
shared_script 'config.lua'
client_script 'client/main.lua'
-- Server files are never downloaded to clients. Secrets live here.
server_script 'server/main.lua'
HOW TO USE IT
From a preset to a loading resource
Start from the preset closest to what you are building. Each one is a working shape, not a blank form.
- Pick the preset. Plain script for a config plus a client and a server file. NUI for anything with an interface. Vehicle, map and clothing for streamed assets — those three come with the
data_fileentries already filled in, which is the part that is hard to remember and silent when it is wrong. - Name the folder in lowercase. Underscores or dashes, nothing else. A capital letter works on your Windows machine and then fails on the Linux box you deploy to, because that filesystem is case-sensitive and the resource name is a path.
- Put the shared things in shared_scripts. Config, constants, locale tables, pure helpers. Not the database layer, not an API key, not anything that calls a native on one side only — shared files are downloaded to clients and run on both sides.
- If there is a ui_page, fill in files properly. The page itself and every asset it loads. Globs for a bundled front end. The validator will tell you if the page is not covered, because that is the bug that produces a blank black rectangle and no error anybody finds.
- Declare what you depend on. Resource names in the dependencies list, runtime constraints in their own fields. If you tick ox_lib or oxmysql, both the load line and the dependency are added for you.
- Download it as fxmanifest.lua into the resource root. Not a subfolder, and not
__resource.lua— that is the superseded name, and a resource with both is a resource where you will edit the wrong one.
The load order, in one paragraph
On the server: shared files, then server files. On the client: shared files, then client files. Within each list, the order you write them in is the order they load, and a glob loads in filesystem order — so two files that depend on each other should either be named so the order falls out right, or be listed explicitly. The manifest gives you no ordering at all between resources; that is what dependency is for, and failing that, the order of ensure lines in server.cfg.
FX_VERSION
The three versions, and what each actually changed
They inherit each other, so picking one picks everything below it too.
Loads NUI in a secure context, so WASM and fetch work — at the cost of NUI callbacks having to be https:// rather than http://. This is the current FXv2 version and the one to use.
Implies clr_disable_task_scheduler, and stops defining `window` in JS contexts for library compatibility. Only pick it if a dependency genuinely needs it.
The FXv1 equivalent. Requires a game to be specified and is mandatory for RedM. There is no reason to start a new resource here.
REFERENCE
Every manifest key, and the trap that comes with it
Marked documented, deprecated or convention — because the reference itself says metadata keys can be arbitrary, and three of the keys everybody uses are in that category.
| Key | What it does | Source |
|---|---|---|
| fx_version | Which functionality set the resource gets. One of adamant, bodacious or cerulean; each inherits the one before it. cerulean is current. Missing it entirely is the commonest cause of "resource manifest is invalid" — the server will not guess. | documented |
| game / games | Which game APIs the resource may use: common, gta5 or rdr3. Singular for one, the games table for several. adamant and above require it. A FiveM-only script wants game 'gta5', not common — common cannot reach a single game native. | documented |
| author | Your name. It appears in the reference's example but is not a documented entry — the page says metadata keys can be arbitrary. | convention |
| description | What the resource is. Same status as author: convention, shown in txAdmin, not in the spec. | convention |
| version | Your version string. Also convention. Several update checkers read it, which is the only reason it matters. | convention |
| shared_script / shared_scripts | Loaded on both sides, and added to the resource packfile. Runs before the client and server lists on its own side. Anything in here runs twice — once per side. Configuration tables and pure functions belong here; anything that touches a native or a database does not. | documented |
| client_script / client_scripts | Loaded on the client, and implicitly added to the packfile so it downloads. Supports globbing. | documented |
| server_script / server_scripts | Loaded on the server only. Never downloaded to clients, which is why secrets go here and nowhere else. | documented |
| ui_page | Sets the resource's NUI page, to a file in the resource or a URL. Setting it is half the job. The page and every asset it loads must also be in files, or NUI fetches a 404 and draws nothing. | documented |
| file / files | Adds a file to the packfile so clients download it on joining the resource. This is the list NUI serves from. A stylesheet or font that is not in it gives you an unstyled page with no error in the console you would notice. | documented |
| dependency / dependencies | Requires another resource to load first. The table form also takes runtime constraints: /server:BUILD, /onesync, /gameBuild:ALIAS, /policy:NAME and /native:HASH. Singular takes one string, plural takes a table. The plural one is where the slash-prefixed constraints go — they are not resource names. | documented |
| provide | Marks this resource as a replacement for another, so resources that depend on the original are satisfied. qbx_core provides qb-core this way, which is how qb-* resources run on Qbox at all. | documented |
| data_file | Mounts a file into the game's extra content system, by type. Supports globbing in the filename. A wrong type name fails silently: the file never mounts, no error appears, and your add-on car has stock handling. | documented |
| this_is_a_map | Marks the resource as a GTA map and reloads map storage when it starts. Any value will do. | documented |
| server_only | Clients download nothing from this resource at all. It is the right answer for a pure server script, and it will break any resource with a client script or a ui_page. | documented |
| loadscreen | The HTML file used as the game loading screen. | documented |
| loadscreen_manual_shutdown | Keeps the loading screen up after the game data loads; you close it yourself with SHUTDOWN_LOADING_SCREEN_NUI. | documented |
| escrow_ignore | Which files stay readable when the resource is pushed through Asset Escrow. It only does anything to an escrowed asset. In an open resource it is inert — and leaving it in tells everybody which files you planned to encrypt. | documented |
| lua54 | The reference now says: deprecated, you do not need to enable it, and as of June 2025 all Lua scripts use 5.4 already. Harmless but pointless. If you see it in a resource you downloaded, that resource predates June 2025 and probably has other assumptions to check. | deprecated |
| node_version | Picks the Node version for the server scripting runtime. Documented values are 16, the default, and 22. | documented |
| clr_disable_task_scheduler | Turns off the custom C# task scheduler on the server. Already implied from bodacious upward. | documented |
| replace_level_meta | Replaces the level meta with your own file. The file also has to be listed in files. | documented |
| before_level_meta / after_level_meta | Loads a level meta around the primary one. The reference says to use data files wherever possible instead. | deprecated |
| resource_manifest_version | The FXv1 GUID. The reference says outright: you should be using fxmanifest.lua and fx_version instead. | deprecated |
| use_experimental_fxv2_oal | Enables One Argument List for Lua. Marked experimental in the reference; qbx_core ships with it on. | experimental |
| export / server_export | Exports a global function from a client or server script. The reference steers you away from export: use the exports('name', fn) call instead. server_export has no such note. | documented |
| convar_category | Adds your convars to the Project Settings page in FxDK, with a type: CV_STRING, CV_BOOL, CV_INT, CV_SLIDER, CV_COMBI, CV_PASSWORD or CV_MULTI. | documented |
STREAMING
The data_file types this tool offers
A working subset of the published list, spelled exactly as the reference spells them. A wrong type never errors — it just does not mount.
| Type | What it mounts | Example path |
|---|---|---|
| VEHICLE_METADATA_FILE | vehicles.meta — the model definition itself. | data/vehicles.meta |
| HANDLING_FILE | handling.meta — how it drives. | data/handling.meta |
| CARCOLS_FILE | carcols.meta — model variation and mod kit data. | data/carcols.meta |
| VEHICLE_VARIATION_FILE | carvariations.meta — colour combinations and kits. | data/carvariations.meta |
| VEHICLE_LAYOUTS_FILE | vehiclelayouts.meta — seats, entry animations, in-car layout. | data/vehiclelayouts.meta |
| VEHICLE_SHOP_DLC_FILE | Dealership entries for an add-on vehicle. | data/dlctext.meta |
| VEHICLEEXTRAS_FILE | Extras data. | data/vehicleExtras.dat |
| VFXVEHICLEINFO_FILE | Vehicle particle and effect info. | data/vfxvehicleinfo.meta |
| DLC_ITYP_REQUEST | Registers a prop type definition. The documented example is an .ityp; streamed map resources point it at the .ytyp. | stream/myprops.ytyp |
| DLC_POP_GROUPS | popgroups.ymt — which peds and vehicles populate the world. | data/popgroups.ymt |
| POPSCHED_FILE | Population scheduling override. | data/popcycle.dat |
| GTXD_PARENTING_DATA | TXD parent and child relationships for map textures. | data/gtxd.meta |
| INTERIOR_PROXY_ORDER_FILE | Interior proxy order for an MLO. | data/interiorproxies.meta |
| SCENARIO_POINTS_OVERRIDE_PSO_FILE | Scenario points manifest, for ambient animations in a map. | data/scenarios.ymt |
| SHOP_PED_APPAREL_META_FILE | Clothing shop entries for streamed apparel. | data/shop_ped_apparel.meta |
| PED_METADATA_FILE | The ped definition itself, for an add-on ped. | data/peds.meta |
| PED_PERSONALITY_FILE | pedpersonality.meta — behaviour profile for an add-on ped. | data/pedpersonality.meta |
| TATTOO_SHOP_DLC_FILE | Tattoo and overlay shop entries. | data/tattoo.meta |
| OVERLAY_INFO_FILE | Overlay definitions for ped decoration. | data/overlay.xml |
| WEAPONINFO_FILE | An add-on or modified weapon definition. | data/weapons.meta |
| WEAPON_METADATA_FILE | Weapon metadata. | data/weaponmeta.meta |
| WEAPONCOMPONENTSINFO_FILE | Attachments and components. | data/weaponcomponents.meta |
| WEAPON_ANIMATIONS_FILE | Per-weapon animation set. | data/weaponanimations.meta |
| LOADOUTS_FILE | Loadout definitions. | data/loadouts.meta |
| DLC_WEAPON_PICKUPS | Pickup definitions for an add-on weapon. | data/pickups.meta |
| AUDIO_WAVEPACK | A folder of wave packs, not a single file. | audio/sfx/mypack |
| AUDIO_GAMEDATA | A .dat151.rel game data file. | audio/mysounds_game.dat |
| AUDIO_SOUNDDATA | A .dat54.rel sound data file. | audio/mysounds_sounds.dat |
| AUDIO_SPEECHDATA | A .dat4.rel speech data file. | audio/myspeech.dat |
| CLIP_SETS_FILE | Clip set definitions for custom animations. | data/clip_sets.xml |
| CONDITIONAL_ANIMS_FILE | Conditional animation definitions. | data/conditionalanims.meta |
| SCENARIO_INFO_FILE | Scenario definitions. | data/scenarios.meta |
| EXPLOSION_INFO_FILE | Explosion definitions. | data/explosion.meta |
| PTFXASSETINFO_FILE | Particle effect asset registration. | data/ptfxassetinfo.meta |
| TIMECYCLEMOD_FILE | A timecycle modifier, for interior lighting. | data/timecycle_mods.xml |
| TRAINTRACK_FILE | Train tracks. | data/traintracks.xml |
| TRAINCONFIGS_FILE | Train configuration. | data/trainconfigs.xml |
| CONTENT_UNLOCKING_META_FILE | Content unlock definitions. | data/unlocks.meta |
| STREAMING_REQUEST_LISTS_FILE | Streaming request lists. | data/streamingrequestlists.meta |
| ZONEBIND_FILE | Zone binding. | data/zonebind.ymt |
The full reference lists 89 types, most of them with no description at all. These are the ones a FiveM resource actually uses. Note that the published list gives no file extensions — the example paths above are the ones the reference shows, except DLC_ITYP_REQUEST, where the documented example is an .ityp and every streamed map resource in practice points it at the .ytyp. If you are following a map tutorial, use the .ytyp.
QUESTIONS