FiveM Prop Files Explained: YDR, YTD, YBN, YTYP & YMAP

Open almost any prop or map resource and you’ll find a stream folder full of files with four-letter extensions that all look vaguely the same. Most people install them by copying the folder and hoping. That works — right up until something doesn’t spawn, and you have no idea which of the files is responsible.

This post is the reference I wish I’d had. What each file is, what it’s for, how they depend on each other, and the handful of rules that explain nearly every broken prop. No tools to buy, no workflow to follow — just the mental model. When you’re ready to actually build one, how to make custom props in FiveM has the options.

The Short Version

File	What it is	Needed for a prop?
`.ydr`	The 3D model (drawable)	Yes
`.ytd`	A texture dictionary	Only if textures aren’t inside the `.ydr`
`.ybn`	Collision (bounds)	Only if collision isn’t inside the `.ydr`
`.ytyp`	Archetype definitions — registers the model name	Yes, to spawn it by name
`.ymap`	Placements — puts props at fixed spots in the world	Only for permanent placement
`fxmanifest.lua`	Tells FiveM what the resource is and loads the `.ytyp`	Yes

Hold on to one idea: the model is not the name. The .ydr is a mesh. The .ytyp is what tells the game “a thing called my_burger exists, here’s how big it is, here’s its drawable.” Nearly every “installed fine but won’t spawn” problem lives in the gap between those two files.

.ydr — The Drawable

The .ydr is the model: the mesh, the shaders applied to it, and usually its textures and collision packed in alongside. It’s what you see.

A few things worth knowing:

The file name matters. An archetype points at its drawable by name, and by convention the two are identical — my_burger.ydr is the drawable for an archetype called my_burger.
It can carry its own textures (an embedded texture dictionary) and its own collision, which is why a lot of simple props are nothing but a .ydr plus the .ytyp.
A related format, .yft, is the “fragment” — used for vehicles and for props that break apart or have moving parts. If you’re making a static prop, you want a .ydr.
Polygon count and texture size live here. When a prop hurts performance, this is the file doing it.

.ytd — The Texture Dictionary

A .ytd holds textures. It’s a separate file when several models share the same textures, or when the textures are too big to sensibly embed.

If a prop turns up black, purple, grey or strangely shiny, suspect textures first: either the .ytd isn’t streaming, or the archetype points at a texture dictionary name that doesn’t exist.

Texture dictionaries aren’t just a prop thing, either. Vehicles, clothing and even the minimap use them — our custom minimap guide is entirely about editing one.

.ybn — Collision

A .ybn is a bounds file: the invisible physical shape the game uses for collision. Players stand on it, vehicles hit it, bullets stop at it.

Collision is often embedded inside the .ydr instead, which is tidy but means changing collision means rebuilding the model. Separate .ybn files are more common in maps, where one collision file covers a whole area of placed objects.

Two opposite failures come from here:

Players walk through the prop — there’s no collision, or the archetype doesn’t reference it.
An invisible wall — the collision is bigger than what you can see. The classic case is a flat sign or poster given a solid box, so there’s a slab the size of the picture standing in front of the wall.

.ytyp — Archetypes (The One Everyone Forgets)

The .ytyp is a list of archetype definitions. Each archetype describes one model:

Its name — what you pass to CreateObject, and what a .ymap refers to.
The drawable and texture dictionary it uses.
Its bounding box and bounding sphere — its size, which the game uses for streaming and culling.
Its LOD distance — how far away it stays visible.
A physics dictionary — which collision to use, when collision is embedded.
Flags that control various behaviours.

Without an archetype, your .ydr streams to every client and then just sits there. The game knows a drawable exists; it has no idea there’s a spawnable model called that. So GetHashKey('my_burger') points at nothing, RequestModel never loads, and nothing is printed to tell you why.

One .ytyp can define many archetypes, so a pack with 50 props usually has one .ytyp, not 50.

.ymap — Placements

A .ymap places things in the world: “put a my_burger at these coordinates, with this rotation.” When a map resource adds furniture to a room or a sign on a wall that’s there every time the server starts, that’s a .ymap.

Things to know:

A .ymap refers to archetypes by name. If the .ytyp isn’t loaded, the placement silently has nothing to place.
It’s optional for props. If your props are spawned by a script, or held by players as items, you don’t need one at all.
Maps also replace vanilla ones. Many map resources ship .ymap files that override the game’s own for an area, which is why two map resources can conflict over the same spot.

Placing props doesn’t require making one by hand — a map editor or placement script writes the .ymap for you. That’s a different job from making a prop, and our prop creator comparison covers both kinds of tool.

fxmanifest.lua — The Glue

Everything inside a folder named stream is streamed to players automatically; you don’t list .ydr, .ytd or .ybn files anywhere. The .ytyp is different — it has to be registered:

fx_version 'cerulean'
game 'gta5'

this_is_a_map 'yes'

files {
    'stream/my_props.ytyp'
}

data_file 'DLC_ITYP_REQUEST' 'stream/my_props.ytyp'

data_file 'DLC_ITYP_REQUEST' tells the game to load the archetypes in that .ytyp.
this_is_a_map 'yes' is what makes FiveM honour that entry. Leave it out and the .ytyp is ignored — the drawables still stream, so there are no errors, but no name ever resolves.
files lets clients download the .ytyp the data_file line points at.

Both of the map lines are load-bearing, and missing either one produces exactly the same symptom: everything installs, nothing spawns. If you’re adding interiors, how to add custom MLOs to FiveM covers the manifest lines that are specific to those.

How It All Fits Together

When the server starts, FiveM reads the manifest and registers the .ytyp. The archetypes in it now exist as names. When a player gets near something — or a script calls CreateObject — the game looks up the archetype by name, which points to the .ydr for the model, the texture dictionary for its textures, and the physics dictionary for collision. If a .ymap is loaded, the game uses those same archetype names to place copies in the world.

Follow that chain and every failure makes sense:

Symptom	The broken link
Nothing spawns, no error	Archetype not registered — manifest lines missing, no full restart, or a name mismatch
Placed props are missing	The `.ymap` loaded, but the archetype it names didn’t
Black, purple or untextured	Texture dictionary missing or misnamed
Walk straight through it	No collision, or the archetype doesn’t point at it
Invisible wall	Collision larger than the visible model
Pops out of view too early	LOD distance too low in the `.ytyp`
Floats or sinks into the floor	The model’s origin is in the wrong place

The Four Rules That Fix Most Props

Names must match everywhere. The .ydr file, the archetype name, the .ymap reference and the name you spawn.
The .ytyp must be registered with both this_is_a_map 'yes' and data_file 'DLC_ITYP_REQUEST'.
Streamed files live in a folder named exactly stream.
Do a full server restart after adding props. Archetypes register at startup; restarting the resource isn’t enough.

Frequently Asked Questions

Can a prop work with only a .ydr? It’ll stream, but you won’t be able to spawn it by name without an archetype in a registered .ytyp.

Do I need a .ymap for props? Only if you want them placed permanently in the world. Scripted spawns and held items don’t need one.

What’s the difference between .ydr and .yft? A .ydr is a static drawable. A .yft is a fragment, used for vehicles and objects that break or have moving parts.

Do I need a separate .ytd? Not if the textures are embedded in the .ydr. Separate .ytd files make sense when several models share textures.

Why does my prop work in CodeWalker but not in-game? CodeWalker shows you the drawable; the game needs the archetype registered through the manifest, and a full restart. That’s almost always the gap.

Can I edit these files by hand? Some, yes. .ytyp and .ymap files can be converted to XML and edited in CodeWalker. Models themselves are edited in Blender with Sollumz — the full process is in making FiveM props the hard way.

Where to Go From Here

If you just need props, you don’t have to write any of these files yourself. Full disclosure: this is our script — the LMX Prop Creator builds a prop from a photo in-game and writes the .ydr, .ytyp, .ymap and manifest for you, with the naming and both registration lines handled.

But whether you use a tool, a prop pack or Blender, knowing what’s in the stream folder is what turns “it doesn’t work” into a two-minute fix. And if your props are headed into an inventory as usable items, how to add custom food items to FiveM picks up where this post leaves off.