BOB, the guide: building terrain and packs with the Total War: Warhammer III Assembly Kit

What BOB does§

BOB is the builder of the Assembly Kit, Creative Assembly's official kit (Steam → Library → Tools). It is not for drawing: it transforms. It takes the sources stored in raw_data (the database tables, Terry's terrain projects) and derives the game's files from them, which it writes to working_data; it can also gather them into packs. The tw-modding wiki's Beginner's Guide expands its name as Build-on One Button.

Why this compulsory step? Because the game does not read working formats. A relief painted in Terry is a .tif image; the game wants compiled maps (.compressed_map, .dds, .bin). A table edited in Dave, the kit's database editor (CA writes it DaVE; the Steam launcher says Database Editor: Dave), is an XML file; the game wants its tables in its own format. BOB does the translation.

The diagram below follows a battle map from source to game: the Terry project (the tile map and the tile) in raw_data, BOB and its rules.bob files, the game's files in working_data, then the two routes to a pack: RPFM, the proven one, or a BOB rule, which we have not proven in Warhammer III.

BOB lives in the kit's binaries folder: bob.modder.x64.exe. It opens from the Steam launcher, from its executable or from Terry: see “Opening BOB and giving it work” below. It is made of modules, one per trade; the Warhammer III kit ships, among others, bob_terrain, bob_tile, bob_vegetation, bob_texture, bob_campaign, bob_dbexport, bob_localisation, bob_lua, bob_pack and bob_files.

What BOB does not do: the logical half of a campaign map (regions, roads, pathfinding). That is the job of CAIME (Campaign AI Map Editor), the Campaign Map Toolkit's editor: see the CAIME guide.

Vocabulary§

BOB's window§

Opened from the Steam launcher (Exporter: BOB) or from its executable, BOB displays a window titled BOB - Select Data Files To Build. It shows Raw Data (the sources) and Working Data (what is already built); a third tree, Retail Data, shows the kit's retail folder (with assembly_kit and data in it). The Rome II kit already had a retail tree.

A right-click on a node opens a menu of three entries: View rules, View actions and Select files only. View actions opens a small “BOB” window: the node's two lists of actions, described below. We recorded this window and this menu on screen on 24.09.2026, in Assembly Kit 1.3.4908.

1. Tick a node. Its actions show up in two lists: Provider actions and Consumer actions, each with a Merge Actions box. For the database node, the first one is empty.
2. Pick an action, or <All>, at the top of Consumer actions, to take them all. With <All>, BOB adds by itself what they depend on (for example the Database Export node).
3. Repeat for each node to process.
4. Click Start, bottom right. Each action turns green when it is done.

How to check it worked. Every chosen action is green. Then read bob.log: see “BOB's logs” below.

Why so many precautions? Because BOB does not always report what it did not do. A run can end without an error and without producing the file you expected. Hence this guide's rule: after every run, check.

rules.bob files: BOB's recipes§

BOB does not decide on its own what to do with a file. It follows rules, written in text files called rules.bob and placed in raw_data and working_data folders. A rule says, for example, where to look for a terrain's prefabs, or which pack a folder goes into.

The syntax§

• Each [Section] stands for a processor; below it, one line per setting: Key = value.
• The <Files> key filters the files concerned: comma-separated lists, exclusion with a leading -, and the wildcard *, which matches any character but /: it does not cross folders.
• Three dots, ..., match any character, / included: ...*.terry therefore also reaches the .terry files in subfolders (CA's Attila BoB page). The kit's [Tile] and [Prefab] rules use it.
• Sections in the rules.bob files CA ships: [Pack], [Terrain], [Tile], [Prefab], [Copy] and [+AssetGraph]. ChaosRobie's campaign rules.bob (raw_data/terrain/campaigns/rules.bob, the maps' parent folder) adds [Prop], [Entity], [Mesh] and [Texture].
• [Copy] and [+AssetGraph] seem to serve CA for shipping the example map: they copy the raw data into the kit's retail folder (IncludeInRetail = true). A mod does not need them.
• Don't invent sections or keys: stick to those shown by the kit and CA's documentation.

How BOB finds a file's rule§

1. BOB looks for a rules.bob in the folder of the file it is processing, and checks whether one of its rules targets that file, filters included.
2. If not, it climbs up one folder, and tries again.
3. The first rule that applies wins. If it reaches the top without finding one, it uses its defaults.

A local rule can replace the one above, or only complete it. It all comes down to one sign:

The diagram below follows three files in working_data: each climbs the folder tree up to the first rules.bob that applies, and that rule decides which pack it goes into.

How to check a rule applies. After the run, check that the effect the rule announces took place (for example, the pack the files went into). If not, a rule closer to the file may have won: look for it by climbing its folders.

Three rules.bob files from the kit, line by line§

Nothing beats real rules. The first and third files ship with CA's kit; the second follows the model of the kit's example map, with compression added. Each block can be copied as is; the numbered notes below explain it line by line.

First file: working_data/rules.bob§

[Pack]
    <Files> = -*.pack
    PackFile = <retail>/data/mod.pack
    PackType = mod

1. <Files> = -*.pack: every file except packs; the - sign excludes.
2. PackFile: the pack to build. For the word <retail>, see below.
3. PackType = mod: the only value CA's documentation shows.
4. Sitting at the top of working_data, this rule applies to any file that finds no [Pack] closer to it. CA sums it up this way: everything except packs goes into mod.pack.

Second file: a separate pack for a battle map§

To be placed in the tile map's folder, working_data/terrain/battles/my_map/, and in the tile's folder (see the box):

[Pack]
    BasePath = /
    PackFile = <retail>/data/my_map.pack
    PackType = mod
    Compressed = true
    CompressionType = LZ4

1. BasePath = /: according to CA's Rules.bob page, you add it when the rule sits in a subfolder, to send that folder's content to another pack. The example map writes it this way.
2. PackFile: the map's pack. This [Pack] is closer to the tile map's files than the top one: they go into my_map.pack, no longer into mod.pack.
3. PackType = mod: as in the first file.
4. Compressed and CompressionType: optional. Compression is LZ4 or ZSTD. The kit's documentation (documentation/pack/pack/compression.txt) advises against it for sounds and videos, and urges caution for models (LZ4 if it is really needed).

That last rules.bob, the one in _tile_database/TILES/, points to assembly_kit_example.pack: if your tile also has an entry in that folder, check in RPFM which pack it went into.

Third file: raw_data/terrain/battles/rules.bob§

[Terrain]
    PrefabRoot = art/prefabs/battle
    save_meta_data_map = false
    save_final_tile_map = true

1. This is a processing rule, not a pack rule: it says where to look for battle prefabs (PrefabRoot), and which maps to write (the two save_… keys).
2. PrefabRoot = art/prefabs/battle is for a battle. For a campaign terrain, ChaosRobie's project writes art\prefabs\campaign: that is this project's value; follow the one you are building on.
3. save_meta_data_map and save_final_tile_map: keep them as CA gives them.

The word <retail>: what we know, and what we don't§

Pack rules write PackFile = <retail>/data/…. It is tempting to read it as “the game folder”. That is not what we observed:

• On our installation, a [Copy] rule aimed at <retail>/assembly_kit/… wrote into assembly_kit/retail/assembly_kit/…: into a retail folder inside the kit.
• The Rome II Assembly Kit guide likewise finds the finished pack in assembly_kit/retail/data.
• BOB's window also has a Retail Data tree, which shows that retail folder of the kit (with assembly_kit and data in it; recorded on 24.09.2026).

A pack built by BOB would therefore land in assembly_kit/retail/data/, not in the game's data folder. We have not checked this in Warhammer III for a pack: it is a deduction, and the [Pack] route itself is unproven there. After a run, look for the pack in both places (its modification date gives it away), and copy it by hand into the game's data/ folder if it is not there.

Opening BOB and giving it work§

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, the only option known for it is -no_console, the one the launcher passes.

Opened from Steam or from its executable, BOB shows its window and waits for you to pick its work. Opened by Terry, it works in the background, and its messages appear at the bottom right of Terry. The command line only opens it: the work is chosen in the window, or in Terry.

From Terry§

• In Terry: File → Process with BOB (Ctrl+P), or the globe button with an arrow pointing right (Basic toolbar). It is the tutorials' route for terrain.
• Terry writes what it asks for (processors, folders, wanted outputs) into a configuration file, then launches BOB in the background; the messages appear at the bottom right of Terry. Each Process with BOB starts a new BOB.
• What it offers to build depends on the project type (tile, battle tile map, campaign tile map); BOB's options are in Terry's Settings.
• No need to close Terry: it launches BOB itself. Save first: CA advises saving often, as Terry sometimes crashes.
• CA's wiki pages written for the 2016 kit talk about Export Map: in Warhammer III it is Process with BOB, then the pack (RPFM, or a [Pack] rule, unproven in Warhammer III).

How to check it worked. Follow the messages to the end, then read bob.log in binaries: the number of actions announced on the first line, as many (STATUS: Finished) lines, and Exit code: 0 at the end.

From BOB's window§

Tick the node, pick the action or <All>, then Start. Three typical uses:

Before running BOB from its window, or saving a pack into working_data, close Terry and the game: an open Terry locks working_data. Process with BOB, run from Terry, is not affected.

How to check it worked. The actions are green, bob.log ends with Exit code: 0, and the expected files have appeared with the run's date.

The command line§

BOB has no built-in help, and the only option known for it is -no_console, the one the Steam launcher passes. The kit's launcher offers three options:

For repetitive work, prepare the rules.bob files and the data by script, then start the run with one click on Start, or from Terry.

What BOB produces§

For terrain, a BOB output keeps its source's path, under working_data instead of raw_data. A battle tile map stored in raw_data/terrain/battles/my_map/ therefore comes out in working_data/terrain/battles/my_map/. That is how you find what a run wrote.

Example: the example battle map shipped with the kit (assembly_kit_example_tile_map and its tile assembly_kit_example_tile) gives:

For a campaign, outputs go to working_data/terrain/campaigns/<map>/ and working_data/campaign_maps/<map>/.

Three exceptions to the same-path rule:

• The database export writes one folder per table, working_data/db/<table>_tables/, with a data file inside; and also, for each campaign, starting-position tables (start_pos_…) in raw_data/EmpireDesignData/campaigns/<campaign>/, so into raw_data.
• A [Copy] rule writes under <retail>: for us, into the kit's assembly_kit/retail/… folder.
• A [Pack] rule writes its pack under <retail>/data/: see “The word <retail>” above.

Two practical consequences:

• BOB rewrites its outputs on every run. A hand edit in working_data (a texture list, a lighting collection…) disappears on the next run. Fix the source, or make the edit with a script you rerun after every run.
• An open Terry locks working_data. Before running BOB from its window, or saving a pack into working_data, close Terry and the game; Process with BOB, run from Terry, is not affected.

How to check an output is new. Look at its modification date: it must be the run's. An older file comes from a previous run, and your change was not built.

BOB's logs§

BOB writes its logs to the kit's binaries folder, next to its executable. They only keep the last run: each run wipes the previous one. To compare two runs, copy the logs elsewhere before the next run.

Reading a run in three minutes§

1. Open bob.log. The first line says how many actions were selected; the last one must say Exit code: 0.
2. Count the (STATUS: Finished) lines: one per action done. Compare with the number on the first line, and with what you expected. An incomplete run shows up here, even without an error.
3. Open bob_warnings.log and count the “Failed to find tile”: each one is a hole in the terrain.
4. At the slightest doubt, open the other logs in the same folder.

So Exit code: 0 is not enough on its own: count the actions too.

Messages to know§

Four messages come up often. The “Where” column says which log to look in:

For a campaign map, a “Failed to find tile” comes from the pattern painted in tile_map.png: the diagram below, taken from the Terry guide, shows what BOB accepts.

And no message is a message too: for a campaign map the game's database does not know, BOB runs only 6 actions out of 15, without a word. See “BOB and a campaign map” below.

Step by step: three typical jobs§

Building a battle map§

Painting, zones and creating the tile map are in the Terry guide. Here is BOB's part:

1. Save, then open the tile map (the project in raw_data/terrain/battles/<map>/) and run File → Process with BOB. Reload it afterwards to check.
2. Reopen the tile. In Map Properties, untick legacy vegetation generation, then Process with BOB.
3. Remember the order: the tile map always comes before the tile. After that, when you touch up the tile, only the tile needs re-exporting.
4. Pack it with RPFM, the proven route: working_data/terrain (without the kit's example map), a row in battles_tables whose specification is terrain/battles/<map>/ (trailing slash included), a text and an image: see the Terry guide.
5. Put the pack in the game's data/ folder with a square thumbnail of the same name, enable it in the launcher, and test through Custom Battle.

How to check it worked. After every run, since the logs only keep the last one:

• bob.log ends with Exit code: 0, holds as many (STATUS: Finished) lines as its first line announces actions, and its actions concern the project you just processed;
• bob_warnings.log holds no “Failed to find tile”;
• after the tile map run, working_data/terrain/battles/<map>/ holds tile_map.bmd, tile_list.bin, lf_normal.dds, full_lf_logic_map.compressed_map and map_info.xml, dated from the run;
• in game, the map appears in Custom Battle, and the terrain has no holes.

Exporting the kit's database§

Why: your tables edited in Dave are XML files in raw_data/db; the export writes them in the game's format, one folder per table in working_data/db/. This is useful when a tool wants the database in the game's format (for us, for the startpos). For a mod, it is not what you pack: see the box below.

1. Close Terry and the game.
2. Open BOB from the Steam launcher (Exporter: BOB) or from its executable (bob.modder.x64.exe, in binaries).
3. Tick the database node and pick <All>: BOB adds the dependencies by itself, such as the Database Export node.
4. Click Start, and wait until everything is green. For us: 3,788 actions in 109 seconds.

How to check it worked. bob.log ends with Exit code: 0, and working_data/db/ holds one folder per table, with its data file, dated from the run (1,694 for us). The export also writes, for each campaign, starting-position tables (start_pos_…) in raw_data/EmpireDesignData/campaigns/<campaign>/: don't be surprised to find them there.

Building a pack§

Two routes lead to a pack, and the diagram at the start of this guide shows them side by side:

• RPFM, the proven route. You create the pack and add the wanted working_data folder to it. It is the route of the tw-modding wiki's battle map tutorial (the RPFM guide).
• BOB's [Pack] rule, unproven in Warhammer III. A rules.bob with [Pack] (see the examples above) tells BOB which working_data files to gather, and into which pack; a battle map needs it in both its folders. We don't know which node to tick for BOB to build that pack in Warhammer III (in the Rome II kit, you ticked mod.pack in the retail tree; Warhammer III's, Retail Data, shows assembly_kit and data, and we have run nothing from it), and <retail> may make it land in the kit's retail folder.

How to check it worked. BOB cannot reopen a pack: open it in RPFM. It must hold your files under the path the game expects (for a battle map, terrain/battles/<map>/, the one battles_tables cites), and nothing else: neither the kit's example map nor another .pack. Finally, check that it is in the game's data/ folder.

BOB and a campaign map§

CA's documentation warns that the public kit only supports creating battle tiles, and the Warhammer III kit ships no raw campaign terrain data. The community has nonetheless rebuilt a campaign-type Terry project (ChaosRobie, for Immortal Empires Expanded), and BOB has a campaign module, bob_campaign. The project is described in the Terry guide, the map's logical half in the CAIME guide.

The order of runs§

The tw-modding wiki's campaign map tutorial gives this order, for a map the game's database knows (for a new map, see “The limit” below). BOB looks for the first steps' results in your pack, and it reads the packs in the game's data folder: hence the back and forth.

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), which BOB derives from the tile map in your pack.
4. global_props.bin, the placed objects: redo it whenever a region is added or removed (BOB then reads CAIME's map.hex, which must match the database); up to ten minutes, the tutorial says. ChaosRobie's project indeed stores its objects by region, in one .layer each.

From Terry, each Process with BOB starts a new BOB.

How to check it worked. In bob.log, compare the number of actions on the first line with the (STATUS: Finished) lines. A complete run on a campaign terrain counts 15 actions; for a map the game's database does not know, BOB only runs 6 (see below). Then count the “Failed to find tile” in bob_warnings.log, as for a battle.

Three things to know before building§

• Terry needs already-built terrain to open a campaign project in 3D: without it, it crashes on opening. As long as nothing is built, open the project with 3D View unticked in Open…
• The Generate Camera Height Map action crashes BOB (the tutorial reports it too). camera_heightmap.png and the corruption mask are made separately.
• A campaign also needs a battle terrain: the terrain/battles/<folder>/ folder named by the terrain_folder column of its campaign playable area. 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.

The limit: a map the game's database does not know§

A complete run on a campaign terrain counts 15 actions (for us, about a minute once the relief is compressed, 25 minutes the first time). For a map the game's database (the one in CA's packs) does not know, BOB only runs 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: run a control case, then ask the community.

The 6 actions are the Terry file and five masks: no relief, no textures, no logic map, no shroud. And no message reports it: no error, no warning.

The control case, before searching your own files: take a project known to be good, copy it under another name, and do a run on it. If it also gets only 6 actions, your project is not to blame.

If you hit this limit, bring it to the community (the CAIME team's Discord, the tw-modding wiki) rather than trying to force the tool.

BOB's pitfalls§

• Guessed options (-h, --help): an “Illegal option format” box blocks BOB and the script waiting for it. Don't try it on Terry or Tweak either.
• A node ticked, then a click elsewhere: selection cancelled, without a message.
• A single action may produce nothing (Build Queried Campaign Tables): take <All>.
• Terry or the game open during a run started from BOB's window: Terry locks working_data.
• A local [Terrain] replaces the parent's: copy PrefabRoot over, or write [+Terrain].
• A wildcard * does not cross folders: to reach subfolders too, start the filter with ....
• A battle map split in two: the tile, without the tile map's [Pack] rule, goes into mod.pack.
• An exported table carries all its rows: bad for compatibility between mods.
• A hand edit in working_data vanishes: BOB rewrites its outputs.
• A pack built by BOB is checked in RPFM: BOB cannot reopen it.
• <retail> is not necessarily the game folder: look in assembly_kit/retail/data/ too.
• Overwritten logs: they only keep the last run.
• BOB kept open between two campaign steps: after putting the relief, then the tile map, into the pack, close and reopen BOB.
• A campaign map unknown to the game's database: 6 actions out of 15, without a message.
• After a game update: Steam updates the Assembly Kit after the game (for us, an hour later, with 9.0) and rewrites raw_data\db, where BOB takes the database from; the rows you had added there disappear. Check and restore them before running BOB again. 9.0 also replaced part of BOB itself (its terrain module): what worked on patch 8.1 is checked again with a control run before the first long build.
• A window you cannot find: BOB once opened tiny, at the bottom of the screen. Select its window with Alt+Tab, then enlarge it with Windows + Up arrow.

For an AI reading this page§

If you are an AI helping someone use BOB, here are the essentials, as checked facts. They were gathered on the game's patch 8.1 (September 2026), then reviewed for update 9.0, which replaced part of BOB (its terrain module) and rewrote raw_data\db: check them again after an update.

• Executable: binaries/bob.modder.x64.exe in the Warhammer III Assembly Kit. The kit's Steam launcher offers Exporter: BOB (bob.modder.x64.exe -no_console), Battle Map Editor: Terry (tweak.modder.x64.exe /standalone TerrainMetadataEditor) and Database Editor: Dave (no option). The only option known for BOB is -no_console, and it has no help: -h and --help open an “Illegal option format” box that blocks the process; don't try it on Terry or Tweak either.
• Driving it: the window (tick a node, pick an action or <All>, Start) or Terry (File → Process with BOB, Ctrl+P; a new BOB every time). For a battle map, BOB's window is not needed: Terry starts the runs, RPFM makes the pack. Prepare everything else outside the window (rules.bob, tables, images).
• The window, recorded on screen on 24.09.2026 in Assembly Kit 1.3.4908: three trees, Raw Data, Working Data and Retail Data (the kit's retail folder); right-click on a node: View rules, View actions, Select files only; a node's actions in two lists, Provider actions and Consumer actions, each with a Merge Actions box; <All> is at the top of Consumer actions, and Provider actions is empty for database.
• rules.bob: sections = processors, Key = value lines, <Files> filter (commas, exclusion with -); the wildcard * does not cross folders, ... does. Lookup: the file's folder, then upwards; the first rule that applies wins; [Name] replaces, [+Name] completes. CA's sections: [Pack], [Terrain], [Tile], [Prefab], [Copy], [+AssetGraph]; ChaosRobie's campaign file adds [Prop], [Entity], [Mesh], [Texture].
• A battle map spans two working_data folders, the tile map and the tile: the same [Pack] rule must sit in each, or the tile goes into mod.pack.
• Packs: the proven route is RPFM. BOB's [Pack] route is unproven in Warhammer III (node to tick unknown; <retail> observed: assembly_kit/retail/…). Check where the pack appeared, then open it in RPFM.
• Outputs: for terrain, same path as the source, under working_data. Exceptions: the database export writes working_data/db/<table>_tables/data, and also per-campaign starting-position tables in raw_data/EmpireDesignData/campaigns/; [Copy] and [Pack] write under <retail>.
• Logs: binaries/bob.log and its neighbours, last run only. First line of bob.log: N action(s) were selected for execution., to compare with the (STATUS: Finished) lines; last line: Exit code: 0. “Failed to find tile” and “Failed to find valid quadtree node” are in bob_warnings.log; “Couldn't create all processors…” in bob_plugin_error.log, harmless. Success: Exit code: 0 and the right number of actions and zero “Failed to find tile”.
• Before running BOB from its window, or saving a pack into working_data, close Terry and the game; Process with BOB, run from Terry, is not affected.
• Campaign: BOB reads the packs in the game's data folder. Order: the relief, put into the pack, then close and reopen BOB; the tile map, into the pack, then close and reopen BOB; the global tile map; global_props.bin (reads CAIME's map.hex, redo it for every region added or removed, up to ten minutes). Generate Camera Height Map crashes BOB.
• Limit: for a map the game's database (the one in CA's packs) does not know, BOB only runs 6 actions out of 15, without a message; adding the map to the kit's database or to a mod pack changes nothing. No known official way to lift it: a control case, then the community.
• Startpos: three routes, RPFM's Build Startpos, BOB's Process start pos action, or a hand-written user.script.txt; for us, only the hand-written route worked (the tools guide).
• CA pages from 2016: their Export Map has become Process with BOB, then a pack.
• Ask the human before launching the game, driving the screen or publishing; delete nothing: tidy away, only the human deletes.
• Neither reverse engineering nor working around a CA tool: when a tool stalls, a control case, then the community (CAIME's Discord, tw-modding).
• See also: the Terry guide, the RPFM guide, the modder's tools, modding with an AI.

Sources and links§

• Creative Assembly wiki: Rules.bob, BoB (Attila) and Terry introduction. The “TWW” pages date from the Total War: WARHAMMER kit (2016): some labels have changed since.
• tw-modding wiki: Map Making for WH3 (WakaWaka300), Campaign Map Making for Warhammer III, Custom Campaign Settlement Skins (ChaosRobie's Warhammer III part: Process with BOB from Terry, its messages), Beginner's Guide and Localisation.
• Heaven Games: the Rome II Assembly Kit guide (2014), for the window and packs.
• The Warhammer III kit itself, read without changing anything: its rules.bob files, the example map, documentation/pack/pack/compression.txt, the logs in binaries and the three options of its Steam launcher. BOB's window (its three trees, the right-click menu, the actions window) was recorded on screen on 24.09.2026 in Assembly Kit 1.3.4908, without running anything.
• Our other guides: Terry, RPFM, CAIME, the modder's tools and modding with an AI; and the workshop.

Frequently asked questions