I had some significant reservations about posting on this topic publicly, but I’ve concluded that I will not be the only person ever to realize it could be done and more to the point I’m offering a workaround for something (namely, providing up-to-date sources for all all areas of the game) that the developers have stated they themselves plan to do but are understandably too busy to bother with at the moment. That said, please be polite in your decompiling adventures.
The information below is out-of-date. Check lower in the thread for a version of the decompiler made by Flavrans which does not need the workaround described below.
Getting a Decompiled Map [/size]
-
The actual maps which Black Mesa runs need to be extracted from the vpk files like any other game asset. This can be done by dragging bms_maps_dir.vpk over the vpk.exe program stored in the game’s ‘bin’ folder.
-
You will need ata4’s bspsrc utility. The current best (only?) place to get it is from the releases section of the author’s github page.
-
Unzip and run bspsrc.bat.
-
Leave the advanced compilation options as defaults.
-
Add as many maps as you want and decompile. The program will throw a number of “invalid vector” errors.
-
This will produce decompiled VMFs with some bad data in them that will cause Hammer to crash if opened directly.
Making A Decompiled Map Functional[/size] -
In order to make the VMFs you created up above work, you will need to open them in a text editor like Notepad and remove a block of bad data.
-
The data you are looking for are a bunch of spurious lighting origins lumped together near the bottom of the file. They take the form of blocks like this:
[tt]entity[/tt]
[tt]{[/tt][tt] “id” “”[/tt][tt] “classname” “info_lighting”[/tt][tt] “targetname” “sprp_lighting_”[/tt][tt] “origin” “”[/tt][tt]}[/tt]
The coordinates in the origin are occasionally something absurd like “0 0 103161719131765890000000000”- it’s these Very Large Numbers that break Hammer when the map is loaded. However, all of these lighting origins will cause the props they are connected to to light improperly, and will likely be in a place that will cause map leaks, so there’s nothing to be gained by only deleting the weird ones. -
There are typically several hundred of these entites (Gasworks has nearly two thousand!) but since they are all in a row and the decompiler never includes any “legitimate” lighting origins you can just find the first one, find the last one, select everything in between, and delete.
-
The map can now be opened in Hammer, but I find that the reconstructed optimization (areaportals, occluders, and hint brushes) almost universally have an extremely negative effect on both compile time and in-game performance, and may cause compile errors. So, I typically use the ‘auto’ visgroups to hide everything except for those three categories, select the entire map area, and delete all of it. This makes a map that is barely playable and will take a long time to compile, but it’s better than nothing and you can fill in at least basic optimization yourself.
-
Very rarely other elements may be decompiled in a way that causes errors; it’s typically possible to just delete them and make new ones that look the same.
-
If you’re looking to update one of the maps like the outdoor ones that only have had new static props added since the official VMF release, you are probably better off just using hammer’s “entity report” or visgroup functionality to delete every prop_static from the official map, select every prop_static from a decompiled map, and copy them over. This will let you use the new props with the original optimization.
