Quick question for those a bit more experienced than I in setting up Hammer - I’ve been looking at Valve’s developer wiki, and the current installation method for the Source SDK is insanely convoluted and flat-out doesn’t work on most modern development environments (the current versions of Visual Studio and XCode are apparently totally incompatible). Is there a way of running Hammer and editing, say, HL2 content without having to install the full SDK, or is it an all-or-nothing type of affair?
Nah, I already tried that with Quake maps. I had to create new UV maps for bakef material anyway. So I just made additional uv1 map for lightmap and disabled automatic generation of lightmap UV by UE4 when importing the mesh.
Why not to use Trenchbroom instead?
If I’m not mistaken, Trenchbroom primarily authors for Quake 1 format BSP, which is not as powerful as what you can do with Hammer in regards to things like displacement. Also, seeing as most of the work in HammUEr seems to be aimed at making UE4 and Hammer as interoperable as possible, it seems like a good idea to try to use it.
You can install just the authoring tools for certain Source games (L4D1 or 2, Portal 2)
Pretty sure a HL2 install has hammer installed in the \bin directory by default.
Have a look at the Sledge Editor. It’s an open source alternative to Hammer.
.map format, not .BSP. BSP needs to be compiled by a compiler that culls faces that won’t be visible, creates PVS and lightmaps. Either way, personally I think building main CSG layout is what I want to use either Trenchbroom or DarkRadiant (Doom 3, which I have more experience with), and everything else can be done in UE4.
I am not sure what displacement is used for in HL2 maps, but I doubt it’s something you couldn’t have done in UE4 using landscape tool more efficiently (displacement sounds something you’d use for terrain).
Displacements are not only used for landscapes, but also for tunnels and other curved surfaces.
See this video by joe wintergreen, for example.
They’re basically doom3 patches, but more flexible?
The displacement tool does a lot that you can’t get done with the UE4 landscape tool (or any tool in UE4). Take the Antlion Caves in Episode 2, for example:
https://c2.staticflickr.com/2/1467/25601417015_cf6ba2f664_o.jpg
https://c2.staticflickr.com/2/1581/24974741413_89d29a96bf_o.jpg
To each his own. Better off modeling it in 3D package. Otherwise you’d have to learn all ins and out of 3 different packages. So much for efficient workflow o.O
Not to mention convoluted workflow: Displacement - Valve Developer Community
Doom 3 patches were meant to be used for things that are better done when making a map, which are cables, maybe rails, round’ish architectural elements. None of the organic surfaces were made with patches in Doom 3, because sculpted, decimated and baked terrain will always beat patches/displacement (well, I am guessing it’s up to the skills of the creator in either case).
If someone has no clue about 3D apps, but very proficient with Hammer and its displacement tool, then by all means that’s the obvious choice. If someone is like me, proficient with 3D app, but not with Hammer and its tools, then it’s better to just stick to your guns and do layout in Trenchbroom/Radiant or even Hammer, but sculpt everything organic.
So if someone doesn’t know Hammer at all, and planning on staying with UE4, might as well just spend time learning UE4 tools and 3D app, as in the future Epic might just roll out better CSG / mapping tools and time spent learning something obsolete will be a waste.
Just my 20c 
Btw, I made a few test files you might find helpful (for using .proc to import geometry):
Basic cube:
.map: cube64.map - Google Drive
.proc: cube64.proc - Google Drive
Basic “room”:
.map: room.map - Google Drive
.proc: room.proc - Google Drive
.proc format specs: idTech4 ModWiki - ModWiki
I think you’d only need to worry about “model” blocks. Areas, portals, nodes and shadows volumes are specific to id Tech 4. Although if someone makes stealth games, shadow volumes could be used to define areas where player is in the “shadows” and not visible to the enemy. Areas probably could be used to define some zones.
Note that if models on the .map are flagged as “inline” and the map is recompiled, models get embedded into .proc and if you import .proc, then you get not only map, but also all the static models that were “inlined” into .proc
Plus .proc contains only visible geometry, so none of the “nodraw”, “caulk” will be there. Not sure about triggers or other brushes.
We were just correctin’ you 
Better to keep the “x workflow is better lol” out of this thread if we can. There are others for that!
But… isn’t the whole reason for using something like HammUEr so that we don’t have to resort to using a 3D package for basic geometry? IMO @JoeWintergreen laid out the reasons for the benefits of BSP-style brushwork over ‘just use Maya’ pretty well in his videos.
Like it’s been said, it’s X vs Y workflow. Whatever works for you.
What i am doing wrong?
http://rghost.ru/private/8zsTSTBF6/54abebc4365e95523150927ee4356c5e/image.png
http://rghost.ru/private/8X8Fqq9qz/608bb0126288460e1aac6ed2000c91dd/image.png
Missing some pertinent information here, but it looks like this might the HL1 version of crossfire that got converted to… map instead of vmf and is therefor using the broken 1.1 map importer that got fixed in the latest 1.1 decal alpha? (and was fine in 1.0 too)
(Also looks like there’s some Z fighting going on for some reason)
This isn’t real.
This can’t be real.
THIS IS UNREAL.
No seriously, this is amazing.
Also, if that’s Crossfire, and you decompiled it from HL1, your output .map is bad. There’s no good decompiler for HL1.
You could get a very good .vmf of it, though, by decompiling the Half-Life: Source version with VMEX.
I’ve just been leaving lightmap res as the default for the most part, which I think is 16 or 32?
Not sure why your builds take so long, but unless you’re cranking the lightmap res way up it won’t be a HammUEr-specific thing. Slow CPU?