Source files for gm_boreas, developed by Wouter Pleizier (aka Blueberry_pie)
Source release version 2020-09-26 (VMF version: 2020-02-16)

Download: https://www.dropbox.com/s/1okqatkyr8spdjj/gm_boreas_source.zip?dl=1
Mirror 1: https://drive.google.com/file/d/15VcbC2uKYyNGMu11J-qM3wv2YgxeQ5Un/view
Mirror 2: https://s.gvid.me/uw/mirror/ko/blueberry_pie/gm_boreas_source.zip

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.

I've put together some notes that may be useful. Please make sure you've read them before getting started with the source files.

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.

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.

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.

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.)

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.

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)