Goldsource to source?

I am askin’ about to port GoldSrc maps to Source, my goal is only to take their brush works, so I don’t need to worry about entities and stuff…
I’ve google’d around but the guides that I found are a mess or uses ancient stuff with their links broken, so I ask here.

(About “GoldSrc” I mean Opposing Force and Blue Shift)

It depends on if you have the original map source or not is to how hard your porting task will be. If you have the map source, it won’t be that difficult. If you don’t have the map source then I really hope you like the map(s) that you want to port because you’re essentially going to have to remake them from scratch.

If you do have the original map source in .RMF/.MAP form, just open the map in Hammer and copy the entire map to a new VMF. After you do that, you’ll have to remake all of the brush based entities (func_wall, func_wall_toggle, func_illusionary -> func_brush and the rest just tie them to world and back to brush entities.) If you don’t remake the brush entities, they’ll usually cause compile errors related to lighting. The last time I directly ported a Half-life map to Source and didn’t fix the brush entities, they were all solid black in-game. Though this was back in 2004-2005, things have changed since then so YMMV.

If you don’t have the original source to the map then your task just got much more difficult. Unlike Source map decompilers that can generally make a VMF that mostly resembles the original map source, Half-Life has no such luxury due to how the compile tools worked. There are two known map decompilers for Half-Life, the first being “bsptwomap.exe” and the second being “WinBSPC.exe”. Both decompilers have different methods of decompiling the map.

The former (bsptwomap.exe) will create 1 unit thick brushes for every face in the level, but it has issues with holes in vertical wall spans (details, doors, etc.) and will generally create malformed brushes near these areas. Also, some maps that were poorly built or that were compiled with really old compile tools may cause bsptwomap to create infinite length brushes that trash up the decompiled map. Lastly, bsptwomap won’t decompile all Half-Life maps. If the map is too complex, too large or has some other problem, it may not decompile at all. This decompiler is less prone to having this problem than WinBSPC though.

The latter (WinBSPC.exe) can actually decompile maps for several engines (Quake, Quake 2, Half-Life and maybe one or two other games.) It decompiles maps by carving all of the open areas in the map from a large block. While this method is probably more accurate than bsptwomap, it creates considerably more brushes and is much harder to work with in terms of rebuilding the map. The program is also prone to crashing when decompiling maps and has more trouble decompiling maps made with more modern compile tools (MHLT, ZHLT, VHLT, etc.)

In either case, you’ll have to remake the entire map brush by brush with new brushwork because you won’t be able to use any of the existing brushwork due to malformation. I hope you really like the maps you want to port because remaking maps from decompiles like these takes weeks. The additional task of porting it to a different engine just exacerbates an already huge workload.

Besides decompiling I believe you can also export the map’s brushwork as a model file using Crafty, and use Wallworm’s 3DSmax tools to convert it into a model you can then load into Hammer as a base to recreate the map from.

Either way, it’s not going to be fun.

Hm. I see… Well I ported a Blue Shift map for a little test, the problem that doesn’t load texture because GoldSrc uses .wad file instead of .vtf, I tried to convert .bmp to .vtf and .vtm but in VTFEdit I see the texture, but in Hammer they are just black and purple (Missing Texture).

Afaik when you change .vmt of .vtf while in hammer, it’ll go pink and black. Just try to restart Hammer.

Tried that, doesn’t work.

As for textures, I assume your folder structure in the vmt files is probably incorrect.

There are a bunch of HL textures that you won’t be able to do a 1:1 port of to Source because of the texture size. Unlike Source where you can only use power of 2 textures, the HL engine was much more forgiving and you could use any texture size as long as both dimensions were divisible by two.

There are tons of HL textures that are strange sizes like 24, 48, 80, 96, 112, 144 and 192. You can get them to work in source if you compress or expand the dimensions to the nearest power of two, but it’ll look very odd.