A visible building is not necessarily one file. GTA V separates the appearance of an object, its placement, its definition and its collision. That separation is the reason an object can look correct but have no usable floor, or exist as a model without appearing anywhere in the world.
Start with the responsibility of each file
The terminology below follows the CodeWalker README.
| Extension | Responsibility | Useful question |
|---|---|---|
.ydr |
A drawable: a model and related rendering data | Does the asset itself open correctly? |
.ytd |
A texture dictionary | Are the expected textures available? |
.ydd |
A dictionary of drawables | Is the expected drawable in this collection? |
.yft |
A fragment, including a drawable and additional data | Does this object require fragment behavior? |
.ytyp |
Archetype definitions | Is the object defined correctly? |
.ymap |
Map data, including entity placements | Is an instance placed where you expect? |
.ybn |
Bounds and collision data | Can the player interact with solid geometry? |
.cwproj |
A CodeWalker project | Can you reopen and continue the editing work? |
A YMAP is not a bag containing all of the other files. It can refer to archetypes whose assets are provided by the game or by your resource.
Follow one object through the pipeline
Imagine an original workbench named cw_bench. Its visible shape is authored as a drawable. Its archetype tells the game which asset that name represents. An entity places that archetype at a position with a rotation and scale.
For a practice map made only from existing game props, the game already supplies those definitions and assets. For a custom workbench, you must deliver the dependencies your own asset needs. Copying the placement file alone is not enough.
When an object is missing, investigate in that order: asset, definition, placement, resource. This is a diagnostic strategy, not a promise that every error falls neatly into one file.
Where an MLO fits
The Sollumz interior documentation adds interior structure to the picture. An MLO archetype contains room and portal information; a YMAP places an instance in the world. MLO and YMAP are therefore not competing file extensions.
A collection of walls placed with a YMAP may look like a room without being a room-and-portal interior. Calling the file an MLO, or changing its extension, does not create that structure. Read YMAP vs MLO before choosing your first project.
Keep interchange formats separate
Some authoring workflows export CodeWalker XML, then convert it into a native game asset. Keep both versions when they serve different purposes, and name the folders clearly. For example, cw_bench.ydr.xml is not made into a native drawable by removing .xml from its name.
The linked Sollumz export workflow uses RPF Explorer for XML conversion. Your chosen versions may offer additional export routes. Record the actual route you used instead of mixing steps from different tutorials.
Two manifests with different jobs
CodeWalker can generate game map-manifest data. FiveM reads a resource manifest named fxmanifest.lua. Those are not the same file and they do not replace one another.
A useful handoff note names the final exported files, the archetypes they define, the YMAP that places them, and the FiveM resource that delivers them. That note is much easier to maintain than a folder whose filenames all start with final_final.
YMAP file: open and inspect placements
A YMAP describes map data, including entity placements. A native .ymap and a readable .ymap.xml are not the same representation. Use the matching game-file or XML workflow in CodeWalker. Our browser editor supports a bounded ordinary-entity XML subset, not a lossless editor for every YMAP feature.
For an original exercise, use the three-prop source. If the XML came from Menyoo or Map Editor, identify its schema using the conversion guide before attempting to open it as CodeWalker XML.
YTYP file: check the archetype definition
A YTYP supplies archetype definitions and, for an MLO, interior structure. Registering it in a FiveM manifest does not generate missing drawables or collision. Inspect the names and references, then compare them with the files actually delivered. Use the custom-YTYP manifest example as a declaration reference.
YDR, YTD and YBN: inspect the right layer
| File | When to inspect it | Do not confuse it with |
|---|---|---|
| YDR drawable | The visible model or its rendering setup is wrong | The placement that puts it in the world |
| YTD texture dictionary | Referenced texture data is absent or unexpected | A guarantee that every material reference is correct |
| YBN bounds/collision | Physical boundaries, floors or openings are wrong | Portal-driven visibility between rooms |
| CWPROJ project | You need to recover or organize editor work | A game asset to stream on the server |
Keep source, interchange XML and native exports in different folders. That makes it possible to answer “which file was tested?” without relying on its display name alone.