Basic Source mapping Created 10 years ago2014-03-15 20:51:59 UTC by DiscoStu

I thought I'd try Source mapping again. Last time I did, the procedure was:
1. Download SDK
2. Run Hammer
3. Make maps

So I downloaded Source SDK, and attempted to run Hammer.

The configuration information for the game you're trying to edit is invalid or missing.
[Run anyway] [Cancel] [Help]

I get this for every version of the Source engine listed. [Help] eventually takes me here but it pretty much says to run the game (let's say, EP2) which I am absolutely certain I've played not too long ago.

The only exception is selecting Half Life 2 (not Ep1/2) where I don't get this message. Great! At last I get to make some maps. File > New...

Failed to load the default scheme file. The map views may be missing some visual elements.
[OK]

...and now the three views show nothing. I can't make brushes, I can't place entities, I can't zoom or move any of the views. A quick search on google didn't tell me anything useful. What went wrong?

Yeah, it's fucked.
You need to download

Source SDK Base 2013 Singleplayer

Source SDK Base 2013 Multiplayer

then navigate to

Steam > steamapps > common > SourceSDK > bin

and start Hammer.exe manually from the appropriate game folder you want to map for.

Not ideal, but it works.

Thanks. I did download those already. How am I expected to guess that I have to start it from a different place? This is weird.

goes off to try the above

You have run the games that you're trying to map for prior to loading the SDK, right?

Also, there's that Reset Game Configuration option: have you tried that?

^^

If what Ant said doesn't sort it, you might try uninstalling all the base sdk files, and follow Archie's list anew.

Btw, if u interested in cs mapping at all, I'd highly recommend the csgo SDK, as everything works great, without any additional fuckery

If you're wanting to make a mod with custom code, you'll have to wrangle with the Source SDK, but if you just want to make maps for an existing game, run Hammer.bat inside the game's bin folder. This applies to HL2, TF2, CS:S, DOD:S and Portal 1. The other games have their own SDK/authoring tools that you need to install and use. Make sure your games have been converted to SteamPipe (they need to be in the common folder).

e.g:
TF2: Steam/SteamApps/common/Team Fortress 2/bin/Hammer.bat
HL2/EP1/EP2: Steam/SteamApps/common/Half-Life 2/bin/Hammer.bat

I had already run EP2 before and still had the errors, but I followed Archie's instructions and everything seems to work just fine.

So far I'm just messing with it and tossing brushes around. I could really use Tetsuo's book right now

There really aren't too many differences to the hammer you're used to, and where there are changes, there are only improvements.

The Valve Development Community
First and foremost, The VDC, is your #1 resource for Source SDK questions, and exploring new features and theory. Additionally, there are ALWAYS links at the bottom of each article, if you want to expand your knowledge further.

Materials
Textures are handled a little differently, but nothing you can't adjust to in 5 minutes fucking around. Soon as you want to mess with custom materials, head to VDC for a full overivew on materials, VTF, and vmt files, and get yourself VTFEdit by Nem, if you don't already have it.

Lighting
Texture lights exist in source, but i would recommend shying away unless you have a specialized use for them, e.g., lighting the underside edge of a door, but mostly you are going to want to get used to using pointlights, light_spots, and of course the light_environment entity is still there. (i'm still having a hell of a time with lighting, but CSGO lighting is so pretty, you don't have to work to hard to get very nice results)

Models
Most of your models in game are going to be prop_static. If it's something your want a player to be able to move or break, then use prop_phsyics(prop_phsyics_muliplayer for cs or dm games). If a static model is not showing up as a prop_static, then try it as a prop_dynamic, and it should then work. (There is a way to tell whether models are dynamic or not in the model browser, but i can't remember how atm)

Displacements
Displacements are awesome for many reasons, probably you know their primary reason to exist is to create beautiful, smooth terrain, quickly and cheaply for the engine to render, but they have other uses. A big one for me is that on huge maps, you can increase your brushwork budget by changing ordinary walls to displacement surfaces. Remember Displacements don't block VVIS, nor do they seal your level.

Overlay Tool
Info_Overlays are the newest way to apply decals, and they are awesome. VDC says they are more expensive to use than decals(called Infodecals in Source), but personally, i never, ever use infodecal anymore, mostly becasue they are buggy. Overlays can be moved and rescaled as much as you want and are much more stable than infodecals. Important infodecal note: if you alter or move a brush with an infodecal on it, it may "disappear". if this happens, simply double click on the little entity box thingie, select the Brush Faces keyvalue. Then, click on the "Pick" button, and then select the brush(or ctrl+select multiple brushes) that the overlay is to be applied to, and finally, hit "Apply". The overlay should now show up again.

VisGroups
VisGroups are MUCH improved in Source, and can easily help you organize bigger levels into more-manageable chunks. If you don't like corralling your map's brushes and entities into groups, there's always Auto-Visgrouping, which automatically takes every type of brush, tool brush and entity, and gives you toggles you can check/uncheck. Finally, a nice new addition to Source VisGroups are the quickhide/quickunhide toggles on the tool bar, that will make your mapping life much easier when you learn to use them.

Smoothing Groups
Besides using texture alignment to make brush faces flow together, you now have smoothing groups. If you have an area where brush edges don't seem to fit together, making them share a smoothing group will help them blend tremendously. (i don't uses these too often, since the stock smoothing is so good, but i'm sure i could use them more to good effect)

Cubemaps
Use cubemaps to control and tweak all the reflections in your map. These are another thing i never really learned to use too well in Source, but mostly, i just put one cubemap at eye level(80 units?) in each distinct area of the map. However, I've heard you can assign individual brush faces to each cubemap, directly controling what faces reflect, though I've never done this myself.

Compiling
Compiling in Source SDK should be a seamless transition for you, since all the options besides HDR exist. There are still "Normal" and "Expert" compiling of course, but 99% of the time i use Normal(fast VVIS, fast VRAD and HDR), unless i'm working on final lighting. An important compiling note: ALL NON-VISBLOCKING BRUSHES IN YOUR MAPS SHOULD BE FUNC_DETAIL! If not your compile will be bogged down by unecessary VVIS calculations, which will dramatically slow down your compile, and zero benefit to performance. Compiling is MUCH faster for Source SDK all-around if you follow this simple rule, even on the biggest maps!

Notes on Brushwork
As you may have heard, Hammer 4 sometimes has "issues", keeping complicated groups of verticies exactly where you left them, but take heart, the superior smoothing in Source makes it likely you won't notice very slightly off-grid points in the game, so my advice: don't obsess too much about grid points unless you are getting a visual error in the game. Important Brushwork Note: If any brush begins to "act strangely", e.g., when trying to clip a brush and it refuses to let you split it into 2 equal halves, scrap that brush and start over!

General Hammer Tips
If any tool or hotkey or anything in hammer starts acting "weird" or other than expected, immediatley SAVE your work and restart hammer! Also, even though hammer autosave works pretty good, it is by no means bulletproof(meaing it simply fails to work sometimes), so my strong advice is to regularly make backups of your cherished hard work!

That's all i can really think of for now, but don't forget: the most important reference tool for Source SDK users is The VDC!

Thanks Captain, first class introduction!

It's curious that you mention the off-grid vertices. I just tried to do some extremely simple VM and screwed it all up. It refused to move my points to anywhere near a 1-unit grid and everything looked weird. I wasn't even using a very close zoom.

Does this mean I have to learn how to make models?

Hmmm, you have a screen cap? You shouldn't have any trouble with normal, run-of-the-mill brushes staying on the grid, although, sometimes even normal cubes get messed up, but this is pretty rare.

If a brush is "acting strangely" at all, e.g., you try clipping it and it refuses to split into even halves, scrap the brush and start over!

Another general tip: If anything starts acting fucky, like normal tools and hotkeys stop working or act strangely, immediately save your work and restart hammer

Sorry, scrapped the whole map. I was trying to VM an arch to make a round hole in a square block. Done countless times in GS without a hitch. But now, the triangles refused to go into the square's corners or anything close to it. I'll try again tomorrow.

Oh god, off-grid vertices. This seems to be a Hammer bug of some kind. I get the same thing. Giant pain in the ass, and seemingly impossible to fix.

Welcome to source! Use the bin folder. Its easiest!

@Ant & Stu

Click

It appears that Source would compile a map this way regardless of whether or not the vertices were on-grid in the editor. It's just a massive pain in the ass to work with and looks horrible in Hammer. The end result is not affected.

In your screenshot, the error is much less than 1 unit. In my case, the error was around 3-4 units. Yes, THAT bad.

Cheers for that, Archie.

Wow, this thread is like a tutorial about Source engine map making

I'm not complaining!