Source files for gm_boreas, developed by Wouter Pleizier (aka Blueberry_pie)
https://steamcommunity.com/sharedfiles/filedetails/?id=1572373847

Source release version 2020-09-26 (VMF version: 2020-02-16)

Feel free to use any of the content provided in this source release (except for
HL2: Ep1/Ep2 content, which is owned by Valve) for any purpose you like. This
includes modifying the map and distributing it, using parts of the map in your
own maps and/or porting the map to other games. Please include a link to the
original Workshop release if you do so, though.

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

CONTENT

The map relies on a fair amount of custom assets and assets from Half-Life 2:
Episode One and Episode Two. All of the assets used in the map (except for stock
GMod content) are included in the content folder. Copy the contents of this
folder to your game directory before compiling.

The source files of the custom assets are not included in this release.

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

EMBEDDED CONTENT

The embed folder contains various assets that should be embedded in the BSP with
the same folder structure. I do not recommend shipping these as loose files
inside your addon, because they will either not load at all or override stock
content in other maps that the player has installed.

Note: built cubemaps are also included in the embed/materials/maps/gm_boreas/
folder. At the time, the latest update to gm_boreas always caused GMod to crash
when building the cubemaps, so I resorted to manually embedding the cubemaps
from a previous compile. I do not know if this problem was specific to my
hardware/installation and if it still occurs, but I've included them just in
case. Only embed these if necessary. If you do, remember to change the name of
the gm_boreas folder to the filename of your BSP before embedding. Also, bear in
mind that the cubemap filenames correspond to the coordinates of env_cubemap
entities in the map, so this process will not work for env_cubemap entities that
you've moved or added yourself.

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

COMPILING

The compilers folder contains the compilers that were used to build the latest
version of the map. These compilers were modified and built by me and have the
following features:
- Support for func_detail_blocker
- Support for dynamic/physics props as prop_static
- Large address aware, allowing for more memory usage on 64-bit systems
- Increased compile limits (doubled or quadrupled)

Warning: some of the increased limits in these compilers are higher than what
GMod supports. If GMod crashes while loading your map, take a look at the
fullness percentages in your compile log. The compiler may report that certain
things (most notably brushsides and texinfos) exceed 50%, when in reality they
will have exceeded 100%.

The default GMod compilers will likely not work for compiling this map, so you
should probably use these custom compilers instead. Other custom compilers (e.g.
Slartibarty's Slammin' compilers) might also work, but I have not tested this.

The map was compiled in Hammer's expert compile mode with these settings:
VBSP: -allowdynamicpropsasstatic
VVIS: default settings
VRAD: -ldr -lights boreas.rad -StaticPropLighting -StaticPropPolys -TextureShadows
VRAD: -hdr -lights boreas.rad -StaticPropLighting -StaticPropPolys -TextureShadows

Known issues:
- If VRAD crashes for no apparent reason, try running it with -threads 1. This
  is much, much slower but it fixes some rare crashes.
- When compiling both LDR and HDR lighting, running two separate VRAD processes
  tends to be more stable than using the -both parameter. However, the second
  VRAD run seems to mess up the first run's detail prop lighting (e.g. if you
  run LDR first and then HDR, the detail props will have incorrect lighting in
  LDR). Whichever lighting mode is most important to you, run that one last.

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

AI

For the nodegraph: info_node entities are placed throughout the map. GMod
should be able to generate a functional nodegraph on its own using these nodes.

For the navmesh: before generating, I strongly recommend setting the convar
nav_max_view_distance to 1 (not 0, because this causes a default distance to be
used). While this may limit some bot functionality, it also massively reduces
the calculation time and file size, which is pretty much essential for a map of
this size. (For reference: on an i5-2500K, the default nav_max_view_distance
caused the calculation to take 5 days, and it resulted in a 700 MB navmesh file
that took ages to load.)

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

ROADS

The roads, paths and landing strips are a single huge prop with an overlay
material. This allowed for more flexible texture mapping and better integration
with the terrain, but unfortunately it also means that it can't be modified
inside Hammer. The prop was made by importing the terrain displacements into a
3D modeling tool (in my case, 3ds Max via Wall Worm) and then creating
road-shaped cutouts of the terrain geometry.

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

FOLIAGE

To reduce the number of draw calls and improve performance, all of the trees are
batched as much as possible. There are 27 unique props, each containing a large
number of trees (about as many as a single model in Source can fit) arranged for
a specific section of the terrain. Unfortunately, this means that it's not
possible to move or delete individual trees, unless you edit the model it's
contained in.

The bushes in the map are all detail props. Originally, I'd let the compiler
spawn these and use func_detail_blocker where necessary. However, I ended up
needing so many func_detail_blocker brushes that I exceed the BSP limits. To
work around this, I took the generated detail props from a simplified version of
the map and converted those to prop_detail entities that I could place in the
VMF. This way, no func_detail_blockers are necessary at all (though they can
still be found in a hidden VisGroup in the VMF). It's unconventional and
honestly kinda horrible, but prop_detail entities and automatically spawned
detail props are handled the same way by the compiler so the end result is the
same. (If you want to let the compiler spawn detail props like normal, remove
the prop_detail entities from the VMF and change the density in boreas.vbsp)