Decompiling turns a compiled .bsp back into an editable .map you can open in a Hammer/JACK. It is genuinely useful for recovering your own lost source, or for studying how something was built — but it is a lossy, one-way street done backwards. The BSP does not contain your original brushes; it contains the compiler's output, and a decompiler reverse-engineers brushes from that. Understanding what survives and what does not saves you hours of chasing artifacts. First, the ethics.
1. Only decompile maps you have the right to
Compiling is deliberately one-way; a mapper who ships only a BSP has chosen not to release their source. Decompiling someone else's map to re-release it, or to strip credit, is theft of their work and is treated that way by the mapping community. The legitimate uses are narrow: recovering the source to a map you made and lost, or learning technique from a map whose author permits it. Do that and nothing here is a problem; do the other thing and you have made an enemy of every mapper.
2. Pick a decompiler
The established GoldSrc BSP decompilers are tools like BSPTwoMAP and Winbspc. They read a v30 GoldSrc BSP and emit a .map. They differ in how they reconstruct brushes and how much entity data they preserve, so if one produces unusable geometry, trying the other is worth it. Run it against the BSP and open the resulting .map in your editor.
3. Expect off-grid, ugly brushwork
This is the big one. The compiler splits your clean brushes into rendering faces and throws away the original brush definitions. The decompiler rebuilds brushes by guessing, and the result is:
- Off-grid vertices — corners land on fractional coordinates instead of the grid, so nothing snaps cleanly and editing is painful.
- Fragmented geometry — one original brush comes back as several pieces, and complex shapes come back as tangled invalid solids.
- Invalid / concave solids that will not re-compile without cleanup.
The takeaway: a decompiled map is a reference or a recovery starting point, not a clean source you can tweak and recompile as-is.
4. Expect lost and mangled entity data
Point entities usually survive with their positions, but a lot of their keyvalues do not. Custom keys, targetnames, and settings the compiler baked in or dropped come back missing or wrong. Lighting is a special case: the lightmaps are baked into the BSP and cannot be turned back into light entities, so a decompiled map often loses its light setup or produces a fullbright re-compile. You will be re-doing lighting from scratch.
5. Expect texture and WAD issues
The BSP references textures by name and may or may not contain the texture data (depending on whether the original used -wadinclude). After decompiling you often have to re-point the map at the right WADs, and any embedded textures may need extracting. Missing textures show as the usual missing-texture placeholder until you sort the WAD references — see cannot find WAD.
6. Clean up before recompiling
If your goal is a working re-compile (recovering your own map), budget real cleanup time: snap vertices back to the grid, delete and rebuild the worst brushes, re-seal any leaks the fragmentation introduced (a decompiled map frequently leaks), re-add lighting, and fix entity keys. Treat it as a renovation of a rough draft, not a finished file. A leak from the mangled brushwork is common; the leak and pointfile guide will be your friend.
Common errors
- Decompiled map will not compile / leaks everywhere — the fragmented brushwork left gaps in the world hull. Rebuild the offending brushes and chase the leak with the pointfile.
- Everything is off-grid and impossible to edit — expected. Snap vertices to the grid and rebuild the worst solids by hand.
- Lights are gone / re-compile is fullbright — baked lightmaps cannot be decompiled into entities. Re-light the map from scratch per the lighting guide.
- Missing textures on load — the WAD references did not survive. Re-point the map at the correct WADs.
- Entity does not behave like the original — keyvalues were lost in decompilation. Re-enter them by hand.
Verification
Open the decompiled .map and assess honestly: is the geometry close enough to salvage, or is it faster to rebuild? For a recovery job, clean the brushwork, re-light, fix entities, and attempt a full compile — then load the result and compare it against the original BSP room by room. If it compiles, runs, and matches, the recovery worked. If the brushwork is hopeless, you have at least a spatial reference to rebuild from. And if the map was never yours to begin with, the right verification is simply not to have decompiled it.
