# BOB, the guide: building terrain and packs with the Total War: Warhammer III Assembly Kit > BOB is the Assembly Kit's builder: it turns what you prepared in Terry and in the kit's database into files Total War: Warhammer III can read. This guide explains its window, its recipes (the rules.bob files), how to launch it, where to read what it did, and the pitfalls that cost us hours while porting a campaign map from Warhammer I to Warhammer III. Page: https://bretonia.dev/atelier/en/bob/ · 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 BOB does > **In short**: For a battle map, you don't open BOB's window: Terry launches it (Ctrl+P), RPFM makes the pack. The window is mostly for exporting the database. After every run: `bob.log` (`Exit code: 0` and the right number of actions), then `bob_warnings.log`. 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](https://tw-modding.com/wiki/Tutorial:Beginner%27s_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. *Diagram: From source to game, through BOB.* In the diagram: raw_data · your Terry project · Terry · `terrain/battles//terrain/tiles/battle///` · the tile map (the frame), then the tile (what you paint) · `Process with BOB (Ctrl+P)` · the tile map, then the tile · BOB · reads the rules.bob files · logs: binaries/bob*.log · working_data · `tile_map.bmd · tile_list.bin · blend0.dds …` · the game's files, under the same paths as in raw_data; padlock: an open Terry locks working_data, except for the BOB it starts itself · `[Pack] rule` · ? · [Pack] rule · unproven in Warhammer III · probably in the kit: `retail/data/` · copy by hand · `add the` · `folder` · RPFM · the proven route · `working_data/terrain/` · without the example map · `battles_tables` · your row, text, image · The game · `data/ → launcher` · `→ custom battle` A battle map from source to game: Terry has BOB process the tile map, then the tile; BOB follows the rules.bob files and writes the game's files under the same paths, in working_data. The pack is made with RPFM, the proven route; a BOB [Pack] rule would probably put it in the kit's retail folder, a route 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](https://bretonia.dev/atelier/en/caime/). ### Vocabulary | Word | Meaning | |---|---| | `raw_data` | the sources: what the kit's tools read (database XML tables, Terry projects, images) | | `working_data` | what BOB produces: files in the game's format, mostly stored under the same path as their source (see "What BOB produces") | | Kit database | the XML tables in `raw_data/db`, edited with Dave | | Game database | the one in CA's packs; for a campaign map, it is the one that counts (see "BOB and a campaign map") | | Node | a folder or file in one of the trees of BOB's window | | Action | a job BOB can do on a node; each node offers several | | Processor | the part of BOB that does one kind of job; `bob.log` names it in front of each action | | Run | one execution of BOB, from launch to exit code | | Rule | a section of a `rules.bob`, with its `Key = value` settings; each section sets up one processor | | `rules.bob` | a text file of rules placed in a folder; it applies to that folder and those below, unless a closer rule takes over | | Pack | the `.pack` archive the game reads; a mod is one | | `` | a reserved word in `rules.bob` files that stands for a destination folder; see below what we know about it | | Log | BOB's `.log` files, in `binaries`, rewritten on every run | ## 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. *Diagram: BOB's window and its nine markers.* 1. **The title**: BOB - Select Data Files To Build: the window BOB shows when opened from the Assembly Kit's Steam launcher (Exporter: BOB) or from its executable, bob.modder.x64.exe. 2. **Raw Data**: the tree of sources, those in raw_data; a node is a folder or a file. 3. **Working Data**: the tree of what is already built, in working_data. 4. **Retail Data**: a third tree, which shows the kit's retail folder (with assembly_kit and data in it). 5. **The actions window**: a small "BOB" window, opened by ticking a node (here database); a right-click on a node offers View rules, View actions and Select files only, and View actions opens it too. Two lists, Provider actions (empty for database) and Consumer actions, each with a Merge Actions box. 6. ****: at the top of Consumer actions: all the actions; BOB adds by itself what they depend on (the Database Export node). A single action may produce nothing: Build Queried Campaign Tables alone gives 0 files. 7. **The trap**: tick a node, then click elsewhere without picking an action: it unticks, without any message, and Start will do nothing for it. 8. **Start**: bottom right; each action turns green once it is done. Database export, for us: 3,788 actions in 109 s. 9. **bob.log**: then, in binaries: the number of actions on the first line, as many STATUS: Finished lines, then Exit code: 0. Schematic: the trees and the actions window as seen on 24.09.2026 in Assembly Kit 1.3.4908, laid out schematically. To export the database: tick database, which opens the actions window (5), pick at the top of Consumer actions (6), Start (8), then read bob.log (9). For a battle map you don't open this window: Terry launches BOB itself (Process with BOB, Ctrl+P). 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 ``, at the top of *Consumer actions*, to take them all. With ``, 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. > **Ticking is not enough**: A node only stays ticked if one of its actions is. If you tick a node and then click elsewhere without picking an action, the selection is cancelled **without any message**, and Start will do nothing for that node. Another trap: a single action may produce nothing. To export a campaign's tables, *Build Queried Campaign Tables* alone gives zero files; `` solves the problem. 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 `` 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: | Written as | Effect | |---|---| | `[Name]` | replaces the inherited rule **entirely**: a key you don't copy over is gone | | `[+Name]` | keeps the inherited rule and only changes the keys listed | 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. *Diagram: How BOB picks its rule.* In the diagram: Each file climbs to the first rules.bob · `working_data/` · `rules.bob` · `[Pack] = -*.pack` · `PackFile = /data/mod.pack` · `db/land_units_tables/` · `data` · `mod.pack` · (CA's default; an exported table is not published as is) · `terrain/` · `battles/my_map/` · `rules.bob` · `[Pack] BasePath = /PackFile = /data/my_map.pack` · `tile_map.bmd` · `my_map.pack` · `tiles/battle///` · `rules.bob` · `the same rule, to my_map.pack` · `blend0.dds` · `my_map.pack` · [Pack] replaces the inherited rule; [+Pack] only changes the keys it names. · -*.pack excludes; * matches any character but /, so it does not cross folders; ... does. BOB looks for a rules.bob in the file's folder, then climbs folder by folder: the first rule that applies wins. Here, a table goes into mod.pack; the tile map and the tile, which carry the same rule, go together into their own pack, like the kit's example map. > **The local [Terrain] trap**: A `[Terrain]` placed in a subfolder replaces the parent folder's whole `[Terrain]`. If you don't copy `PrefabRoot` into it, it is lost for that folder. Copy `PrefabRoot` over, or write `[+Terrain]` to change only what you need. **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] = -*.pack PackFile = /data/mod.pack PackType = mod ``` 1. ` = -*.pack`: every file except packs; the `-` sign excludes. 2. `PackFile`: the pack to build. For the word ``, 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 = /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). > **A battle map, two folders**: A battle map spans **two** `working_data` folders: the tile map and the tile (`working_data/terrain/tiles/battle///`). Put the **same** `rules.bob` in the tile's folder, or it goes into `mod.pack` and the map is split in two. The kit's example map does this: three `rules.bob` files, including its `_tile_database/TILES/` entry, pointing to one pack. 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. *Diagram: One map, one pack: the same rule in each folder.* In the diagram: One map, two folders, one pack · No rule in the tile's folder · The tile map · `terrain/battles/my_map/` · `rules.bob` · The tile · `terrain/tiles/battle///` · no rules.bob · `my_map.pack` · the tile map only · `mod.pack` · the tile, via working_data/rules.bob · the map is split in two · The same rule in both folders · The tile map · `terrain/battles/my_map/` · `rules.bob` · The tile · `terrain/tiles/battle///` · `rules.bob` · `my_map.pack` · the tile map and the tile · the whole map in a single pack · The kit's example map: 3 rules.bob, 1 pack · `tile map` · `tile` · `_tile_database/TILES/` · → · `assembly_kit_example.pack` · In _tile_database/TILES/, the example tile has its entry (test_tiles_assembly_kit_example_tile.bin and .xml), and that folder's rule sends it into assembly_kit_example.pack: if BOB writes your tile's entry there, check in RPFM which pack it went into. The same [Pack] rule in both of the map's folders, or the tile goes into mod.pack. ### 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 : what we know, and what we don't Pack rules write `PackFile = /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 `/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. *Diagram: Where did my pack go?.* In the diagram: Where did my pack go? · ? · A route unproven in Warhammer III · deduced from a [Copy] rule and the Rome II guide · Look for it in both places · its modification date gives it away · ? · `/retail/data/` · probably here: for us, · led into the kit; Rome II puts its pack here · `/data/` · where the game reads packs · Copy it by hand, if it stayed in the kit · Open it in RPFM · BOB cannot reopen a pack. · terrain/battles// and the tile, nothing else: neither the example map nor a .pack · Enable it in the launcher · then test it in game. · The proven route: making the pack with RPFM If you try the [Pack] rule: find the pack, copy it into the game's data folder, check it in RPFM. ## 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. *Diagram: Three doors into BOB: the Steam launcher, the executable, Terry.* In the diagram: Three doors into BOB · Steam launcher · of the Assembly Kit · `Exporter: BOB` · which passes · `-no_console` · Its executable · in the Assembly Kit · `binaries/bob.modder.x64.exe` · Terry · in its File menu · `Process with BOB` · `or Ctrl+P` · hands it the work · BOB: its window · `BOB - Select Data Files To Build` · `A node` · `An action` · `Start` · it waits for you to pick its work · before Start: Terry and the game closed · In the background · Messages at Terry's bottom right · A new BOB each time · No option known besides -no_console: -h or --help open · "Illegal option format", which blocks BOB. Don't try it on Terry or Tweak either. BOB opens from the Assembly Kit's Steam launcher (Exporter: BOB), from its executable or from Terry. The first two doors open its window, where you pick its work; Terry, for its part, hands BOB the work, and each Process with BOB starts a new BOB. ### 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 ``, then Start. Three typical uses: | Job | Node and action | What to know | |---|---|---| | Export the database | `database` node → `` | for us: 3,788 actions in 109 seconds; one folder per table in `working_data/db/` (1,694), each with a `data` file. Useful when a tool wants the database in the game's format: see "Exporting the kit's database" below | | Texts | the *Retail Pack* option | described on the tw-modding wiki's [Localisation](https://tw-modding.com/wiki/Localisation) page, written for Warhammer II; not checked in Warhammer III. The `.loc` it produces holds every line, with the same risks as an exported table: recommended route, RPFM ([the RPFM guide](https://bretonia.dev/atelier/en/rpfm/)) | | The startpos | `campaigns` node in the Working Data column → *Campaign / Process start pos ()* | this action launches the game; for us, it failed ("Startpos file not found after running the game!"), even for a CA campaign. The three startpos 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](https://bretonia.dev/atelier/en/tools/) | 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: | Steam launcher option | Program launched | |---|---| | *Exporter: BOB* | `binaries/bob.modder.x64.exe -no_console` | | *Battle Map Editor: Terry* | `binaries/tweak.modder.x64.exe /standalone TerrainMetadataEditor` | | *Database Editor: Dave* | `dave/DaVE.retail.x64.exe`, no option | 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. > **Never guessed options**: Never start BOB, Terry or Tweak with guessed options. On BOB, `-h` and `--help` open an "Illegal option format" box that **blocks** the program, and a script waiting for it to finish hangs; don't try it on Terry or Tweak either. To learn a tool's options, look at what its official launcher passes it (the table above), or ask the community. ## 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: *Diagram: Where BOB writes: the same path, three exceptions.* In the diagram: Where BOB writes · For terrain: the same path · `raw_data/` · `terrain/battles/my_map/` · a BOB run · `working_data/` · `terrain/battles/my_map/` · the same path · `tile_map.bmd` · `tile_list.bin` · `map_info.xml` · `…` · Three exceptions · The database export · one folder per table, with a data file inside · `working_data/db/_tables/data` · and also, into raw_data, start_pos_… tables: `raw_data/EmpireDesignData/campaigns//` · `[Copy]` · `→ /…` · for us: `assembly_kit/retail/…` · `[Pack]` · ? · `→ /data/` · its pack; unproven in Warhammer III · BOB rewrites its outputs on every run · A hand edit in working_data vanishes on the next run: fix the source. · A fresh output carries the date of the run. For terrain, a BOB output keeps its source's path, under working_data instead of raw_data: that is how you find what a run wrote. Three exceptions: the database export, and the [Copy] and [Pack] rules, which write under . | Output folder | Files | |---|---| | `working_data/terrain/battles//`: the tile map | `tile_map.bmd`, `tile_list.bin`, `lf_normal.dds`, `full_lf_logic_map.compressed_map`, `map_info.xml` | | `working_data/terrain/tiles/battle///`: the tile | `tile_height_map.compressed_map`, `blend0.dds`, `bmd_data.bin`, the grass and tree lists | For a campaign, outputs go to `working_data/terrain/campaigns//` and `working_data/campaign_maps//`. Three exceptions to the same-path rule: - **The database export** writes one folder per table, `working_data/db/
_tables/`, with a `data` file inside; and also, for each campaign, starting-position tables (`start_pos_…`) in `raw_data/EmpireDesignData/campaigns//`, so into `raw_data`. - **A `[Copy]` rule** writes under ``: for us, into the kit's `assembly_kit/retail/…` folder. - **A `[Pack]` rule** writes its pack under `/data/`: see "The word " 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. | Log | What you read there | |---|---| | `bob.log` | the main log. Its first line announces the number of actions selected (`N action(s) were selected for execution.`); then come one `=== Processor / Action (…) (STATUS: Finished) ===` line per action done, the durations (`All actions took … msecs`), then the exit code (`Exit code: 0` on our successful runs) | | `bob_warnings.log` | the warnings, including the "Failed to find tile": read it after every terrain run | | `bob_plugin_error.log` | "Couldn't create all processors…" on every run launched by Terry, with no effect on the terrain | | `bob_error.log`, `bob_startup_error.log`, `bob_db.log` | the other logs, described by their names | ### Reading a run in three minutes *Diagram: Reading bob.log in three minutes.* In the diagram: Reading a run in three minutes · `bob.log` · in binaries/: the last run only · `N action(s) were selected for execution.` · `=== Terrain / Terry file (…) (STATUS: Finished) ===` · `Duration: … msec(s)` · `=== Terrain / Tilemap (…) (STATUS: Finished) ===` · `…` · `All actions took … msecs` · `Exit code: 0` · The first line announces N actions; Exit code: 0 must end the log. · One STATUS: Finished line per action done: you need N. · bob_warnings.log: the Failed to find tile, to be counted. · When in doubt: the other logs in the folder. · `bob_warnings.log` · `Failed to find tile for 'points …', …` · `Failed to find tile for 'points …', …` · `Failed to find valid quadtree node …` · each Failed to find tile is a hole in the terrain: aim for 0 · quadtree: an object left out, its pivot is off the map · `bob_plugin_error.log` · `Couldn't create all processors,` · `check that BOB has been built.` · known: it shows up on every run launched by Terry, with no effect on the terrain · Exit code: 0 + N STATUS: Finished lines · + 0 Failed to find tile = success · Campaign map: Exit code: 0, but 6 actions out of 15 (the Terry file and 5 masks): the kit's limit; run a control case Schematic extracts. After every run, in binaries: bob.log (N actions announced, one STATUS: Finished line per action done, Exit code: 0), then bob_warnings.log. The logs only keep the last run. 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: | Message | Where | What it means | What to do | |---|---|---|---| | `Failed to find tile` | `bob_warnings.log` | No tile in the tile database matches the pattern painted at that spot of `tile_map.png`: a road too thin, a one-hex coastal spike… Result: a **hole** in the terrain. | Fix the pattern in `tile_map.png` ([the Terry guide](https://bretonia.dev/atelier/en/terry/)), do a new run, recount. The goal is zero. | | `Failed to find valid quadtree node` | `bob_warnings.log` | An entity (a placed object, a water plane…) has its **pivot** outside the map. BOB drops it: it is missing from the built files. | Bring the pivot back inside the map, in Terry, then do a new run. | | `Couldn't create all processors, check that BOB has been built.` | `bob_plugin_error.log` | A requested processor is missing from the kit. | Nothing, if the rest of the run completes: we see it on every run launched from Terry, with no effect on the terrain. | | `prefab root … does not have a valid TargetPath` | to be checked | The `raw_data/art/prefabs/battle/` folder and its `[Prefab]` rule are not part of the run. | Bring that folder, with its rule, into the run. | 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](https://bretonia.dev/atelier/en/terry/), shows what BOB accepts. *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. 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 *Diagram: Three typical jobs, and how to check each one.* In the diagram: Three typical jobs · Building a battle map · in Terry, without opening BOB's window · `the tile map` · Run 1: Ctrl+P, then reload it · `bob.log` · Read it before the next run · `the tile` · Map Properties: legacy vegetation off; run 2: Ctrl+P · `bob.log` · Read it right away · Check after every run: Exit code: 0, as many · STATUS: Finished lines as the first line announces actions; 0 "Failed to find tile" in bob_warnings.log. · Exporting the kit's database · first: Terry and the game closed · `database → ` · In BOB's window · `Start` · Everything turns green · `working_data/db/` · One folder per table · Check: Exit code: 0; one folder per table, with its data file, dated from the run (1,694 for us). · Building a pack · two routes · `RPFM` · The proven route · or · `[Pack] rule` · ? · Unproven in Warhammer III · Check: open it in RPFM; terrain/battles// and the tile, nothing else (neither the example map nor a .pack). Three typical jobs, each with its check: a battle map (Terry launches BOB), the database export (in BOB's window) and the pack (RPFM, the proven route; BOB's [Pack] rule is unproven in Warhammer III). ### Building a battle map Painting, zones and creating the tile map are in [the Terry guide](https://bretonia.dev/atelier/en/terry/). Here is BOB's part: 1. Save, then **open the tile map** (the project in `raw_data/terrain/battles//`) 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//` (trailing slash included), a text and an image: see [the Terry guide](https://bretonia.dev/atelier/en/terry/). 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//` 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 ``: 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//`: don't be surprised to find them there. > **Export, yes; pack everything, no**: A table exported by the kit carries **all** its rows, not just the ones you changed. Put as is into a pack, it hurts compatibility with other mods. For a mod, only add your own rows, in a table fragment under your own name: that is RPFM's job ([the RPFM guide](https://bretonia.dev/atelier/en/rpfm/)). ### 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](https://bretonia.dev/atelier/en/rpfm/)). - **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 `` 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//`, 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](https://bretonia.dev/atelier/en/terry/), the map's logical half in [the CAIME guide](https://bretonia.dev/atelier/en/caime/). ### 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. *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. **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 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. *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 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. *Diagram: Only six actions: the control case.* In the diagram: Only six actions? · How many actions does bob.log announce? · over 6 · Not the limit · 15 for us on a complete run; then count the · Failed to find tile in bob_warnings.log · Run a control case · a project known to be good, copied under another name, then run through BOB · And the control case? · over 6 · Your project · is to blame: search your own files · 6 too · The kit's limit · your project is not to blame: ask the community · don't force the tool · The 6 actions of an unknown map · the Terry file and five masks; no relief, no textures, no logic map, no shroud; and no message at all. Six actions instead of fifteen, without a message: a control case tells whether it is your project or the kit's limit. 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 *Diagram: BOB's pitfalls, along a run.* In the diagram: The pitfalls, along a run · While preparing · A local [Terrain] without PrefabRoot · copy it over, or [+Terrain] · The * wildcard stops at folders · start the filter with ... · The tile without the [Pack] rule · the same rule in both folders · A whole exported table · only your rows, with RPFM · A hand edit in working_data · fix the source · While starting BOB · -h, --help: "Illegal option format" · no guessed options · Terry or the game open · close them before Start · A node ticked, then a click elsewhere · pick an action · A single action · take · BOB kept open (campaign) · close and reopen it · A window you cannot find · Alt+Tab, then Windows + Up arrow · While checking · Overwritten logs · read them after every run · 6 actions out of 15, no message · unknown map: a control case · is not necessarily the game · look in the kit too · A pack built by BOB · open it in RPFM Fifteen pitfalls, sorted by when they bite: while preparing, while starting BOB, while checking. In red the pitfall, after the green arrow its fix. - **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 ``. - **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. - **``** 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 ``, 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; `` is at the top of Consumer actions, and Provider actions is empty for `database`. - `rules.bob`: sections = processors, `Key = value` lines, `` 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; `` 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/
_tables/data`, and also per-campaign starting-position tables in `raw_data/EmpireDesignData/campaigns/`; `[Copy]` and `[Pack]` write under ``. - 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](https://bretonia.dev/atelier/en/tools/)). - 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](https://bretonia.dev/atelier/en/terry/), [the RPFM guide](https://bretonia.dev/atelier/en/rpfm/), [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: [Rules.bob](https://wiki.totalwar.com/w/Rules.bob_Documentation.html), [BoB (Attila)](https://wiki.totalwar.com/w/Total_War:_ATTILA_BoB.html) and [Terry introduction](https://wiki.totalwar.com/w/TWW_Assembly_Kit_Terry_Intro). The "TWW" pages date from the Total War: WARHAMMER kit (2016): some labels have changed since. - 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) (ChaosRobie's Warhammer III part: Process with BOB from Terry, its messages), [Beginner's Guide](https://tw-modding.com/wiki/Tutorial:Beginner%27s_Guide) and [Localisation](https://tw-modding.com/wiki/Localisation). - Heaven Games: [the Rome II Assembly Kit guide](https://rome2.heavengames.com/cgi-bin/forums/display.cgi?action=ct&f=48,6,,30) (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](https://bretonia.dev/atelier/en/terry/), [RPFM](https://bretonia.dev/atelier/en/rpfm/), [CAIME](https://bretonia.dev/atelier/en/caime/), [the modder's tools](https://bretonia.dev/atelier/en/tools/) and [modding with an AI](https://bretonia.dev/atelier/en/ai/); and [the workshop](https://bretonia.dev/atelier/en/). ## Frequently asked questions ### What is BOB in the Total War: Warhammer III Assembly Kit? The kit's builder: it turns the sources in `raw_data` (database tables, Terry terrain projects) into game files in `working_data`, and can gather them into packs. It opens from the Assembly Kit's Steam launcher (Exporter: BOB), from its executable `bob.modder.x64.exe`, or from Terry (File → Process with BOB, Ctrl+P), which hands it the work. ### Do I need to open BOB for a battle map? No. Terry launches BOB itself (File → Process with BOB, Ctrl+P), on the tile map then on the tile, and RPFM makes the pack. BOB's window is mostly for exporting the kit's database. ### Where are BOB's logs? In the Assembly Kit's `binaries` folder: `bob.log`, `bob_warnings.log`, `bob_error.log`, `bob_plugin_error.log`, `bob_startup_error.log` and `bob_db.log`. They only keep the last run. ### How do I know whether a BOB run succeeded? The first line of `bob.log` announces the number of actions selected; there must be as many `STATUS: Finished` lines, and the log must end with `Exit code: 0`. `bob_warnings.log` must hold no Failed to find tile, and the output files must carry the run's date. A pack is checked in RPFM. ### I ticked a folder and BOB did nothing: why? A node only stays ticked if one of its actions is: ticking then clicking elsewhere cancels the selection without a message. And a single action may produce nothing; pick , which adds the dependencies. ### BOB started but I can't see anything: what now? Launched from Terry, BOB works in the background: its messages appear at the bottom right of Terry, and `bob.log` says what it did. Opened from Steam or from its executable, its window once opened tiny, at the bottom of the screen: select it with Alt+Tab, then enlarge it with Windows + Up arrow. If a script launched it with a guessed option, an "Illegal option format" box may be blocking it. ### Which command-line options does BOB accept? The only one known for it is `-no_console`, the one the Steam launcher passes (Exporter: BOB). BOB has no help: `-h` and `--help` open an "Illegal option format" box that blocks it. Don't try guessed options, on BOB, Terry or Tweak. ### Where does BOB put the pack it builds? The `[Pack]` rule writes it to `/data/`. For us, `` pointed to a `retail` folder inside the kit (`assembly_kit/retail/`), as in the Rome II kit guide; this is not confirmed for a pack in Warhammer III, where this route is unproven. Look for it there, then copy it into the game's `data/` folder. The proven route remains RPFM. ### My pack only holds the tile map: why? A battle map spans two `working_data` folders: the tile map and the tile (`terrain/tiles/battle///`). If only the tile map carries your `[Pack]` rule, the tile climbs up to the top `rules.bob` and goes into `mod.pack`. Put the same rule in the tile's folder, or make the pack with RPFM. ### What does "Failed to find tile" mean? That no tile in the tile database matches the pattern painted at that spot of `tile_map.png` (a road too thin, a one-hex coastal spike…). Each occurrence, found in `bob_warnings.log`, is a hole in the terrain: fix the pattern and do a new run, until the count is zero. ### Why doesn't BOB build all the terrain of my new campaign map? 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. We know of no official way to lift this limit: run a control case (a project known to be good, copied under another name), then ask the community. ### Should I close Terry before running BOB? 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.