Source files for gm_fork, developed by Wouter Pleizier (aka Blueberry_pie/03C0)

For more information, please refer to the thread on Facepunch:
http://facepunch.com/showthread.php?t=1434704

--------------------------------------------------------------------------------

- Content:
The materials and models folders contain the custom content used in the map, so
you'll need to place those in the directory of the game you're mapping for. Make
sure that your version of Hammer has HL2, Ep1 and Ep2 mounted, as a fair amount
of content from those games is used. (Alternatively, use GMad to extract the
required content from the Workshop .gma file.)

The model sources (created in 3ds Max 2009) and their respective QC files are
also included, in the modelsrc folder.


- VMF files:
In addition to fork.vmf, there are some VMFs containing small sections of the
map. These have been instanced and collapsed into the main map, but I figured it
couldn't hurt to also include them separately.


- Optimization:
Due to the large size and open nature of the map (as well as the lack of
planning during development), visibility optimization happens almost exclusively
through fade distances for props (and for some brush geometry using func_lods).
I personally would not recommend this approach for other maps unless absolutely
necessary, as Source simply isn't designed for it.


- Compiling:
Compiling the map takes quite a while. VBSP and VVIS are pretty fast (thanks to
the func_viscluster entities), but the HDR and LDR lighting take around 40
minutes each on my i5 2500K (overclocked to 4.2 GHz). I used Hammer's expert
compile mode with the following settings:
VBSP: -nodefaultcubemap -allowdynamicpropsasstatic
VVIS: default settings
VRAD: -hdr -lights fork.rad -StaticPropLighting -StaticPropPolys -TextureShadows
VRAD: -ldr -lights fork.rad -StaticPropLighting -StaticPropPolys -TextureShadows

Make sure you use my custom VBSP (http://facepunch.com/showthread.php?t=1413597)
which adds support for the func_detail_blocker entity and the -nodefaultcubemap
and -allowdynamicpropsasstatic options.


- Roads:
To see how the roads were made in this map, refer to my displacement roads
tutorial: http://facepunch.com/showthread.php?t=1413669


- Cubemaps:
The map has a single env_cubemap in a pitch black box, which effectively
prevents all objects from reflecting anything. I felt that getting all the
reflections right was too troublesome for a map like this, since a lot of
env_cubemaps would be required (each of which would also increase the number of
texture lookups for the CPU/GPU).

The water in the map uses a separate cubemap texture, which is defined in its
material.


- AI:
Due to the size of the map, generating the navmesh takes a long time (about 4
hours on my PC, if I remember correctly). If you want to generate your own,
remember to set nav_quicksave to 1 or it will probably take over a week to
process. I also recommend entering "ent_fire func_physbox kill" into the console
beforehand, which removes the physics-based gates in a number of areas.

The nodegraph was created in GMod using the Nodegraph Editor addon
(http://steamcommunity.com/sharedfiles/filedetails/?id=104487190). For that
reason, no info_node entities are actually stored in the VMF.


- Soundscapes:
The map uses some custom soundscapes, which can be found in the misc folder.
When creating an addon, GMad disallows the packing of .txt files. This means
that both soundscape files have to embedded into the BSP using bspzip or a
similar tool.