ChaosRobie: Created page with ": ''WIP. Just describing the outputs makes it feel incomplete. Missing CAIME layer explanation. Missing Terry project structure. Need to mention db stuff, including start_pos.'' == Introduction == Let's make one thing clear: There is a "logical" map, and there is a "visual" map. The "logical map" is mostly made in CAIME, which is sort of like an image editor with layers. That's got stuff like regions, where settlements are placed, terrain type that influences how pathfi..."

2026-05-09T00:19:15Z

Created page with ": ''WIP. Just describing the outputs makes it feel incomplete. Missing CAIME layer explanation. Missing Terry project structure. Need to mention db stuff, including start_pos.'' == Introduction == Let's make one thing clear: There is a "logical" map, and there is a "visual" map. The "logical map" is mostly made in CAIME, which is sort of like an image editor with layers. That's got stuff like regions, where settlements are placed, terrain type that influences how pathfi..."

New page

: ''WIP. Just describing the outputs makes it feel incomplete. Missing CAIME layer explanation. Missing Terry project structure. Need to mention db stuff, including start_pos.''
== Introduction ==
Let's make one thing clear: There is a "logical" map, and there is a "visual" map.

The "logical map" is mostly made in CAIME, which is sort of like an image editor with layers. That's got stuff like regions, where settlements are placed, terrain type that influences how pathfinding is calculated, areas that are impassable by armies, "bridges" that allow armies to cross water without disembarking, and beaches that allow armies to disembark into the sea. All of this is exists in 2d and without any visual component.

The "visual map" is mostly made in Terry, which is a 3d map editor. And that's the stuff you can see. Like the ground, mountains, trees, vfx, and props.

You want those visual things to correspond to the stuff in the logical map. For instance, you'd want a mountain placed where there is an impassable area. You can also think about it in the opposite way: you want an impassable area where you placed a mountain. Getting that correspondence is not very easy, since you're using two editors and don't interact directly. It takes planning, reference images, annotations, and working iteratively to get a good outcome.

== Campaign map files and how to make them ==
The files you'd put in <nowiki>campaign_maps/<campaign map name></nowiki>

=== map_data.esf ===
CAIME creates this from a map.hex file. (Technically BOB.exe doing the processing, but there's some missing thing that CAIME is supplying).

This is created very quickly, less than 15 seconds for even the most complex map.

=== pathfinding.ppd ===
CAIME creates this, lots of processing and calculation involved. BOB.exe is unable to create this.

This can take quite a while, more than a half hour for large maps with lots of settlements and roads with intersections.

This file is critical, if you adjust ''anything'' in the map data, you will need to recreate this.

=== spd_data.esf and hlp_data.esf ===
These are both created (at the same time) by giving a special command (using a user scrupt) to the game's .exe before you launch the game. But don't worry those details, because RPFM has a nice interface, there's a checkbox when you do Special Stuff -> Build Startpos.

spd_data.esf is always created very quickly, within a minute. For medium sized maps (Immortal Empires) hlp_data.esf takes 5 minutes. However, for larger maps (Old World), it takes well over an hour.

spd_data.esf is critical, if you adjust ''anything'' in the map data, you will need to recreate it. However, hlp_data.esf is bit less critical. It can be out-of-date, and the game will load without crashing. But pathfinding will be super screwed up, so definitely recreate before you release to the public!

=== trade_routes.ptd ===
CAIME creates this.

Not critical, it can be left out-of-date without any apparent issue.

=== Lookup maps ===
CAIME does a .bmp output of the regions, colored based on their colors from the regions db table. You can process it yourself with BOB into these three images:
* <campaign name>_lookup.dds
* <campaign name>_lookup.tga
* <campaign name>_minimap.tga

Not critical, it can be left out-of-date without crashing, but the map overlays will look a bit weird.

==== elector_counts and hef_court ====
Crop the .bmp output and process it like the normal lookups.

=== camera_heightmap.png ===
Greyscale 16 bit .png image, but with a special "tEXt" png block that gives the scale.

Terry ''should'' be able to generate this, but it crashes when that is attempted.

You can approximate it by using the map's heightmap, scaling it appropriately, and setting that "tEXt" block to the right value.

There's also <nowiki>camera_sea_level_height_map.png</nowiki> which is an optional greyscale 16 bit .png image. It does not have that special "tEXt" png block, so not exactly sure how it's scaling works. Vanilla uses this for the Realms of Chaos campaign, in the areas around the Realms of Chaos.

=== borders.pbd ===
It's in a sub directory, but still very important: <nowiki>/display/borders/borders.pbd</nowiki>

CAIME can create in seconds.

Not critical, it can be left out-of-date without crashing, but the borders drawn on the terrain will look a bit weird.

=== trees.campaign_tree_list ===
This is a visual map thing, but it is in the campaign_map folder for some ungodly reason. It's in a sub directory: <nowiki>/display/trees/trees.campaign_tree_list</nowiki>

BOB creates this from your campaign map Terry project, it uses the heightmap found in your .pack, so you should recreate this anytime you change it.

Put a pin in this.

=== And the rest of the display folder ===
Everything else in <nowiki>/<campaign map name>/display</nowiki> (other than borders.pbd and trees.campaign_tree_list) is boiler plate and you should just copy it from a vanilla campaign map.

== More campaign map files and how to make them ==
The files you'd put in <nowiki>terrain/campaigns/<campaign map name></nowiki>

For all of these, BOB processes them from your Terry project.
=== Height map ===
* full_logic_map.compressed_map
* full_height_map.dds
Process this first, because the tile map, global tile map, trees, and even global_props depends on it. Also, put it into your .pack (and restart BOB) before you do those other things, because that's where BOB looks for it.

This combines both the sea and land heights from Terry.

=== Tile map ===
* tile_list.bin
* tile_mask.dds
This is mostly just the ground and sea floor. And also coastal cliffs and (visual) roads.

Process this after the height map has been processed, put into your .pack, and BOB restarted.

==== Global tile map ====
There's actually a second tile map. The main one has the roads/cliffs as invisible. This global one only has the roads and cliffs.

Sub-directory: <nowiki>/global_map/tile_list.bin</nowiki>

BOB gets this from the main tile map, the one it finds in your .pack. So that means you should process this only after the real tile map has been processed, put into your .pack, and BOB has been restarted.

==== patch_mask.dds ====
Despite it's name, this isn't doesn't define the "campaign_terrain_patch_areas" from the db (that's what terrain_visibility_mask.dds is). This is like some sort of optimization for the boring land/sea floor tiles, as far as I can tell. Annoyingly, it screws up for maps of a certain dimension, leaving small holes in the terrain around complex, northerly coastlines. The fix is to edit it in a hex editor, duplicating a horizontal line of data.

=== global_props.bin ===
This file holds almost everything except the trees and ground. It's pretty big, and can take a few minutes to process (up to 10 minutes).

It's also a little weird, because when BOB processes this it peeks at the map.hex file. So make sure that's synced up with the db, or the process will fail. It also means that you'll want to recreate global_props.bin anytime you add or remove a region. If you don't, it's a mixed bag between weird pop-in/pop-out visual glitches, and I recall seeing a crash too.

==== Models folder ====
An output of processing global_props.bin, all the rivers. What BOB is doing is making each river spline into a bespoke model and outputting it to <nowiki><campaign map name>/models</nowiki>.

==== Lighting ====
Another output of processing global_props.bin, the environment stuff ends up in this subdirectory: <nowiki><campaign map name>/lighting</nowiki>

=== Blend ===
The "blend" texture is the ground/terrain texture. Both output to the global folder:
* <nowiki><campaign map name>/global_map/global_blend.dds<nowiki>
* <nowiki><campaign map name>/global_map/texture_arrays.xml<nowiki>

=== And the the rest ===
Nothing much to say about these:
* colour_overlay.dds
* lf_sea_colour.dds
* snow_mask.dds

==== shroud_heights.dds ====
Terry has a "Fill from terrain" for the shroud height layer, just click that and process. Good enough.

==== corruption mask.dds ====
White = Corruption shows at 1%
Black = Corruption shows at 100%
There doesn't seem to be a way to automatically generate this using Terry or BOB. So hand-painting it is (or clever python scripts!).
For each regions, you want white around settlements, then greys slowly getting darker until the borders are reached.

==== lf_normal.dds ====
You can export a normal texture from Terry, it's in one of the menus. It'll be in .bmp format, and BOB can convert it to .dds

==== terrain_visibility_mask.dds ====
Optional. This defines the campaign_terrain_patch_areas, which are used in vanilla to hide/show the Realms of Chaos.

Tutorial:Campaign Map Making for Warhammer III - Revision history