BSP Decompiling Explained: What a Decompile Really Gives You
BSP decompiling turns a compiled Source map back into a VMF. What comes back, what is lost and what anti-decompile protection realistically achieves.
Decompiling means a tool such as BSPSource takes a compiled BSP file and produces a VMF file again, which can be opened in the Hammer editor. The result is a reconstruction, not the original file: geometry and entities come back to a large extent, the mapper's working structure does not. Because the engine has to be able to read every BSP, a compiled map is never truly secret.
Why BSP files can be decompiled
A BSP is not a sealed container. The format has been known for years, and the engine needs exactly the data a decompiler evaluates in order to load the map: brushes for collision, surfaces with materials, entities as text. A decompiler reads those sections and writes them back into the text format Hammer understands. What is a BSP file? shows how the file is structured.
There are legitimate reasons to decompile. Mappers use it to rescue their own projects after losing the VMF, to investigate problems in a compiled version, or to learn from released maps how something was built.
What a decompile gives back
A good decompile restores a surprising amount:
- the world brushes, reconstructed from the stored brush data
- point entities with all properties as well as inputs and outputs
- brush entities such as doors, triggers and
func_detail - displacements, meaning deformed terrain surfaces
prop_staticprops and overlays- cubemap positions and areaportals, the latter not always in the right place
- the assignment of materials to surfaces
- the contents of the pakfile, which can be unpacked like a normal archive
For someone experienced with Hammer, that is enough of a starting point to change a map and recompile it.
What is missing or only approximate
Anything that only served the editor is not in the BSP and therefore does not come back.
| Area | State after decompiling |
|---|---|
| VisGroups, groups, comments | missing, they are never written to the BSP |
| Instances | collapsed, all contents sit directly in the map |
Entities the compiler consumes entirely, such as func_viscluster | cannot be restored perfectly, according to the BSPSource readme |
| Brush shapes | the BSP keeps the brushes themselves, but vertices of complex brushes come back imprecise, up to invalid solids |
| Tool textures such as clip | partly replaced by nodraw or swapped for one another |
| Lighting | light entities are present, lightmaps have to be recalculated |
| Source files for models and textures | missing, the pakfile only holds compiled versions |
In practice this means rework. Reconstructed brushes can cause leaks or invalid solids when compiled again, and a large map without groups and VisGroups is hard to navigate. A decompile is rarely a finished working file, but usually a usable start.
Why a compiled map is never secret
Three facts cannot be changed:
- Every player who joins a server receives the map file.
- The engine has to be able to read the file completely.
- Whatever the engine can read, another program can read in principle as well.
So if you want to protect a map, do not rely on secrecy. Realistic goals are a higher effort for reconstruction and proof of where a copy came from.
What anti-decompile measures realistically achieve
Anti-decompile measures work in two places. First, they remove information the engine does not need but an editor would find helpful, such as editor IDs or leftover source files in the pakfile. Second, they change how the file is represented so that automatic reconstruction works less reliably and needs more manual work.
| Expectation | Reality |
|---|---|
| Nobody can open my map any more | The engine has to read it, so it stays analysable in principle |
| A decompile is ruled out afterwards | It becomes more laborious and gives worse results |
| The protection lasts forever | Decompilers keep evolving, and so do protection methods |
| Anti-decompile replaces copy protection | The file can still be copied unchanged |
The last point is often overlooked: an obfuscated map runs on any server someone copies it to. Anti-decompile protects your work from convenient further editing, not from being passed on. That takes other means, described in Protect your GMod map from leaks.
The cross-check matters as well. No change to a BSP may damage the map. Serious methods validate the output again and do not release a file that fails that check.
bspmarket.de deliberately words this carefully for its own BSP Protection: the anti-decompile layer makes typical decompile output harder to use, and complete protection against decompiling cannot be guaranteed for Source BSP files. What each level does is listed under BSP Protection and in BSP obfuscation explained. Since a decompile can never be ruled out entirely, a fingerprint is the sensible addition: it makes a copy traceable even though the copy itself cannot be prevented.
Technically possible does not mean permitted
The fact that a map can be decompiled says nothing about whether you may use the result. A map that reflects its author's own creative decisions is protected as that author's work, and decompiling does not change that. Anyone who modifies, republishes or sells other people's maps will generally need the author's consent. GMod map copyright basics offers an overview that is not legal advice.
FAQ
Can every BSP file be decompiled?
In principle every Source BSP can be analysed, because the engine has to read it. How usable the result is depends on the map, the decompiler and any protection applied.
Will decompiling give me my lost VMF back?
Only as a reconstruction. Geometry and entities come back to a large extent, groups, VisGroups and instances do not. Regular backups of the VMF are the better approach.
Does obfuscation prevent decompiling?
No. It hinders typical decompile attempts and reduces usable editor information. A decompile cannot be ruled out.
Does a fingerprint survive a decompile?
That depends on the method and on how much was changed. Methods that rely on several independent signals are more robust against individual changes. There is no guarantee.