Deleting an entity from your own YMAP is not the same as removing a vanilla building from GTA V. A visible object may be placed by another YMAP, rendered by a different LOD, spawned by a script or backed by collision in a separate asset. Identify the source before editing.
This guide starts with a map you own. It then explains the additional checks needed for a vanilla override. It is not a one-click building-removal recipe and does not certify a particular replacement map. Keep a separate backup and test resource; never make your first experiment by overwriting the original game archives.
Identify the object and the file that owns it
Select the visible entity in CodeWalker with the appropriate selection mode. Record its archetype name, world position and owning map/archive information. Take an observation at close range and at a longer distance. Similar-looking objects are not proof that you selected the same placement or LOD.
The CodeWalker README describes inspecting an entity’s YMAP and RPF entry. Use those references to identify the loaded source, not a filename copied from an old tutorial for a different game update. Our prop-identification guide helps separate names, hashes and placements.
Write down whether the object belongs to your own resource, a third-party map you may edit, or vanilla data. Check permissions before distributing a modified third-party resource.
Delete a placement from a YMAP you control
Duplicate the source project into a new revision. Open the intended YMAP in the project window and select the entity by both identity and position. Use that build’s entity removal action, then confirm the entity count changed by exactly one. Do not mistake hiding an item in the viewport for deleting it from the map file.
For a controlled exercise, open the three-prop source example, remove only the middle cone, and keep the original file. The resulting source should contain two placements at the unchanged outer coordinates. This is a source-editing exercise, not an in-game-certified removal fixture.
Recalculate extents and flags, save the native map to a new output location, close it and reopen it. Compare the surviving entities with the pre-edit record. Package the changed map in your isolated development resource using the streaming workflow.
Removing a vanilla placement needs an override strategy
An empty new YMAP does not instruct the game to subtract an entity from another YMAP. You need a deliberate override of the relevant map data, or a runtime approach appropriate to the server’s design. Identify the effective source for the exact game build before copying it into a controlled mod workspace.
Do not hard-code the archive path from an old screenshot. Updates and DLC can change which source wins. Keep the original naming and dependency relationships required by the selected override workflow; test it alone before combining it with other maps that touch the same area.
Limit the change to the intended entity. Document the file you override, the build you obtained it from and the other resources known to overlap. This prevents a small deletion from accidentally replacing a broader world change with an older file.
Why the object or building still appears
| Observation | What to investigate |
|---|---|
| Visible close up, gone far away | A different high-detail placement may still be active |
| Gone nearby, visible at distance | Inspect LOD/SLOD relationships and the distant representation |
| Reappears when another resource starts | Look for a conflicting map override or script-created object |
| The view is empty but the player cannot pass | Inspect the relevant collision, not just the visible drawable |
| The building is gone but part of the scene flickers | Check overlapping geometry, duplicate placements and retained LODs |
These are investigation paths, not guaranteed diagnoses. Change one layer at a time and repeat the same observation before moving on.
Collision is a separate edit
A visible doorway does not create a hole in world collision. Identify which collision asset blocks the entrance and verify that your edit preserves the surrounding floor, walls and terrain. Removing an entire collision file just to open one door can break a much larger area.
The collision lesson distinguishes physical surfaces from interior visibility. The Sollumz collision documentation provides the modeling workflow. Do not treat an MLO portal as a substitute for a physical opening.
Prove the edit and keep rollback simple
Test near and far views, walking boundaries, reconnection and relevant neighboring resources. Compare the untouched revision against the candidate using the same route. Preserve a package containing only the intended overrides and a record of their source build.
When the removal is uncertain, return to the last working resource rather than accumulating more deletions. The release checklist provides a place to record remaining risks before you distribute the result.