...at least not completely. It gets to a certain point and does nothing, but eat 90-100% of my CPU.

Quote:
materialPath: c:\program files (x86)\steam\steamapps\common\portal 2\portal2\materials
Loading C:\Program Files (x86)\Steam\steamapps\common\portal 2\sdk_content\maps\mine\mp_coop_cts.vmf
ConVarRef gpu_level doesn't point to an existing ConVar
fixing up env_cubemap materials on brush sides...
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 8 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (0)
writing C:\Program Files (x86)\Steam\steamapps\common\portal 2\sdk_content\maps\mine\mp_coop_cts.prt...Building visibility clusters...
done (0)
Finding displacement neighbors...
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (0) (51108 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 477 texinfos to 193
Reduced 30 texdatas to 28 (888 bytes to 803)
Writing C:\Program Files (x86)\Steam\steamapps\common\portal 2\sdk_content\maps\mine\mp_coop_cts.bsp
2 seconds elapsed

4 threads
reading c:\program files (x86)\steam\steamapps\common\portal 2\sdk_content\maps\mine\mp_coop_cts.bsp
reading c:\program files (x86)\steam\steamapps\common\portal 2\sdk_content\maps\mine\mp_coop_cts.prt
204 portalclusters
655 numportals
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5.

Also, when I start hammer, Windows switches to Aero basic. That hasn't happened before it started doing this.

How long have you let hammer compile before you decided that its not compiling. The latest map I released was taking 20 mins to compile before I optimized it. While compiling, it would look like its not doing anything but it calculating slowly. This usually occurs when you have a very heavy map or you have huge rooms.

First of all, under what configuration are you compiling (Fast, Final, Default, etc.)? Second, as stated above, do you have any immensely large rooms or complicated/spherical/cylindrical brushwork that isn't tied to a func_detail in your map?

Default configuration.
Yes I have a large skybox.
I cut a decagonal (10-sided) hole in a wall and put a prop_testchamber_door in it. With the clipping tool.

Is the skybox completely surrounding the map (please say no)?
Is the wall with the hole tied to a func_detail?

Yes.
No.

Alright, first tie the brush with the hole in it to a func_detail. Do that for any other complex, non-sealing geometry in your map too. As for the skybox: for the record it's very bad practice to completely surround your map with a skybox, not only for compilation but also during runtime. This is because during compilation and runtime the computer has to calculate what is visible and what isn't, and if there's a huge area around the outside of your map it screws things up. If you made the skybox to seal a leak, seal the leak by fixing the mismatched brushes instead. If it's part of an effect (i.e. the white light from the ceiling in destroyed chambers), you can simply fit a brush as though it were a ceiling and texture the face with the skybox texture.

I made the skybox because I want the level to be "outside". Like the hub in Portal 2 co-op.

The Coop hub is "outside", but no skybox is needed!
Just create a big black box around the map. Thats the way Valve made it for every map.

Skotty wrote:
The Coop hub is "outside", but no skybox is needed!
Just create a big black box around the map. Thats the way Valve made it for every map.

Are you sure? -.^
The only maps with giant boxes around the maps are underground or BTS

Yes I meant with "every map" every BTS map (because that's the topic, isn't it?)

Thank you for your help. It complies at a reasonable speed now.