Porting Goldsource maps to Source (Gmod 13)

Hello everyone !

I began playing Garry’s Mod not that long ago, and i quickly found it awesome.
The concept of a sandbox with a community that can always bring new content in the game is awesome.

I saw on the Steam Workshop that there are many addons (characters, weapons etc…) from many games, but when i try to download a map from a same game to put my character in it …well… i don’t find any map from this game.
So i thought “Why not porting them myself ? It should be possible at least for Goldsource maps because Valve did it for Half-life Source”

So i Googled a bit, and i found this:" https://developer.valvesoftware.com/wiki/Porting_Half-Life_maps " for the Goldsource maps (actually i want maps from many other games that i like, but i’ll make other topics for each game)

As you probably can see, this is not really a tuto, and not very well explained and detailed ( for people who don’t handle Valve softwares, like me), but anyway, i tried to do what the page says, but when i come to the Hammer editor part, i can’t open the Goldsource map into Hammer (the latest version of hammer) (the 4.XX).

The problem is not really Hammer, it’s more how to do the whole porting job, the page of the link don’t explain how to do, so :

Can someone here explain, step by step, how to port a Goldsource map (from a game like opposing force, blue shift or CS CZ deleted scenes etc…) to Garry’s mod 13 ?
(a real tutorial would be apreciated)

it’s kind of long so thank you for reading.

http://www.facepunch.com/threads/473582

Valve had the raw source files for all the HL1 maps on-hand.

If you don’t have the source file (ie. not a BSP!) for a Goldsrc map, then oh boy are you in for a world of hurt. Goldsrc maps don’t decompile nearly as cleanly as Source maps do, to the point where the best option is to rebuild the map, brush by brush, using the decompile as a base.

Thank you dude, but i also need to know how to open an old goldsrc map (.RMF) on Hammer 4.1

Can i open it with any game configuration (like Gmod) ? or Hammer needs to be configurated for the Goldource game first

You can’t configure 4.1 for GoldSrc games as far as I know, so you’ll have to open a GoldSrc version of Hammer and replace the textures/models accordingly. Although I could be completely wrong and there might be a way to use WADs with 4.1.

Ha. You are in for the true pain.
I have spent the last 2-3 years porting every blue shift and opposing force map to gmod. And I am still only halfway done with the polishing.
Here is what you should know:
1st- Decompile the bsp using BSPTWOMAP
2nd- open the map file in an old version of hammer and save it as rmf
3rd load the rmf into a source hammer version and save as vmf. Do NOT make a gmod configuration. I tried and it was a HUGE mistake. Make a Half-Life source config if you have it, it is a huge help with the entities.
4th- proceed to repair every brush in the map. This will take from 2-3 hours to 2 days.
5th- fix the textues. Textures work differentely in source, and BSPTWOMAP screws up the textures even further. Use winbspc to get the texture values. Do NOT use winbspc to port the actual maps. It is very innacurate. I had to redo half my work because of that.
6th- fix the entities. Entities work in completely different ways in source so you will have to repair them aswell. Nearly all brush entities will have color set to 0 0 0 and visibility to 0 aswell. change color to white (255 255 255) and visibility to maximum (renderamt-255)

That is about it.
Oh, if there is a specific map you want, chances are I already did it. Call me and I will try to give you a copy of my vmfs.
Peace.

[editline]27th September 2014[/editline]

Oh, and I forgot something VERY important:
Goldsrc maps used texture-based lights. The maps will be dark unless you use the half-life source lights.rad file when compiling. Opfor and Bshift used several new light textures, so you will have to add them with new values to the rad file. I could never get the new textures to light up but maybe you will get lucky.

https://developer.valvesoftware.com/wiki/Porting_Goldsource_content_to_Source
Read the “mapping” part at the very bottom of the page

[editline]28th September 2014[/editline]

Thank you for the answer, it looks like it’s a bit long to do and i don’t want to loose my time to port something that you are already porting.
I will maybe try to do this for Half-life Decay (PC) or CS CZ Deleted Scenes maps.

About the maps that you already ported to source, are them downloadable somewhere ? i would like to have them on Gmod.

Do NOT try to port the Decay maps for the love of all that is holy. I am trying to port them myself and everything wrong with decompiled goldsrc maps is 10 times worse there. they made liberal use of nodraw textures, which really confuses the decompiler. I cannot help you with the deleted scenes maps as I never tried opening them, but power to you if you manage to bring them over.

Now tell me, which maps do you want, and do you want them for rp or for the actual levels?

It’s only to see them, it will be the proof that porting Goldsource maps to Source is possible ( and maybe to make some funny screenshots ). I don’t want any particular map, give me anything you want i’ll be happy. :downs:
You should upload them all on the Gmod Workshop, i think that a lot of players wish to have them like me.

I have not uploaded anything yet as few of the maps are perfect. Once they are perfect, they are ready.
Besides I will also have to upload the converted textures and models…
But that map, of2a3 was it? Yes. It will do nicely.

I am preparing a thread to document my progress. In the meantime, add me on steam, so we can talk more openly. I will try to upload it to the workshop as friends-only once I check friends-only uploading actually exists.
My steam name is “Moon.” moon with a dot in the end.

I’ve been using a custom Gmod configuration for hammer since like 2005 and it works fine. You just have to know what you’re doing.

It’s actually better to remake every brush (and brush entity) from scratch in a new map because you get a much cleaner result that’s more optimized. Valve made liberal use of carve in HL1, which is further trashed by the decompiler.

Again, it’s better to completely remake brush entities than reuse existing broken ones. And you can also replace all of the legacy entities with the modern equivalent (func_wall, illusionary, wall_toggle -> func_brush.) There are some entites that don’t exist between HL1 and Source as well like func_pendulum which have to be implemented as something else like a func_rotating on a timer.

Texture lights in Source are a bit of a pain to get working, but they can work. You’ll have to put lights.rad somewhere outside the Steam directory (like on the c:\ drive) and add “-lights c:\lights.rad” to the vrad compile options. The latest version of vrad has some internal lights.rad and refuses to override with an external file unless done this way.

Another thing is you need to specify the directory the light texture is in (unlike the old lights.rad where you just specify the texture name.) So if the light was named tubelight001 and stored in textures\hl1lights, the lights.rad entry would be:

hl1lights ubelight001 <r> <g> <b> <brightness>

And if you want the actual light texture to self illuminate, you’ll need to add an alpha channel to the texture with the part of the texture you want to glow being a white color with the non-illuminated parts being black. You’ll then have to add “$selfillum” “1” to the texture VMT.

Considering how Source maps tend to decompile on par with “dropped out of a AC130 at max height”, this is saying something.

Uh, what about it? I knew that? I answered your question earlier with that information :v:

There are two known decompilers for Half-Life maps:

  1. BSPTWOMAP

This decompiler will create the entire map out of 1 unit thick brushes. It has lots of trouble with things that break wall spans (doors, windows, sloped surfaces, etc.) and will usually create multiple overlapping brushes where those things exist. It also likes to make pencil thin brushes of infinite length so the map looks like a pincushion from all 2D views. This decompiler can decompile considerably more complex maps than WinBSPC, but there are still maps that it will crash on.

  1. WinBSPC

This decompiler will make a huge single block and carve the entire empty space out of the level you’re decompiling. While this decompiler is more accurate geometry wise, good luck sorting out the massive amounts of carved brushes and mangled textures. It also tends to crash on more complicated levels, badly compiled maps and maps that were compiled using the original HL compile tools.

In either case, you end up with a horrible mess that takes considerable amounts of time to fix. It’s not like Source where you can decompile and recompile the map with only slight issues.

Great. However Half life source just works better for this.

No, it is not. I am sorry but redoing the map from scratch will not only take longer, but the final result will be innacurate. I prefer my method and so far it has worked flawlessly.

Half Life Source has functional func_pendulums. Func_rotating on a timer not only needs said timer, but just does not work properly. Also, func_brush is trash. Tried to use it on texlights and the whole map went dark. I use illusionary to make light sources and brush is useless at it.

An internal lights.rad huh? I suspected something similar. So that is why I cannot change the base values. I tried loading directly in the VRAD command but it did not work. I will try adding paths to the textures, thanks for that.
Curiously, several of these textures lack self-ilumn tags, but illuminate none the less.

[editline]29th September 2014[/editline]

Gigabite:
I tried placing directories in the lights.rad files.
And now my maps are illuminated. You have my eternal gratitude.
You are a mapping God.

It’s always going to be inaccurate because of rounding errors during the compile process and during the decompile. All of the maps I’ve remade were by making all new brushes. Though I don’t really care about accuracy and something that looks similar enough to the original is good enough for my tastes.

You also have to take into consideration the VMF format is much less accurate than the RMF or MAP formats. Since it stores brushes as clipped planes instead of by vertex, you’re going to get corrupted brushes every time you save the map in hammer. Brush based terrain is the worst in the VMF format, it’s almost impossible to get it to not end up corrupted. I learned this the hard way when I ported ctf-lavagiant.

I do agree it takes much more time to recreate the brushes though, some of my remakes took years to finish.

I’ve never made a map for HL:S so I didn’t know they had func_pendulum. I always used a func_rotating or func_door_rotating on a timer and it worked out pretty good.

I’ve never had a problem with texture lights breaking while on func_brush so no idea what the problem you’re having is.

Without a self illumination alpha mask, the entire texture will either be black and emit light or be whatever brightness the texture light specifies and emit light. This is alright if you don’t mind it, but it tends to look better when you only have the parts of the texture that are supposed to emit light be the bright parts.

Here’s an example of a masked texture light in one of my older maps:

http://cloud-4.steampowered.com/ugc/531746613523084300/DE7E58A087BE9AC249F46A3947FE0D99219D266A/

Notice how only the yellow light emitting part is only bright while the rest of the trim texture is dark, instead of the whole texture being overbright.

I prefer going for full accuracy. Besides I only worked with valve and gearbox maps so far, and bsptwomap usually decompiles them with minimal fuss. The only maps to ever give problems and deformed brushes were the Decay ones, which were ports of ports so it is not really surprising.

I made some texlight brushes into func_brush so they would be untouchable and the whole map went dark. Isolating the section with those brushes allowed the illumination to work, and replacing them with illusionary fixed the problem entirely.

Thanks for the tip, this might come in useful one day. For now I am okay with the way it is working.

You mean like the brush deforming even after every face has been made into a triangle? Yes I am familiar with that, unfortunately. Once again, Decay maps.
On a side note, you ported a level from UT? There was a Unreal: RTNP level I wanted to try porting, but I gave up once I could not even edit it properly on unrealed.
Amusingly enough, Quake 2 levels port almost flawlessly to source. Have you ever tried? I should try converting the textures and finish base64. That would be sweet.

Ah, lavagiant. Natural rock formations are the ultimate pain in porting, do you not agree?

Thats funny because Valve still uses it in all of their games.