# Terry, the guide: Total War: Warhammer III's terrain editor, from your first battle map to campaign terrain > Terry is the 3D terrain editor in Total War: Warhammer III's Assembly Kit. This guide takes you through it step by step: opening it, reading its window, moving around, painting, making a first battle map and seeing it in game. It then gathers what is known about campaign map terrain, which the kit does not ship, learnt while porting a whole map into Warhammer III. Page: https://bretonia.dev/atelier/en/terry/ · Atlas of Bretonnia, modders' workshop · updated on 2026-09-25. Plain-text version, for readers and AIs; the diagrams are described in words. Reviewed on 25 September 2026, update 9.0. Written against its sources, the Assembly Kit on patch 8.1, CA's wiki and tw-modding; what 9.0 changed on our project has been added, the rest has not been rechecked point by point. ## What Terry is, and what it does in the public kit **Terry** (*Terrain Metadata Editor*) is Creative Assembly's (CA) 3D terrain editor, shipped with the Total War: Warhammer III Assembly Kit. It is where a terrain is made: relief, textures, vegetation, props, logical zones, lighting and sounds. It is not a separate program: it is a **mode of Tweak**, the kit's editor. Terry does not write the files the game reads, but **sources**, in the kit's `raw_data` folder. **BOB**, the kit's builder, builds them into `working_data`; **RPFM** puts them into a pack. Terry starts BOB itself: **File → Process with BOB**. > **What Creative Assembly says**: CA presents Terry as "the primary tool for developing campaign maps and battlefields". But for the public kit, CA warns that only the creation of **battle tiles** is supported. In plain terms: for battles, the kit has what you need; for campaigns, what is known comes from the community. - **In the public kit**, Terry makes battle tiles and battle maps, with their logic (deployment, playable area, capture points), and prefabs. - **The kit ships no campaign terrain**: in the Warhammer III kit, `raw_data/terrain/` only holds `battles/` and `tiles/battle/`. - **No command drives Terry**: you can only open it; the rest happens in its window. The journey of a battle map, from Terry to the game: 1. **Terry**: You paint the tile (relief, textures, props, logical zones) and place it in a tile map. (`.terry`, `.layer`, `.tif`, `tile_map.png` in `raw_data`) 2. **BOB**: It builds the tile map, then the tile, into game files. (`working_data/terrain/…`) 3. **RPFM**: The pack: the built files, a `battles_tables` row, a text, an image. (`my_map.pack`) 4. **In game**: The map appears in custom battle. This guide follows that journey, then gathers what is known about campaign map terrain. > **Before you start**: You need the Warhammer III **Assembly Kit** (Steam → Library → Tools), installed on the same drive as the game, as RPFM requires; **RPFM**; a *vista*, that is a ready-made tile map that will serve as scenery (the tw-modding tutorial provides some, taken from Warhammer II); a **drawing program** that shows the pointer's position in pixels (the tutorial mentions GIMP). ## Terry's vocabulary A few words come up everywhere. Here is the meaning this guide gives them. *Diagram: Nested words.* In the diagram: Nested words · a battle map, from the outside in · Tile map · the scenery all around the tile, borrowed from a vista (a ready-made tile map): you take its tile_map.png and climate_map.png · Tile · `.terry` · the ground you fight on, which you paint · Rasters · `.tif` · images in which each pixel carries a value: relief, texture blend… · Layers · `.layer` · groups of entities: a File Layer is a .layer file; a Logical Layer is just for tidying · Entities · props, prefabs (ready-to-place assemblies) and logical entities: deployment zones, playable area, capture points… Terry's words nest: the tile map, the scenery borrowed from a vista, surrounds the tile; the tile is a .terry project, its rasters (.tif images) and its layers; a layer holds entities. | Word | Meaning | |---|---| | Tile | a piece of terrain made in Terry: relief, textures, props, logic. A battle map is a tile placed in a tile map. | | Tile map | the large terrain, assembled from tiles, around the battlefield; your tile has its place in it. On a campaign map, `tile_map.png` says which kind of tile goes on each hex: land, sea, coast, road. | | Raster | an image in which each pixel carries a value: a height, a texture blend, a mask. One `.tif` file per saved raster (relief, texture blend…). | | Vista | a ready-made tile map, reused as scenery around your tile; the Warhammer III kit ships none (see the FAQ). | | Layer | a group of entities. A *File Layer* is a `.layer` file; a *Logical Layer* is just for tidying. | | Prefab | a ready-to-place, reusable assembly of objects; battle or campaign. | | Logical entity | what the game reads without showing it: deployment zones, playable area, AI hints, no-go zones, capture points. | | Playable Area | in battle, the logical entity bounding where movement orders can be given; it also sets where units rout and reinforce from, and the minimap's edges (CA). CA's introduction page adds that its edges bound the camera. | | Campaign playable area | the `campaign_map_playable_areas` row describing a campaign's map; its `terrain_folder` column names a battle terrain. | | BOB | the kit's builder: it turns the sources in `raw_data` into game files, in `working_data`. Each execution is called a **run** here. See [the BOB guide](https://bretonia.dev/atelier/en/bob/). | | `raw_data` / `working_data` | what the kit's tools read (your sources) / what they produce (the game files). | | Catchment | an export variant of the same map (`catchment_01`…), picked by the `catchment_name` column of the `battles` table. On a campaign, catchment maps pick the battle map according to the location. | ## Opening Terry Since Terry is a mode of Tweak, there are three ways in, all leading to the same window. - **From the kit's launcher**: In Steam (Library → Tools), start the Warhammer III Assembly Kit, then pick **Play Battle Map Editor: Terry**. (According to the tw-modding wiki's Custom Campaign Settlement Skins page (Warhammer III part, ChaosRobie).) - **From Tweak**: Open `binaries/tweak.modder.x64.exe` in the kit folder, then the **Plugins → Terry** menu. (According to the same page.) - **From the command line**: From the kit's `binaries` folder: `tweak.modder.x64.exe /standalone TerrainMetadataEditor`. (It is the command the launcher option runs; the only known one for Terry.) **How to check.** The window is titled `TWeak - Terry`. It takes a while to come up: about 25 seconds for us. On start-up, the Project Wizard appears. > **Never guessed options**: Don't try any option other than this one. "Illegal option format" has been seen with BOB (`-h`, `--help`): a box that blocks the program, and a script waiting on it hangs. Don't try it on Terry or Tweak either. ### The Project Wizard The **Project Wizard** appears on start-up (*Show on startup* box) and reopens with **File → Project Wizard…**: it offers recent projects and the **New** tab, which it opens on (tw-modding). In Warhammer III it shows three icons. The right-hand one, a dotted box, creates a **prefab**, battle or campaign (tw-modding, Custom Campaign Settlement Skins). The kit only knows three project types: `tile`, `tile_map` and `prefab` (file `working_data/Terry/entity_configuration.xml`). So the other two icons are probably the tile and the tile map (not checked on screen). ## Terry's window Terry's window is made of panels that can be detached and docked: the layout is adjustable, and yours may differ. The figure shows a common layout, with numbered markers: menus and toolbars at the top, scene hierarchy on the left, properties at the bottom and on the right, 3D view in the centre, BOB's messages at the bottom right. *Diagram: Terry's window and its nine areas.* 1. **Menus and toolbars**: File, View, Tools; toolbars open from View → Toolbars. 2. **The Basic toolbar**: tools 1 to 4 (select, move, rotate, scale), four painting modes, the Process with BOB globe (Ctrl+P), World or Editor View; then Entity Creation (Visual, Logical, Other). 3. **Scene Hierarchy**: entities, sorted into layers; a double-click makes a layer active (in red). 4. **Entity Properties**: the selection's properties, editable for several objects at once. 5. **Project Errors**: whatever would stop the map working in game. 6. **The viewport**: the 3D scene: the tile grid, the playable area, the deployment zones (Alliance 0 = attacker, blue in Warhammer III's Terry; 1 = defender, dark red; the 2016 docs had it the other way round: trust the number). 7. **Tool Properties**: the active tool's settings: brush, or a prefab picker. 8. **Map Properties and Settings**: the project's settings; Terry's own (autosave, BOB, camera). 9. **BOB's messages**: bottom right, during a run: pop-ups, according to tw-modding. Terry's window, in a common layout (diagram): panels can be detached and docked, yours may differ. | Panel | What it is for | |---|---| | **Viewport** | the 3D scene. *World View* shows a game-like preview; *Editor View* adds the debug lines. The G key switches between them. | | **Scene Hierarchy** | the entities, sorted into layers: a *File Layer* per `.layer` file (at least one per project), *Logical Layers* for tidying. Double-clicking makes a layer **active**: it turns red, and new objects land in it. Unticking *Export* turns it into a reference layer, which is not exported. | | **Entity Properties** | the selection's properties, editable for several objects at once. Bottom left. | | **Tool Properties** | the active tool's settings: the brush, or the choice of a prefab, with a search field. | | **Map Properties** | the project's settings. Bottom right. | | **Settings** | Terry's own settings, not the map's: autosave, BOB options, overlays, camera, preview environment (*Set As Default For Project Type* button). | | **Project Errors** | whatever would stop the map working in game. | | **Toolbars** | through **View → Toolbars**, or the **Tools** menu. *Basic*: tools 1 to 4, the four painting modes, *Show in Explorer*, World / Editor View, and the export: the globe with an arrow, **Process with BOB** (*Export Map* in the first Warhammer). Then *Advanced*, and *Entity Creation* (*Visual*, *Logical*, *Other*). | ### A project's files - `.terry`: an XML file describing the project type, its rasters and its scene. - One `.tif` per saved raster (`.height..tif`, `.blend..tif`…): the relief, the texture blend… The kit's example tile declares eight rasters but saves only two. - The `.layer` files: one per *File Layer*, with its entities. - `.terry.user`: the preview settings. In these XML files, a property carries the name it shows in Terry, in lower case, with spaces turned into underscores: *Lighting File* is written `lighting_file`. Handy for finding in a file what you set in the window. ### Coordinates - The Y axis is altitude, pointing up. - **In battle**, three extents: the *Usable Area*, a 2,048 m square centred on the battlefield, where physics and unit pathfinding apply; the tile map, drawn out to 8 km from the centre; the *Playable Area*, where movement orders can be given, which also sets where units rout and reinforce from, and the minimap's edges (CA; according to its introduction page, its edges also bound the camera). An 8 × 8 tile is 2,048 m across (read off the kit's example tile): placed in the centre of the tile map, it covers exactly the Usable Area. - **On a campaign map**, the axes are those of hex space: see campaign terrain, below. ## Getting around: camera and shortcuts These shortcuts come from CA's documentation. The keyboard ones are in the Warhammer III kit's shortcut file (`working_data/Terry/local/keyboard.xml`); the mouse ones in CA's pages and the kit's status tooltips (`working_data/Terry/status_tooltips.xml`). Ctrl+S and Ctrl+Shift+S are missing: the file lists "save as" with no key, and "save" not at all. > **Non-QWERTY keyboards**: The file names keys by their letter, on the model of a QWERTY keyboard (W, A, S, D for the camera). We do not know whether Terry reads the letter or the key's position: on an AZERTY keyboard, for instance, try both (Z, Q, S, D sit where W, A, S, D are). *Diagram: Keyboard and mouse cheat sheet.* In the diagram: Cheat sheet: keyboard and mouse · keyboard from keyboard.xml and CA; mouse from CA's pages · Camera · W · A · S · D · move · Shift: faster · Q · E · rotate · C · up · down · R · top-down view, centred · Z · zoom to selection · Letters of a QWERTY keyboard. On AZERTY, try both: W A S D, then Z Q S D. · Tools and view · select · move · rotate · scale · Tab · edit the entity · align the terrain under the selection · Shift · + · raise it · Alt · + · lower it · G · world / editor view · H · coloured relief · Brush · [ · ] · size · O · P · opacity − / + · N · M · other value − / + · , · . · palette ← / → · Mouse · left click: select, paint · right click or Esc: leave the tool (select mode: menu) · wheel: zoom · middle · drag: pan · Alt · + middle: rotate · Shift · + middle: up, down · Ctrl · + · P · Process with BOB · (or the globe) · Ctrl · + · S · not confirmed in Warhammer III · save through File → Save · Also in the file; meaning to be checked · Shift · + · C · switch camera · L · local or world axes · Shift · + · T · clamp and orient to terrain · Shift · + · place tool Terry's keys as the Warhammer III kit declares them, and the mouse as CA describes it. Letters are those of a QWERTY keyboard: see the "Non-QWERTY keyboards" box. Ctrl+S is not in the file: save through the File menu. | Keys | Action | |---|---| | W A S D (Shift: faster) · Q / E | move · rotate | | C / X · R · Z | up / down · top-down view, centred · zoom to the selection | | wheel · middle button · Alt + middle · Shift + middle | zoom · pan · rotate · up or down | | right-click or Esc | leave the current tool | | 1 2 3 4 · Tab | select, move, rotate, scale · edit the entity | | Shift + drag · Ctrl + drag | duplicate · rotate the selection | | Ctrl+G / Ctrl+U | group / ungroup | | Ctrl+A · Ctrl+D · Ctrl+I · Ctrl+H · F | select all · select none · invert the selection · hide · freeze the selection | | [ / ] · O / P · N / M · , / . | brush size · opacity − / + · "other value" − / + · previous / next palette | | hold Shift · Alt + click · Ctrl+Alt + mouse | quick smoothing · pick a value · brush size and rotation | | 5 · Shift+5 · Alt+5 | align · raise · lower the terrain under the selection | | H · G | coloured relief (topography) · world / editor view | | Shift+C · L · Shift+T · Shift+2 | switch camera (probably perspective or orthographic) · local or world axes · clamp and orient to the terrain · place tool (meanings deduced from the file's command names: **to be checked**) | | Ctrl+N · Ctrl+O · Ctrl+P | new · open · **Process with BOB** | | Ctrl+S · Ctrl+Shift+S | save · save as (**unconfirmed** in Warhammer III) | > **Ctrl+S: unconfirmed in Warhammer III**: CA's documentation gives Ctrl+S (or **File → Save**) to save and Ctrl+Shift+S to save as. In the Warhammer III kit's shortcut file, "save as" (`SaveProjectAs`) is listed with no key, and "save" is not listed at all; we have not confirmed them. Until you have tried them yourself, save through the **File** menu. Two commands have no default key: *CopyCamera* and *PasteCamera*. They copy and paste the viewpoint through the clipboard, in the form `camv3;eye x;y;z;target x;y;z`: a way to compare two states of a terrain from the same angle. To give them one, the *ConfigureKeyset* command is probably the shortcut settings (its menu label is still to be checked); keys are stored in `keyboard.xml`. ## The painting and creation modes Terry works in **modes**: pick a mode, a tool, then paint or place. The four painting modes are on the *Basic* toolbar; the creation modes on the *Entity Creation* toolbar and in the **Tools** menu. *Diagram: The four painting modes.* In the diagram: The four painting modes · Height · `Terrain Height Painting` · paints the relief · `.height..tif` · `Add · Subtract · Absolute · Smooth · Erase` · Texture · `Terrain Texture Painting` · paints the textures, one channel each (grass01, mud01…) · `.blend..tif` · `Normal · Smooth · Erase · Replace` · low flow: textures blend softly · Forest · `Terrain Forest Painting` · paints the forest texture: trees above 60% · `.blend..tif` · forest01 channel (kit's example tile); deduced: the kit has no forest raster. · a "hybrid" texture mode, for forests (CA) · `60%` · Other · `Terrain Painting (Other)` · overrides the computed logical ground type · `GroundType raster` · file name to be checked · `Set · Clear` · same texture, two ground types · A · B · Brush gestures · left click · paint · right click · Esc · leave · Shift · smooth · [ · ] · size · O · P · opacity · Ctrl · + · Alt · + mouse: size, rotation · Alt · + click: sample (textures) The four painting modes on the Basic toolbar: what each paints, the file it writes and its operations (the kit's tool_state.xml), then the brush gestures. ### Relief: Terrain Height Painting - Three panels. *Maps*: the rasters and their layers (**Add Layer** on right-click), which blend in order. *Operations*. *Brushes*: **New Round** creates a round brush, with *Scale*, *Hardness*, *Size Jitter*… - Warhammer III operations: *Add*, *Subtract*, *Absolute*, *Smooth*, *Erase*. - To see slopes steeper than 45° in red: **Settings → View 3D → Overlay → Land No Gos**. ### Textures: Terrain Texture Painting - Each channel is one of the project's textures (`grass01`, `mud01`…). - A low *flow* blends textures into one another. - Operations: *Normal*, *Smooth*, *Erase*, *Replace*. ### Forests: Terrain Forest Painting You don't place trees one by one: you paint the forest texture, and forest grows wherever that texture exceeds 60%. ### Logical ground: Terrain Painting (Other) This mode paints **logical** ground types: what the game knows about the ground, regardless of the texture you see. ### Objects: Entity Creation (Visual) - Entities: *Prefab*, *Building*, *Prop*, *Decal*, *VFX*, *Polygon Mesh*, *Terrain Hole*, *Vegetation* (*Place* or *Paint*), *Procedural Exclusion Zone*, and lights. - While placing, [ and ] set the scale; Shift + mouse, the rotation. - **A lake** is a `water_plane` prop, *Surface Oriented* unticked, placed in a hollow of the relief. Water shallower than 0.5 m stays passable, with a penalty; deeper water is impassable (CA). ### Logic: Entity Creation (Logical) - Entities: *AI Hint*, *No-Go* / *Go Region*, *Deployment Zone*, *Deployment Zone Region*, *Playable Area*, and, in Warhammer III, capture points. - The kit keeps these entities for battle projects. A campaign project has its own: `CampaignSettlement`. *Diagram: The battlefield from above.* - A. **Tile map**: the scenery all around, borrowed from a vista; drawn out to 8 km from the centre (CA). - B. **Your 8 × 8 tile**: the ground you fight on, which you paint, in the middle of the tile map. - C. **Usable Area**: the same square as the tile (B): an 8 × 8 tile is 2,048 m across (read off the kit's example tile); placed in the centre, it covers exactly the Usable Area, 2,048 m centred on the battlefield, the only place with physics and unit pathfinding (CA). - D. **Playable Area**: where move orders can be given; its edges set where units flee and reinforcements arrive, and the minimap's edges (CA, Creating Zones); CA's introduction page adds that they bound the camera. - E. **Deployment Zones**: Alliance 0 = attacker, 1 = defender; in Warhammer III's Terry, 0 is blue and 1 dark red (the 2016 docs had it the other way round): trust the number. Each zone has its additive region (+), created with it (tutorial); an optional subtractive region (−) cuts a piece out (CA). - F. **Capture points**: for a domination map: type domination 1, 2, 3; importance score; from 80 × 80 to 180 × 180 (tutorial). - G. **Reinforcement lines**: AI Hint attacker or defender teleport reinforcement line: a short two-point line; about 20 units long is enough (tutorial). - H. **Procedural Exclusion Zone**: laid between the playable area and the tile's edge, to make the map lighter: no procedural vegetation outside play, grass but also forest trees; repaint the forests you want by hand (tutorial). - I. **No-Go**: a closed polygon marking an impassable area (CA). - J. **Defensive Hill**: an AI Hint showing the AI a defensive position: a closed polygon; left open, a probable crash (CA). A battle map seen from above: your tile in the middle of a tile map borrowed from a vista, and what you lay on it (logical entities, exclusion zone), marked by letters. ### Advanced tools: Advanced and Other A ruler to measure; *Snap BBox* and *Snap Verts* to align; the grid and snapping; a perspective or orthographic camera; *Sound Marker* to place sounds; *Camera Bounds*, which limits the editor's camera only, not the game's. ### Several variants of one map A layer can carry an **export type** (`catchment_01`…). The `catchment_name` column of the `battles` table then picks the variant the game loads. That is how one terrain gives both a domination map and a classic battle. ## Your first battle map, step by step This walkthrough follows the tw-modding wiki's Warhammer III tutorial, completed with CA's documentation. Two pieces of advice first. **Save often**: CA warns that Terry sometimes crashes. And set the **autosave** in *Settings* (on our install, it was set to 15 minutes). Terry keeps its autosaves in `working_data/Terry/local/autosave/` and logs its errors in `working_data/Terry/local/terry_error_log.txt`, in the kit folder. A battle map is **two** Terry projects. The **tile** is the ground where the fighting happens, which you paint in detail; the **tile map** is the scenery around it, drawn out to 8 km (CA), which you borrow from a *vista*. Only a 2,048 m square in the centre, the *Usable Area*, has physics and unit pathfinding (CA). The figure shows both projects one above the other, with their files, BOB's two runs and the `battles_tables` row that links it all to the game. *Diagram: The files of a battle map.* In the diagram: raw_data · what you make · Tile map · `terrain/battles//.terry · tile_map.png` · `climate_map.png · explicit_tiles` · created once, after the tile: Tools → Create battle for tile… · The tile · `terrain/tiles/battle///.terry · .layer` · `.height..tif` · `.blend..tif` · what you paint: relief, textures, props, zones · `explicit_tiles: x,y` · = where the tile goes · BOB: 1. the tile map then 2. the tile · working_data · what the game reads · The output · `terrain/battles//: tile_map.bmd,` · `tile_list.bin, map_info.xml…` · `terrain/tiles/battle/…:` · `tile_height_map.compressed_map, blend0.dds…` · RPFM: declare it · `battles_tables: key · type · specification` · `= terrain/battles//battle_environment · screenshot_path` · `(image 3:1)` · `battles_localised_name_` · then: the pack installed, without the kit's example map, ticked in the launcher, in custom battle A battle map: the tile map (the scenery, created once) places the tile (what you paint); BOB builds the tile map, then the tile; RPFM declares it in battles_tables. *Diagram: A battle map, move by move.* In the diagram: A battle map, move by move · save often, through the File menu: Terry sometimes crashes (CA) · Terry: the tile, then the tile map · grey tag: the project open in Terry · Create the tile · the tile · Project Wizard → New: a battle tile · Save it straight away · the tile · File → Save As…: map name and tile set in lower case, size 8x8, climate · `.terry` · `.layer` · `.tif` · Paint it · the tile · relief, textures, forests, then the props · Place the logic · the tile · Tools → Entity Creation (Logical): a Playable Area, two Deployment Zones · Alliance 0 · attacker · Alliance 1 · defender · The Project Errors panel reports nothing. · Create the tile map: once is enough · the tile · Tools → Create battle for tile… · `tile_map.png` · `climate_map.png` · `explicit_tiles` · Place your tile in it · outside Terry · tile_map.png and climate_map.png: a vista's; explicit_tiles: change x,y (black square's corner) · BOB: the tile map, then the tile · after each run, bob.log ends with Exit code: 0 · A run on the tile map · the tile map · open it, Process with BOB (Ctrl+P), then reload it · Your tile is in its place. · A run on the tile · the tile · reopen it; in Map Properties, untick legacy vegetation generation; then Ctrl+P · RPFM, then the game · Declare it with RPFM · the pack, a battles_tables row, the name, the image · Test it · in a custom battle, with the pack enabled in the launcher The ten moves of a first battle map, in order: in Terry, the tile, then the tile map; two BOB runs, tile map first; RPFM declares the map, and you test it in a custom battle. 1. **Create the project.** In the Project Wizard, on the **New** tab, choose a battle tile. The exact label of that choice is not confirmed in Warhammer III. 2. **Save it straight away** (**File → Save As…**): the dialog asks for the **map name**, in lower case (a folder name, not the name shown in game); the **tile set**, a folder name of your own, in lower case (the tutorial, which makes a domination map, calls it `domination`); the **size**, 8x8, to stay compatible with Warhammer II's tile maps; the **climate** (which drives, among other things, grass and trees). Leave the bottom box ticked, as the tutorial says (its label is not confirmed here). *Check*: going by the kit's example map, the tile is stored in `raw_data/terrain/tiles/battle///`. The *Show in Explorer* button opens the folder: a `.terry`, at least one `.layer`, some `.tif` files. 3. **Paint** the relief, textures and forests, then place the props. To make the map lighter, the tutorial places a *Procedural Exclusion Zone* between the playable area and the tile's edge: no more grass outside play, but no more trees in that band's forests either; it repaints them by hand. *Check* in *World View* (G key), the game-like preview, and with H, the coloured relief. 4. **Place the logic**, with **Tools → Entity Creation (Logical)**. A **Playable Area**: 2x2 to 3x3, the tutorial advises, without giving the unit; without one, the game sets it between 800 and 1,300 m depending on the number of units, or fits it to the deployment zones, whichever is larger (CA). Two **Deployment Zones**, each with its additive *Deployment Zone Region*: **Alliance ID 0 for the attacker, 1 for the defender**, *Zone ID* at 0. In Warhammer III's Terry, alliance 0 shows in blue and 1 in dark red (CA's 2016 documentation had it the other way round): trust the number. For a domination map, **capture points**: type *domination 1/2/3*, importance *score*, from 80 × 80 to 180 × 180; the tutorial adds a second region to each deployment zone, of type *guerilla exclusion additive*, for vanguard deployment (the opposite alliance cannot deploy in it), and makes sure no player can vanguard-deploy onto a capture point. And **reinforcement lines**: an *attacker* or *defender teleport reinforcement line* AI Hint, a short two-point line; about 20 units long is enough, the tutorial says. *Check*: the zones show in the 3D view, and the **Project Errors** panel reports nothing. 5. **Create the tile map** with **Tools → Create battle for tile…**: Terry creates its project in `raw_data/terrain/battles//`. Once is enough, the tutorial says; after that you work in the files it created. *Check*: the folder holds a `.terry`, `tile_map.png`, `climate_map.png` and `explicit_tiles`. 6. **Place your tile in the tile map.** In that folder, replace `tile_map.png` and `climate_map.png` with those of an existing *vista*, a ready-made tile map that will serve as scenery. Then, in `explicit_tiles`, change the first two numbers of the line `x,y,tile path,0` (see right after the list): x,y is your tile's top-left corner in `tile_map.png`, in pixels. An 8 × 8 tile in the centre of a 64 × 64 tile map goes at 28,28; the kit's example map has its own in the same place. 7. **Build the tile map**: open it in Terry, run **File → Process with BOB** (Ctrl+P, or the globe on the *Basic* toolbar), then reload it. *Check*: your tile is in its place. 8. **Build the tile.** Reopen it. In **Map Properties**, untick *legacy* vegetation generation (in the `.terry`, the `use_legacy_procedural_vegetation` property). Then **Process with BOB**. The tile map always comes before the tile; after that, when you touch up the tile, only the tile needs re-exporting. 9. **Declare the map to the game with RPFM**: see the next section. 10. **Test it** in a **custom battle**, with the pack enabled in the launcher. By default, the tutorial says, `explicit_tiles` holds something like this: ``` 3,3,terrain/tiles/battle/lzd_hills_infield/chaqua_pit,0 ``` Change only the first two numbers. x,y are read in pixels of `tile_map.png`, x from the left, y from the top: open the image in your drawing program and point at the top-left corner of the vista's black square, that is 28,28 in a 64 × 64 tile map (tutorial). Check that the path is your tile's, from `terrain/`, with forward slashes; keep the final `0`. *Diagram: Placing the tile in the tile map.* In the diagram: Placing the tile in the tile map · `a vista's tile_map.png · 64 × 64 pixels` · x → · y ↓ · black 8 × 8 square: your tile's place · `explicit_tiles` · `28 , 28 , terrain/tiles/battle// , 0` · x = the column, counted from the left. · y = the row, counted from the top. · your tile's path: check it (from terrain/, with forward slashes). · the tutorial's final 0: keep it. · Reading x,y · open the image in a paint program and point at the black square's top-left corner · The kit's example map · it paints its tile in the tile's colour, (0, 255, 127), in the same place, with no explicit_tiles. · one BOB run on the tile map, then reload it: your tile is in the middle · avoid: a path starting with raw_data/, backslashes In a vista's tile map, your tile takes the black square's place: explicit_tiles gives its top-left corner in pixels, then its path. An 8 × 8 tile in the middle of a 64 × 64 tile map goes at 28,28. The kit's example map places its tile differently: its tile (`raw_data/terrain/tiles/battle/test_tiles/assembly_kit_example_tile/`) declares the colour (0, 255, 127) in its `.terry`, and its tile map's `tile_map.png`, 64 × 64 pixels, carries a block of it from 28,28 to 35,35, without `explicit_tiles`. > **How to check it worked**: After each BOB run: its message appears at the bottom right of Terry; `bob.log`, in the kit's `binaries` folder, states on its first line how many actions were selected (`N action(s) were selected for execution.`) and ends with `Exit code: 0`; and the outputs are there, under `working_data`, at the same path as their source. For the tile map: `tile_map.bmd`, `tile_list.bin`, `lf_normal.dds`, `full_lf_logic_map.compressed_map` and `map_info.xml`. For the tile: `tile_height_map.compressed_map`, `blend0.dds`, `bmd_data.bin` and the grass and tree lists. Read `bob_warnings.log` too, in the same place: BOB's logs only keep the last run. ## Declaring it to the game with RPFM, and testing it BOB has produced the game files. What remains is to put them in a pack and tell the game the map exists: that is the job of a `battles_tables` row, a text and an image. RPFM does all of it; its basic moves are in [the RPFM guide](https://bretonia.dev/atelier/en/rpfm/). *Diagram: Declaring the map: one row, four references.* In the diagram: One row, four references · battles_tables: a classic row copied, its key changed first · `battles_tables` · file never named data__ · `key` · `myprefix_my_map` · a key of your own · `type · classic` · `specification` · `terrain/battles/my_map/` · trailing slash included · `screenshot_path` · `ui/frontend ui/battle_map_images/my_map.png` · the space is intended · `team_size_1 · 1` · `team_size_2 · 1` · `singleplayer · 1` · `multiplayer · 1` · `battle_environment` · `weather/battle/wh_day_clear_04.environment_group` · The name (.loc) · `battles_localised_name_` · what the player sees · The tile map · produced by BOB, in your pack · The image, 3:1 · in the pack · The atmosphere · not to be confused with battle_environment_audio · the size of the two sides, and where the map is offered · Then, from pack to game · The pack · without the kit's example map · PackFile → Install · then enabled in the launcher · Custom battle · the map, with its name and its image One battles_tables row declares the map: its key gives the name (in a .loc), specification points to the tile map, screenshot_path to the image, battle_environment to the atmosphere. Then the pack, without the kit's example map, is installed, and the map is tried in a custom battle. 1. **Create a pack** and add the `working_data/terrain` folder to it, as the tutorial does, then remove everything that is not yours: the kit's example map (`assembly_kit_example_tile_map`, `assembly_kit_example_tile`, `_tile_database/TILES/test_tiles_assembly_kit_example_tile.*`) and any game file you may have extracted there. *Check* in RPFM that only your folders remain: the tile map, the tile and its `_tile_database/TILES/_.*` entry. 2. **Add a row** to `battles_tables`: right-click the pack → **Create… → Create DB** → `battles_tables`, a file named after you (never `data__`, which would replace the game's table); copy a `classic` row from the game, **Paste as New Row**, and change the key **first** ([the RPFM guide](https://bretonia.dev/atelier/en/rpfm/)). That way you keep every column; fill them in from the table below. 3. **Add the text** `battles_localised_name_`: it is the name the player will see. 4. **Add the image** at the path given by `screenshot_path`: three times as wide as it is tall (tutorial). The space in `frontend ui` is intended. 5. **Save the pack**, then **PackFile → Install** in RPFM, which copies it into the game's `data` folder. A square image with the same name as the pack serves as its thumbnail (the tutorial plans it for the Workshop). Then **enable the pack** in the launcher. 6. **Test** with a **custom battle**. A domination map is tested in multiplayer, or with a community mod (see the tw-modding tutorial). | battles_tables column | What it takes | Example | |---|---|---| | `key` | your map's key: a key of your own, never that of a game map | `myprefix_my_map` | | `type` | `classic` or `domination` | `classic` | | `specification` | the tile map's folder, with the trailing slash, as in the tutorial; CA mostly writes `terrain\battles\\`: if you copy a CA row, keep its form | `terrain/battles/my_map/` | | `screenshot_path` | the map's image; it must be in the pack | `ui/frontend ui/battle_map_images/my_map.png` | | `team_size_1`, `team_size_2` | the size of the two sides | `1`, `1` | | `singleplayer`, `multiplayer` | where the map is offered | `1`, `1` | | `battle_environment` | the atmosphere: an `.environment_group` file from `weather/battle/` (CA leaves it empty in 715 of its 1,216 rows); not to be confused with `battle_environment_audio`, right next to it | `weather/battle/wh_day_clear_04.environment_group` | | `catchment_name` | the export variant to load (see the modes, above) | your layers' export type; with no export type, to be checked (259 CA rows leave it empty) | > **How to check it worked**: In RPFM, the pack holds `terrain/battles//`, the tile's folder under `terrain/tiles/battle/` and its entry in `terrain/tiles/battle/_tile_database/TILES/`, the table, the text and the image, and nothing from the example map. In game, the map is in the custom battle list, with its name and image, and the battle opens on your terrain, each army in its deployment zone. ## Campaign map terrain: what we know > **Advanced level**: For a battle map, you are done. What follows is for those who want to touch a campaign map's terrain. In five lines: the kit ships no campaign project (you start from ChaosRobie's); rasters are sized on the number of hexes; sea, coasts and roads are declared in `tile_map.png`; BOB's runs follow a precise order; a map the game's database does not know stops at 6 actions out of 15. For a campaign map, the kit ships nothing: no Terry project, no raw terrain data. That is true of the Warhammer III kit, and of the Warhammer I kit. Yet Terry can open a **campaign-type** project. ChaosRobie, the author of *Immortal Empires Expanded*, proved it: he rebuilt the Immortal Empires map as a Terry project, and shared that project with the community. Here it is, dissected: it is the blueprint to follow. | Item | What it is | |---|---| | the `raw_data/terrain/campaigns//` folder | missing from the kits: this is what you create | | `.terry` | the project, in XML (version 27): the map's settings, **one entity per region**, named after its database key, and ten terrain layers | | `.terry.user` | the preview settings: without it, Terry shows neither water nor trees | | `rules.bob`, two files | BOB's recipe is in the parent folder, `raw_data/terrain/campaigns/rules.bob`: `[Terrain]` with `PrefabRoot = art\prefabs\campaign` (ChaosRobie's project's value; `battle` for a battle), `TileDatabase = terrain\tiles\campaign\_tile_database`, `HeightPatch = true`…; the one in the map folder only holds `[Copy]` and `[+AssetGraph]`, which copy the raw project into the kit's `retail` folder on every run. Recreate only the map folder and you lose the recipe. | | `tile_map.png` | the tile map: land, sea, coasts, cliffs, roads, one colour per type | | ten `.tif` rasters | relief, sea floor, texture blend, colours, shroud, trees, corruption, snow, patch visibility | | one `.layer` per region | placed objects: set dressing, mountains, water | *Diagram: The campaign project, folder by folder.* In the diagram: The campaign project, folder by folder · after the project ChaosRobie shared · `raw_data/terrain/campaigns/` · missing from the kit: to be created · `rules.bob` · BOB's recipe, in the parent folder · `[Terrain]` · `PrefabRoot = art\prefabs\campaign` · `TileDatabase = terrain\tiles\campaign\_tile_database` · `HeightPatch = true` · `…` · `/` · the map's folder, to be created too · `.terry` · the project, in XML (version 27): ten terrain layers, one entity per region, named after its database key · `.terry.user` · the preview settings: without it, no water and no trees · `tile_map.png` · one colour per type: land, sea, coast, cliff, road · `*.tif` · ten rasters: relief, sea floor, texture blend, colours, shroud, trees, corruption, snow, patch visibility · `*.layer` · one per region: the placed objects, set dressing, mountains, water · `rules.bob` · `[Copy]` · `[+AssetGraph]` · only copies the raw project into the kit's retail folder, on every run · Recreate only / and you lose the recipe. · One more region: one more entity in the .terry, and one more .layer. The kit ships no campaign project: you rebuild one on the model of ChaosRobie's. BOB's recipe is in the parent folder's rules.bob; the one in the map folder only copies the project. Remember that the project is **tied to the map's list of regions**: one more region means one more entity and one more layer. The logical half (regions, ground, roads, towns) is made in CAIME (Campaign AI Map Editor), the Campaign Map Toolkit's editor: [the CAIME guide](https://bretonia.dev/atelier/en/caime/). ### Raster sizes follow from the number of hexes Every resolution is proportional to the map's number of hexes, the CAIME one (read from ChaosRobie's project and applied to our map). The last column gives the example of our map, 400 × 440 hexes. | Layers | Pixels per hex | Example, 400 × 440 hexes | |---|---|---| | `Height`, `HeightSea`, `BlendCampaign`, `ColorOverlay`, `ColorOverlaySea` | 8 (plus 4 rows) | 3200 × 3524 | | `HeightShroud` | 4 (plus 2 rows) | 1600 × 1762 | | `CampaignTree`, `CorruptionMask`, `SnowMask`, and `tile_map.png` | 2 (plus 1 row) | 800 × 881 | | `PatchVisibilityMask` | one cell per patch of p tile-map pixels, p = ceiling(longest side / 128) | 114 × 125 | The arithmetic: 400 × 8 = 3200 pixels wide, 440 × 8 + 4 = 3524 high. For the patches, the tile map is 800 × 881: p = ceiling(881 / 128) = 7, and you count whole patches (800 / 7 gives 114, 881 / 7 gives 125). *Diagram: One hex, four resolutions.* In the diagram: One hex, four resolutions · 8 × 8 pixels · + 4 rows in all · `Height` · `HeightSea` · `BlendCampaign` · `ColorOverlay` · `ColorOverlaySea` · 4 × 4 pixels · + 2 rows in all · `HeightShroud` · 2 × 2 pixels · + 1 row in all · `CampaignTree` · `CorruptionMask` · `SnowMask` · `tile_map.png` · `PatchVisibilityMask` · one cell per p × p pixel patch of tile_map.png: p = ceiling(longest side / 128) · here p = 7: one patch ≈ 3.5 hexes · Our map: 400 × 440 hexes · 8 px per hex, + 4 rows · `3200 × 3524` · 4 px per hex, + 2 rows · `1600 × 1762` · 2 px per hex, + 1 row · `800 × 881` · p = ceiling(881 / 128) = 7 · `114 × 125` · 800 / 7 → 114; 881 / 7 → 125: whole patches only · Grid too small: ground in one corner only; elsewhere, roads and the sky showing through. · Read off ChaosRobie's project, applied to our map. A campaign Terry project's rasters are sized on the hex count: 8, 4 or 2 pixels per hex, plus a few rows; PatchVisibilityMask counts patches. A schematic view of one hex. > **Why PatchVisibilityMask matters**: Ground is only drawn on the patches this mask covers. With a grid that is too small, Terry draws ground in one corner of the map only; elsewhere you only see special tiles, such as roads, with the sky showing through. It happened to us. ## Campaign terrain: conventions, BOB's order and limits ### Conventions They were established on our project and on ChaosRobie's; CA does not document them. - Rasters run **north to south**; heights are in world units, water at 0. - x points east, z north, and the world is **hex space**. Terry stretches the rasters by 2/√3 along z: a world point (x, z) reads a raster at row z × √3/2. - **The sea is declared in `tile_map.png`** (`sea` tile, colour 83, 141, 213), not by height. The sea floor must be below 0 everywhere, even under land, or the water is not drawn. - The sea surface is made of **large water planes placed as objects**, at height 0. Their pivot must be inside the map, or BOB drops them ("Failed to find valid quadtree node"). - **Coasts are painted with coast types**: a one-hex band (`cliff_gen`, `sea_coast`) along the whole sea. Each hex of the band must have a single run of one to three sea neighbours, or "Failed to find tile" and a hole in the shoreline. Paint it in whole hexes: drawn pixel by pixel, it cost us 148 "Failed to find tile"; by hex, none. - **Roads**: each road hex is a solid 2 × 2 pixel block of `tile_map.png`; a thinned line leaves holes. *Diagram: Sea, coast, roads in tile_map.png.* In the diagram: Sea, coast, roads · `tile_map.png: 1 hex = 2 × 2 pixels` · The sea · `sea · 83, 141, 213` · yellow: the coast (see below) · water plane at 0, pivot inside the map floor below 0 everywhere, even under land · The coast · a one-hex band; each hex has · 1 to 3 sea neighbours in a single run · a one-hex spit: "Failed to find tile", a hole · `sea_coast · 255, 255, 0` · `cliff_gen · 253, 3, 1` · shore (sea_coast) or cliff (cliff_gen): same rule. · whole hexes: 0 failures; drawn by the pixel: 148 (our map) · Roads · a solid 2 × 2 pixel block per hex · a one-pixel line: holes · After each BOB run, count the "Failed to find tile" lines in bob_warnings.log: aim for 0. · Established on our own project and ChaosRobie's; CA does not document it. In tile_map.png each hex is a 2 × 2 pixel block: the sea is declared by its colour, the coast is painted as a one-hex band, roads as solid blocks. Any departure gives "Failed to find tile", so holes. - **Rivers**: Warhammer III has almost no river tiles left. Its rivers are meshes placed as objects, or sea channels lined with coast. - **Starting from CAIME**: [the CAIME guide](https://bretonia.dev/atelier/en/caime/) has CAIME export `tile_map.png` (**Tools → Export → Baseline Tilemap**) for the Terry project. Caveat: we have not tried it (our `tile_map.png` is written by script); CAIME's documentation contradicts itself on what the image contains; and if it carries rivers, they will call for river tiles, which Warhammer III has almost none of. Count the "Failed to find tile" after the first run. - **What the kit lacks** (the campaign tile database, `terrain/tiles/campaign/_tile_database`, with the legend of `tile_map.png`'s colours; the lighting; the sea materials) is extracted from the game's packs with RPFM. ### The order of runs The tw-modding tutorial on campaign maps gives this order; the details, which are the reference, are in [the BOB guide](https://bretonia.dev/atelier/en/bob/): 1. **The relief** first: the next steps depend on it and read it from your pack. Put it in your pack, in the game's `data` folder, then close and reopen BOB. 2. **The tile map**: into the pack again, then close and reopen BOB. 3. **The global tile map** (roads and cliffs). 4. **`global_props.bin`**, the placed objects: redo it whenever a region is added or removed (BOB then reads CAIME's `map.hex`); up to ten minutes on a large map, the tutorial says. *Diagram: Campaign: the order of runs.* In the diagram: Campaign: the order of runs · for a map the game's database knows · A map unknown to the game's database (the one in CA's packs): BOB only runs 6 actions out of 15, without a message. A control case, then the community. · The relief · the next steps read it from your pack · `full_height_map.dds` · `full_logic_map.compressed_map` · Relief into your pack, the pack into the game's data folder, then close and reopen BOB · The tile map · `tile_list.bin` · `tile_mask.dds` · `patch_mask.dds` · Tile map into your pack, then close and reopen BOB · The global tile map · roads and cliffs, taken from the tile map in your pack · `global_map/tile_list.bin` · The placed objects · BOB reads CAIME's map.hex, which must match the database; redo it for every region added or removed; up to ten minutes, the tutorial says · `global_props.bin` · Generate Camera Height Map: this action crashes BOB; camera_heightmap.png is made separately (the tutorial: approximated from the heightmap, scaled). The order from tw-modding's campaign map tutorial. BOB reads the packs in the game's data folder: after the relief, then after the tile map, the pack goes there, then you close and reopen BOB; from Terry, each Process with BOB starts a new BOB. From Terry, each *Process with BOB* starts a new BOB. After each run, read `bob_warnings.log`, in `assembly_kit/binaries/`, and count the "Failed to find tile": each one is a hole in the terrain. *Check* `bob.log` too: its first line states how many actions were selected (`N action(s) were selected for execution.`), and each finished action has its `(STATUS: Finished)` line; how many to expect: see the limits, below. Finally, look in `working_data/terrain/campaigns//`: the built relief (`full_height_map.dds`), `tile_list.bin` and `global_props.bin`. ### Known limits - **Six actions out of fifteen.** A full run on a campaign terrain has 15 actions (for us, about a minute once the relief is compressed, 25 minutes the first time). For a map that the game's database (the one in CA's packs) does not know, BOB runs only 6 of them, without a message; adding the map to the kit's database or to a mod pack changes nothing. We know of no official way to lift this limit: make a control case, then ask the community. A control case is a known-good project copied under another name: if it also stops at 6 actions, your project is not the cause. - "Generate Camera Height Map" crashes BOB (the tutorial reports this crash too). The camera height map (`camera_heightmap.png`) is approximated by the tutorial from the relief, scaled; the corruption mask is painted by hand or by script (by script, for us). - As long as no built terrain exists, Terry crashes when opening the project in 3D: untick *3D View* in the opening dialog (*Open…*). - **A campaign has two terrains**: its own, and a battle terrain declared by its campaign playable area (`terrain_folder` column, `terrain/battles//`). Without it, the game crashes at the first land battle, even between two AIs, so often at the very first end of turn. It is a battle tile map, which BOB builds as such; CA's also carries battle locations and catchment maps. *Diagram: One campaign, two terrains.* In the diagram: One campaign, two terrains · The campaign playable area · `campaign_map_playable_areas` · `terrain_folder = ` · The campaign terrain · `terrain/campaigns//` · the map's relief, tiles and placed objects · The battle terrain · `terrain/battles//` · a battle tile map; CA's also carries battle locations and catchment maps · Without that battle terrain: a crash at the first land battle, even between two AIs, so often at the very first end of turn. A campaign map has two terrains: its own, and a battle terrain, named by the terrain_folder column of its campaign playable area. The full story of a port, walls included: [the porting tutorial](https://bretonia.dev/blog/en/tutorial-porting-a-warhammer-1-map-to-warhammer-3.html). ## Terry's pitfalls First, the `working_data` lock, in four cases: *Diagram: Terry open: what works, what's blocked.* In the diagram: Terry open: what works, what's blocked · Terry is a mode of Tweak: Terry open means Tweak open · An open Terry locks working_data · including the packs placed there · Process with BOB (Ctrl+P), started from Terry · not affected: Terry starts BOB itself · BOB started from its own window · close Terry and the game first, then start BOB · Saving a pack into working_data · close Terry and the game first, then save · CAIME's Map Data and Dynamic Resources exports · Tweak and Terry closed. CAIME's warning looks for · Tweak.AssemblyKit, not tweak.modder.x64.exe: don't rely on it. · BOB rewrites its outputs on every run: don't touch anything up by hand in working_data. Terry is a mode of Tweak: when open, it locks working_data. Of the four cases, only Process with BOB, started from Terry, is not affected; for the others, close it first. - **An open Terry locks `working_data`**, including the packs placed there. Before running BOB from its own window, or saving a pack into `working_data`, close Terry and the game; *Process with BOB*, started from Terry, is not affected. - **Tweak and Terry closed during CAIME's exports**: during CAIME's *Map Data* and *Dynamic Resources* exports, Tweak **and Terry** must be closed (Terry is a mode of Tweak). Don't rely on CAIME's warning: it looks for a program named `Tweak.AssemblyKit`, whereas the Warhammer III kit's one is called `tweak.modder.x64.exe`. - **The preview is not the game**: every culture variant shows at once; decals are white spheres; campaign tree-map forests only show if the matching preview option is on (`show_campaign_tree_map`, in the *Settings*; off on our install), and only for tree families the kit's database knows; map-specific textures are ignored; water is rendered differently. All of that is judged in game. - **Create battle for tile…: once per map is enough.** What a second run would do to a folder you have edited is not documented: don't rerun it on a tile map you have changed. - **Without `.terry.user`, a campaign preview has neither water nor trees**: that small file, next to the `.terry`, holds the preview settings. - **CA's documentation dates from the first Warhammer.** Its *Export Map* has become **Process with BOB**, followed by RPFM; and the deployment zone colours have swapped (2016: 0 red, 1 blue; Warhammer III: 0 blue, 1 red): trust the *Alliance ID*, never the colour. - The *Defensive Hill* AI Hint must be a **closed polygon**, or a crash is likely. - **BOB rewrites its outputs on every run**: a manual touch-up in `working_data` disappears on the next run. - **Snow since 9.0**: the Immortal Empires snow material (`combi_campaign_snow.xml.material`) no longer cites a mask; the game binds the campaign's own `snow_mask.dds` by itself. Don't copy a snow material for each map. ## For an AI reading this page If you are an AI helping someone use Terry, here are the essentials, checked on a real project. These facts were gathered on the game's patch 8.1 (September 2026), then reviewed for update 9.0 (for us, the kit update rewrote the `raw_data\db` tables but touched neither the terrain nor `working_data`): check them again after an update. - Ask the human before launching the game, driving the screen or publishing; delete nothing: tidy away, only the human deletes. - No reverse engineering and no workaround of a CA tool: when a tool gets stuck, a control case, then the community (CAIME's Discord, tw-modding). - Terry is a mode of Tweak. Assembly Kit Steam launcher: *Battle Map Editor: Terry* = `tweak.modder.x64.exe /standalone TerrainMetadataEditor`, from `binaries` (window `TWeak - Terry`, about 25 s); *Exporter: BOB* = `bob.modder.x64.exe -no_console`; *Database Editor: Dave* (Dave, which CA spells DaVE). No command drives Terry; no guessed options. - BOB opens from the Assembly Kit's Steam launcher (*Exporter: BOB*), from its executable `bob.modder.x64.exe`, or from Terry (*Process with BOB*, Ctrl+P), which hands it the work. On the command line, its only known option is `-no_console`, the one the launcher passes. - Public kit: battle tiles only. Tile: `raw_data/terrain/tiles/battle///`; tile map: `raw_data/terrain/battles//`, created by Create battle for tile… (once is enough); BOB on the tile map, then on the tile. - `explicit_tiles`: the `x,y,path,0` line already exists (tutorial): change its x,y, in pixels of `tile_map.png`, x from the left, y from the top (the tile's top-left corner); path from `terrain/`, with forward slashes. 8 × 8 tile in the centre of a 64 × 64 tile map: 28,28, as in the kit's example map. - Alliance ID 0 = attacker, shown in blue in Warhammer III's Terry; 1 = defender, in red (CA's 2016 documentation says the opposite). Trust the number, never the colour. - `battles_tables`: copy a game row, Paste as New Row, change the key first; table file never named `data__`. `specification` = `terrain/battles//`; `battle_environment` = an `.environment_group` from `weather/battle/`; `screenshot_path` image in 3:1 format; text `battles_localised_name_`. - Terry's logs: `working_data/Terry/local/terry_error_log.txt`; autosaves in `working_data/Terry/local/autosave/` (every 15 minutes on our install, set in `settings.xml`). - Campaign: project to create in `raw_data/terrain/campaigns//` (`.terry` version 27, one entity per region). The `rules.bob` recipe is in the parent folder, `raw_data/terrain/campaigns/rules.bob`; the one in the map folder only copies (`[Copy]`, `[+AssetGraph]`). - Rasters: 8 px per hex (+ 4 rows), `HeightShroud` 4 (+ 2), trees, corruption, snow and `tile_map.png` 2 (+ 1). `PatchVisibilityMask`: one cell per patch of p tile-map pixels, p = ceiling(longest side / 128), i.e. (width // p) × (height // p) cells. - Sea declared in `tile_map.png` (`sea`, 83, 141, 213), floor below 0 everywhere; coast as a one-hex band; roads as 2 × 2 pixel blocks (conventions established on our project and ChaosRobie's). - Order of campaign runs: the relief, put it in the pack (in the game's `data`), close and reopen BOB; the tile map, into the pack, close and reopen BOB; the global tile map; `global_props.bin`, to redo whenever a region is added or removed (it reads the `map.hex`). The tutorial says *restart*: you close BOB and reopen it, you don't just "rerun" it. - A full run on a campaign terrain has 15 actions. For a map that the game's database (the one in CA's packs) does not know, BOB runs only 6, without a message; adding the map to the kit's database or to a mod pack changes nothing. No known official way: a control case, then the community. Never promise 15 actions for a new map. - Before running BOB from its own window, or saving a pack into `working_data`, close Terry and the game; Tweak and Terry closed during CAIME's *Map Data* and *Dynamic Resources* exports. Read `binaries/bob.log` and `binaries/bob_warnings.log`. Judge in game, not in the preview. - Details: [BOB](https://bretonia.dev/atelier/en/bob/), [RPFM](https://bretonia.dev/atelier/en/rpfm/), [CAIME](https://bretonia.dev/atelier/en/caime/), [the modder's tools](https://bretonia.dev/atelier/en/tools/), [modding with an AI](https://bretonia.dev/atelier/en/ai/). ## Sources and links - Creative Assembly wiki, pages written for the first Total War: WARHAMMER's kit (some labels have changed since): [Terry introduction](https://wiki.totalwar.com/w/TWW_Assembly_Kit_Terry_Intro), [Terry contents](https://wiki.totalwar.com/w/Total_War_WARHAMMER_Assembly_Kit_Terry), [interface](https://wiki.totalwar.com/w/TWW_Assembly_Kit_Terry_Interface.html), [shortcuts](https://wiki.totalwar.com/w/TWW_Assembly_Kit_Terry_Keys.html), [quick start](https://wiki.totalwar.com/w/TWW_Assembly_Kit_Terry_Quick_Start_Guide.html), including [zones](https://wiki.totalwar.com/w/TWWAKT_Creating_Zones.html), [navigating the viewport](https://wiki.totalwar.com/w/TWWAKT_Navigating_the_Viewport.html), [painting](https://wiki.totalwar.com/w/TWWAKT_Painting.html) and [saving](https://wiki.totalwar.com/w/TWWAKT_Saving.html), and [Rules.bob](https://wiki.totalwar.com/w/Rules.bob_Documentation.html). - tw-modding wiki: [Map Making for WH3](https://tw-modding.com/wiki/Tutorial:Map_Making_for_WH3) (WakaWaka300), [Campaign Map Making for Warhammer III](https://tw-modding.com/wiki/Tutorial:Campaign_Map_Making_for_Warhammer_III), [Custom Campaign Settlement Skins](https://tw-modding.com/wiki/Tutorial:Custom_Campaign_Settlement_Skins) (Warhammer III part, ChaosRobie), [RPFM For Dummies](https://tw-modding.com/wiki/Tutorial:RPFM_For_Dummies), and, for Warhammer II, [Land Battle Maps](https://tw-modding.com/wiki/Battle_Maps:Land_Battle_Maps) and [Custom Vistas](https://tw-modding.com/wiki/Battle_Maps:Custom_Vistas). - The Warhammer III Assembly Kit's files, read only: Terry's settings and shortcuts (`settings.xml`, `keyboard.xml`, `status_tooltips.xml`, `entity_configuration.xml`), the kit's `rules.bob` files, the example map, the `battles` table (`battles.xml`). - The *Immortal Empires Expanded* campaign Terry project, shared by ChaosRobie, and our own project. - Our other guides: [BOB](https://bretonia.dev/atelier/en/bob/), [RPFM](https://bretonia.dev/atelier/en/rpfm/), [CAIME](https://bretonia.dev/atelier/en/caime/), [the modder's tools](https://bretonia.dev/atelier/en/tools/), [modding with an AI](https://bretonia.dev/atelier/en/ai/); and [the modders' workshop](https://bretonia.dev/atelier/en/). ## Frequently asked questions ### Can Terry edit a campaign map? It can open a campaign-type project, but the public kit ships none, nor any campaign terrain data: you have to rebuild one, on the model of the project ChaosRobie shared for Immortal Empires Expanded. ### How do I open Terry? From the Assembly Kit launcher in Steam (Play Battle Map Editor: Terry, which runs the command below), from Tweak (Plugins → Terry), or with the command `tweak.modder.x64.exe /standalone TerrainMetadataEditor`, run from the kit's `binaries` folder. Don't try any other option. ### Can Terry be driven from the command line? No: you can only open it. Everything else happens in its window, with keyboard and mouse; BOB is started from Terry with File → Process with BOB. ### Alliance ID 0 or 1: who attacks? 0 is the attacker, 1 the defender. In Warhammer III's Terry, 0 shows in blue and 1 in red; CA's 2016 documentation had it the other way round. Trust the number, never the colour. ### Why doesn't my map show up in custom battle? Check that the pack is in the game's `data` folder and enabled in the launcher, that it holds the built files of both the tile map and the tile, that the `specification` in `battles_tables` points to the tile map's folder (`terrain/battles//` with the trailing slash, as in the tutorial; if you copied a CA row, keep its form), and that the `battles_localised_name_` text and the image exist. ### Why doesn't Terry show my map the way the game does? Its preview is not the game: every culture variant at once, white spheres instead of decals, no map-specific textures, water rendered differently. Campaign tree-map forests only show if the `show_campaign_tree_map` option is on in the Settings, and only for tree families the kit's database knows. Fidelity is judged in game. ### Why does BOB only build part of my new campaign map's terrain? A full run on a campaign terrain has 15 actions (for us, about a minute once the relief is compressed, 25 minutes the first time). For a map that the game's database (the one in CA's packs) does not know, BOB runs only 6 of them, without a message; adding the map to the kit's database or to a mod pack changes nothing. We know of no official way to lift this limit: make a control case, then ask the community. ### Terry crashes when opening my campaign project: what can I do? As long as no built terrain exists for that map, Terry crashes when opening it in 3D: untick 3D View in the opening dialog (Open…). ### Must I close Terry before running BOB? Before running BOB from its own window, or saving a pack into `working_data`, close Terry and the game: an open Terry locks `working_data`. Process with BOB, started from Terry, is not affected. ### Terry crashed: where should I look? In the kit's `working_data/Terry/local` folder: `terry_error_log.txt`, where Terry logs its errors, and the `autosave` folder, where it keeps its autosaves (every 15 minutes on our install; the delay is set in the Settings). Save often: CA warns that Terry sometimes crashes. ### My tile doesn't show in the tile map: what should I check? The `explicit_tiles` line: x,y in pixels of `tile_map.png`, x from the left, y from the top, at the top-left corner of the vista's black square; a path starting from `terrain/`, with forward slashes, to the tile's folder; the final 0. Then run Process with BOB on the tile map and reload it in Terry, as the tutorial says. Finally, read `bob_warnings.log`, in the kit's `binaries` folder. ### The armies deploy in the wrong place: why? Check the Alliance ID of both deployment zones: 0 for the attacker, 1 for the defender, whatever their colour. Each zone has its additive Deployment Zone Region, Zone ID at 0. Then redo the BOB run on the tile and put its files back into the pack. ### Where can I find a vista? The Warhammer III kit ships none. The tw-modding tutorial for Warhammer III provides some, taken from Warhammer II; the same wiki's Custom Vistas page, written for Warhammer II, explains how to make one from those in the Warhammer II kit (`raw_data/terrain/vistas`). From a vista you take `tile_map.png` and `climate_map.png`, which you place in your tile map's folder.