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.