# BOB, le guide : compiler le terrain et bâtir des packs avec l'Assembly Kit de Total War: Warhammer III > BOB est le bâtisseur de l'Assembly Kit : il transforme ce que vous avez préparé dans Terry et dans la base du kit en fichiers que Total War: Warhammer III sait lire. Ce guide explique sa fenêtre, ses recettes (les fichiers rules.bob), comment le lancer, où lire ce qu'il a fait, et les pièges qui nous ont coûté des heures en portant une carte de campagne de Warhammer I dans Warhammer III. Page : https://bretonia.dev/atelier/bob/ · Atlas de Bretonnie, atelier des moddeurs · mis à jour le 2026-09-25. Version en texte brut, pour les lecteurs et les IA ; les schémas y sont décrits en mots. Relu le 25 septembre 2026, mise à jour 9.0. Écrit contre ses sources, l'Assembly Kit au patch 8.1, le wiki de CA et tw-modding ; ce que la 9.0 a changé sur notre chantier y est ajouté, le reste n'a pas été revérifié point par point. ## Ce que fait BOB > **En bref** : Pour une carte de bataille, vous n'ouvrez pas la fenêtre de BOB : Terry le lance (Ctrl+P), RPFM fait le pack. La fenêtre sert surtout à exporter la base. Après chaque passage : `bob.log` (`Exit code: 0` et le bon nombre d'actions), puis `bob_warnings.log`. BOB est le **bâtisseur** de l'Assembly Kit, le kit officiel de Creative Assembly (Steam → Bibliothèque → Outils). Il ne sert pas à dessiner : il **transforme**. Il prend les sources rangées dans `raw_data` (les tables de la base, les projets de terrain de Terry) et en tire les fichiers du jeu, qu'il écrit dans `working_data` ; il sait aussi les réunir en packs. Le [guide du débutant](https://tw-modding.com/wiki/Tutorial:Beginner%27s_Guide) du wiki tw-modding développe son nom en *Build-on One Button*. Pourquoi ce passage obligé ? Parce que le jeu ne lit pas les formats de travail. Un relief peint dans Terry est une image `.tif` ; le jeu veut des cartes compilées (`.compressed_map`, `.dds`, `.bin`). Une table éditée dans Dave, l'éditeur de la base du kit (CA l'écrit DaVE ; le lanceur Steam dit *Database Editor: Dave*), est un fichier XML ; le jeu veut ses tables dans son propre format. BOB fait la traduction. Le schéma ci-dessous suit une carte de bataille de la source au jeu : le projet Terry (la tile map et la tuile) dans `raw_data`, BOB et ses `rules.bob`, les fichiers du jeu dans `working_data`, puis les deux chemins vers un pack : RPFM, la voie éprouvée, ou une règle de BOB, que nous n'avons pas éprouvée dans Warhammer III. *Schéma : De la source au jeu, par BOB.* Dans le schéma : raw_data · votre projet Terry · Terry · `terrain/battles//terrain/tiles/battle///` · la tile map (le cadre), puis la tuile (ce que vous peignez) · `Process with BOB (Ctrl+P)` · la tile map, puis la tuile · BOB · lit les rules.bob · journaux : binaries/bob*.log · working_data · `tile_map.bmd · tile_list.bin · blend0.dds …` · les fichiers du jeu, sous les mêmes chemins qu'en raw_data ; cadenas : Terry ouvert verrouille working_data, sauf pour le BOB qu'il lance lui-même · `règle [Pack]` · ? · Règle [Pack] · non éprouvée dans Warhammer III · sans doute dans le kit : `retail/data/` · recopie à la main · `ajout du` · `dossier` · RPFM · la voie éprouvée · `working_data/terrain/` · sans la carte d'exemple · `battles_tables` · votre ligne, texte, image · Le jeu · `data/ → lanceur` · `→ bataille personnalisée` Une carte de bataille, de la source au jeu : Terry fait passer BOB sur la tile map, puis sur la tuile ; BOB suit les rules.bob et écrit les fichiers du jeu sous les mêmes chemins, dans working_data. Le pack se fait avec RPFM, la voie éprouvée ; une règle [Pack] de BOB le poserait sans doute dans le dossier retail du kit, voie que nous n'avons pas éprouvée dans Warhammer III. BOB est dans le dossier `binaries` du kit : `bob.modder.x64.exe`. Il s'ouvre par le lanceur Steam, par son exécutable ou depuis Terry : voir « Ouvrir BOB et lui donner du travail », plus bas. Il est fait de modules, un par métier ; le kit de Warhammer III livre entre autres `bob_terrain`, `bob_tile`, `bob_vegetation`, `bob_texture`, `bob_campaign`, `bob_dbexport`, `bob_localisation`, `bob_lua`, `bob_pack` et `bob_files`. Ce que BOB ne fait pas : la moitié logique d'une carte de campagne (régions, routes, pathfinding). Celle-là, c'est le travail de CAIME (Campaign AI Map Editor), l'éditeur du Campaign Map Toolkit : voir [le guide CAIME](https://bretonia.dev/atelier/caime/). ### Le vocabulaire | Mot | Sens | |---|---| | `raw_data` | les sources : ce que les outils du kit lisent (tables XML de la base, projets de Terry, images) | | `working_data` | ce que BOB produit : les fichiers au format du jeu, rangés pour l'essentiel sous le même chemin que leur source (voir « Ce que BOB produit ») | | Base du kit | les tables XML de `raw_data/db`, qu'édite Dave | | Base du jeu | celle des packs de CA ; pour une carte de campagne, c'est elle qui compte (voir « BOB et une carte de campagne ») | | Nœud | un dossier ou un fichier dans l'un des arbres de la fenêtre de BOB | | Action | un travail que BOB sait faire sur un nœud ; chaque nœud en propose plusieurs | | Processeur | la partie de BOB qui fait un type de travail ; `bob.log` le nomme devant chaque action | | Passage | une exécution de BOB, du lancement jusqu'au code de sortie | | Règle | une section d'un `rules.bob`, avec ses réglages `Clé = valeur` ; chaque section règle un processeur | | `rules.bob` | un fichier texte de règles, posé dans un dossier ; il vaut pour ce dossier et ceux du dessous, sauf règle plus proche | | Pack | l'archive `.pack` que lit le jeu ; un mod en est un | | `` | un mot réservé des `rules.bob`, qui désigne un dossier de destination ; voir plus bas ce que nous en savons | | Journal | les fichiers `.log` de BOB, dans `binaries`, réécrits à chaque passage | ## La fenêtre de BOB Ouvert par le lanceur Steam (*Exporter: BOB*) ou par son exécutable, BOB affiche une fenêtre intitulée **BOB - Select Data Files To Build**. Elle montre **Raw Data** (les sources) et **Working Data** (ce qui est déjà bâti) ; un troisième arbre, **Retail Data**, montre le dossier `retail` du kit (on y voit `assembly_kit` et `data`). Le kit de Rome II avait déjà un arbre *retail*. Un clic droit sur un nœud ouvre un menu de trois entrées : *View rules*, *View actions* et *Select files only*. *View actions* ouvre une petite fenêtre « BOB » : les deux listes d'actions du nœud, décrites ci-dessous. Nous avons relevé cette fenêtre et ce menu à l'écran le 24.09.2026, sur l'Assembly Kit 1.3.4908. *Schéma : La fenêtre de BOB et ses neuf repères.* 1. **Le titre** : BOB - Select Data Files To Build : la fenêtre qu'affiche BOB ouvert par le lanceur Steam de l'Assembly Kit (Exporter: BOB) ou par son exécutable, bob.modder.x64.exe. 2. **Raw Data** : l'arbre des sources, celles de raw_data ; un nœud est un dossier ou un fichier. 3. **Working Data** : l'arbre de ce qui est déjà bâti, dans working_data. 4. **Retail Data** : un troisième arbre, qui montre le dossier retail du kit (on y voit assembly_kit et data). 5. **La fenêtre des actions** : une petite fenêtre « BOB », que l'on ouvre en cochant un nœud (ici database) ; un clic droit sur un nœud propose View rules, View actions et Select files only, et View actions l'ouvre aussi. Deux listes, Provider actions (vide pour database) et Consumer actions, chacune avec une case Merge Actions. 6. **** : en tête de Consumer actions : toutes les actions ; BOB y ajoute de lui-même ce dont elles dépendent (le nœud Database Export). Une action seule peut ne rien produire : Build Queried Campaign Tables seule donne 0 fichier. 7. **Le piège** : cocher un nœud puis cliquer ailleurs sans choisir d'action : il se décoche, sans aucun message, et Start ne fera rien pour lui. 8. **Start** : en bas à droite ; chaque action passe au vert quand elle est faite. Export de la base, chez nous : 3 788 actions en 109 s. 9. **bob.log** : ensuite, dans binaries : le nombre d'actions de la première ligne, autant de lignes STATUS: Finished, puis Exit code: 0. Schéma : les arbres et la fenêtre des actions relevés le 24.09.2026 sur l'Assembly Kit 1.3.4908, disposition schématique. Pour exporter la base : cocher database, qui ouvre la fenêtre des actions (5), prendre en tête de Consumer actions (6), Start (8), puis lire bob.log (9). Pour une carte de bataille, on n'ouvre pas cette fenêtre : Terry lance BOB lui-même (Process with BOB, Ctrl+P). 1. **Cochez un nœud.** Ses actions s'affichent, en deux listes : *Provider actions* et *Consumer actions*, chacune avec une case *Merge Actions*. Pour le nœud `database`, la première est vide. 2. **Choisissez une action**, ou ``, en tête de *Consumer actions*, pour les prendre toutes. Avec ``, BOB ajoute de lui-même ce dont elles dépendent (par exemple le nœud *Database Export*). 3. **Recommencez** pour chaque nœud à traiter. 4. **Cliquez sur Start**, en bas à droite. Chaque action passe au vert quand elle est faite. **Comment vérifier que ça a marché.** Toutes les actions choisies sont vertes. Lisez ensuite `bob.log` : voir « Les journaux de BOB », plus bas. > **Cocher ne suffit pas** : Un nœud ne reste coché que si une de ses actions l'est. Si vous cochez un nœud puis cliquez ailleurs sans choisir d'action, la sélection s'annule **sans aucun message**, et Start ne fera rien pour ce nœud. Autre piège : une action seule peut ne rien produire. Pour exporter les tables d'une campagne, *Build Queried Campaign Tables* seule donne zéro fichier ; `` règle le problème. Pourquoi tant de précautions ? Parce que BOB ne signale pas toujours ce qu'il n'a pas fait. Un passage peut se terminer sans erreur et sans avoir produit le fichier que vous attendiez. D'où la règle de ce guide : **après chaque passage, on vérifie**. ## Les fichiers rules.bob : les recettes de BOB BOB ne décide pas seul de ce qu'il fait d'un fichier. Il suit des **règles**, écrites dans des fichiers texte nommés `rules.bob`, posés dans les dossiers de `raw_data` et de `working_data`. Une règle dit, par exemple, où chercher les prefabs d'un terrain, ou dans quel pack ranger un dossier. ### La syntaxe - Chaque `[Section]` désigne un **processeur** ; en dessous, une ligne par réglage : `Clé = valeur`. - La clé `` filtre les fichiers visés : listes séparées par des virgules, exclusion par un `-` placé devant, et joker `*`, qui vaut tout caractère sauf `/` : il ne traverse pas les dossiers. - Trois points, `...`, valent tout caractère, `/` compris : `...*.terry` vise donc aussi les fichiers `.terry` des sous-dossiers (page BoB d'Attila de CA). Les règles `[Tile]` et `[Prefab]` du kit s'en servent. - Sections des `rules.bob` livrés par CA : `[Pack]`, `[Terrain]`, `[Tile]`, `[Prefab]`, `[Copy]` et `[+AssetGraph]`. Le `rules.bob` de campagne de ChaosRobie (`raw_data/terrain/campaigns/rules.bob`, le dossier parent des cartes) ajoute `[Prop]`, `[Entity]`, `[Mesh]` et `[Texture]`. - `[Copy]` et `[+AssetGraph]` semblent servir à CA pour livrer la carte d'exemple : elles recopient les données brutes dans le dossier `retail` du kit (`IncludeInRetail = true`). Un mod n'en a pas besoin. - N'inventez ni section ni clé : tenez-vous à celles que montrent le kit et la documentation de CA. ### Comment BOB trouve la règle d'un fichier 1. BOB cherche un `rules.bob` dans le dossier du fichier qu'il traite, et regarde si une de ses règles vise ce fichier, filtres compris. 2. Sinon, il remonte d'un dossier, et recommence. 3. La **première** règle qui s'applique gagne. Arrivé en haut sans en trouver, il prend ses valeurs par défaut. Une règle locale peut remplacer celle du dessus, ou seulement la compléter. Tout tient dans un signe : | Écriture | Effet | |---|---| | `[Nom]` | remplace **entièrement** la règle héritée : une clé que vous ne recopiez pas n'y est plus | | `[+Nom]` | garde la règle héritée et ne change que les clés citées | Le schéma ci-dessous suit trois fichiers de `working_data` : chacun remonte l'arborescence jusqu'au premier `rules.bob` qui s'applique, et c'est cette règle qui décide du pack où il part. *Schéma : Comment BOB choisit sa règle.* Dans le schéma : Chaque fichier remonte au premier rules.bob · `working_data/` · `rules.bob` · `[Pack] = -*.pack` · `PackFile = /data/mod.pack` · `db/land_units_tables/` · `data` · `mod.pack` · (le défaut de CA ; une table exportée ne se publie pas telle quelle) · `terrain/` · `battles/ma_carte/` · `rules.bob` · `[Pack] BasePath = /PackFile = /data/ma_carte.pack` · `tile_map.bmd` · `ma_carte.pack` · `tiles/battle///` · `rules.bob` · `la même règle, vers ma_carte.pack` · `blend0.dds` · `ma_carte.pack` · [Pack] remplace la règle héritée ; [+Pack] ne change que les clés qu'il cite. · -*.pack exclut ; * vaut tout caractère sauf /, et ne traverse donc pas les dossiers ; ... les traverse. BOB cherche un rules.bob dans le dossier du fichier, puis remonte de dossier en dossier : la première règle qui s'applique gagne. Ici, une table part dans mod.pack ; la tile map et la tuile, qui portent la même règle, partent ensemble dans leur propre pack, comme la carte d'exemple du kit. > **Le piège du [Terrain] local** : Un `[Terrain]` posé dans un sous-dossier remplace tout le `[Terrain]` du dossier parent. Si vous n'y recopiez pas `PrefabRoot`, il est perdu pour ce dossier. Recopiez `PrefabRoot`, ou écrivez `[+Terrain]` pour ne changer que ce qui vous intéresse. **Comment vérifier qu'une règle s'applique.** Après le passage, vérifiez que l'effet annoncé a eu lieu (par exemple, le pack où les fichiers sont partis). Sinon, une règle plus proche du fichier l'a peut-être emporté : cherchez-la en remontant ses dossiers. ## Trois rules.bob du kit, ligne à ligne Rien ne vaut des règles réelles. Le premier et le troisième fichier sont livrés par CA ; le deuxième suit le modèle de la carte d'exemple du kit, compression en plus. Chaque bloc se recopie tel quel ; les notes numérotées dessous l'expliquent ligne à ligne. ### Premier fichier : working_data/rules.bob ``` [Pack] = -*.pack PackFile = /data/mod.pack PackType = mod ``` 1. ` = -*.pack` : tous les fichiers, sauf les packs ; le signe `-` exclut. 2. `PackFile` : le pack à bâtir. Pour le mot ``, voir plus bas. 3. `PackType = mod` : la seule valeur que montre la documentation de CA. 4. Placée au sommet de `working_data`, cette règle vaut pour tout fichier qui ne trouve pas de `[Pack]` plus près de lui. CA la résume ainsi : tout, sauf les packs, part dans `mod.pack`. ### Deuxième fichier : un pack à part pour une carte de bataille À poser dans le dossier de la tile map, `working_data/terrain/battles/ma_carte/`, et dans celui de la tuile (voir l'encadré) : ``` [Pack] BasePath = / PackFile = /data/ma_carte.pack PackType = mod Compressed = true CompressionType = LZ4 ``` 1. `BasePath = /` : selon la page Rules.bob de CA, on l'ajoute quand la règle est posée dans un sous-dossier, pour envoyer son contenu vers un autre pack. La carte d'exemple l'écrit ainsi. 2. `PackFile` : le pack de la carte. Ce `[Pack]` est plus proche des fichiers de la tile map que celui du sommet : ils partent dans `ma_carte.pack`, et plus dans `mod.pack`. 3. `PackType = mod` : comme dans le premier fichier. 4. `Compressed` et `CompressionType` : facultatifs. La compression se fait en `LZ4` ou en `ZSTD`. La documentation du kit (`documentation/pack/pack/compression.txt`) la déconseille pour les sons et les vidéos, et invite à la prudence pour les modèles (`LZ4` si elle est vraiment nécessaire). > **Une carte de bataille, deux dossiers** : Une carte de bataille occupe **deux** dossiers de `working_data` : la tile map et la tuile (`working_data/terrain/tiles/battle///`). Posez le **même** `rules.bob` dans le dossier de la tuile, sinon elle part dans `mod.pack` et la carte est coupée en deux. La carte d'exemple du kit fait ainsi : trois `rules.bob`, dont celui de son entrée `_tile_database/TILES/`, vers un seul pack. Ce dernier `rules.bob`, celui de `_tile_database/TILES/`, vise `assembly_kit_example.pack` : si votre tuile a aussi une entrée dans ce dossier, vérifiez dans RPFM le pack où elle est partie. *Schéma : Une carte, un pack : la même règle dans chaque dossier.* Dans le schéma : Une carte, deux dossiers, un pack · Sans règle dans le dossier de la tuile · La tile map · `terrain/battles/ma_carte/` · `rules.bob` · La tuile · `terrain/tiles/battle///` · aucun rules.bob · `ma_carte.pack` · la tile map seule · `mod.pack` · la tuile, par working_data/rules.bob · la carte est coupée en deux · La même règle dans les deux dossiers · La tile map · `terrain/battles/ma_carte/` · `rules.bob` · La tuile · `terrain/tiles/battle///` · `rules.bob` · `ma_carte.pack` · la tile map et la tuile · toute la carte dans un seul pack · La carte d'exemple du kit : 3 rules.bob, 1 pack · `tile map` · `tuile` · `_tile_database/TILES/` · → · `assembly_kit_example.pack` · Dans _tile_database/TILES/, la tuile d'exemple a son entrée (test_tiles_assembly_kit_example_tile.bin et .xml), et la règle de ce dossier l'envoie dans assembly_kit_example.pack : si BOB y écrit l'entrée de votre tuile, vérifiez dans RPFM où elle est partie. La même règle [Pack] dans les deux dossiers de la carte, sinon la tuile part dans mod.pack. ### Troisième fichier : raw_data/terrain/battles/rules.bob ``` [Terrain] PrefabRoot = art/prefabs/battle save_meta_data_map = false save_final_tile_map = true ``` 1. C'est une règle de **traitement**, pas de pack : elle dit où chercher les prefabs de bataille (`PrefabRoot`), et quelles cartes écrire (les deux clés `save_…`). 2. `PrefabRoot = art/prefabs/battle` vaut pour une bataille. Pour un terrain de campagne, le projet de ChaosRobie écrit `art\prefabs\campaign` : c'est la valeur de ce projet ; suivez celui que vous reprenez. 3. `save_meta_data_map` et `save_final_tile_map` : gardez-les tels que CA les donne. ### Le mot : ce que nous savons, et ce que nous ne savons pas Les règles de pack écrivent `PackFile = /data/…`. On le lit volontiers comme « le dossier du jeu ». Ce n'est pas ce que nous avons observé : - Sur notre installation, une règle `[Copy]` qui visait `/assembly_kit/…` a écrit dans `assembly_kit/retail/assembly_kit/…` : dans un dossier `retail` **à l'intérieur** du kit. - Le guide de l'Assembly Kit de Rome II trouve de même le pack fini dans `assembly_kit/retail/data`. - La fenêtre de BOB a d'ailleurs un arbre **Retail Data**, qui montre ce dossier `retail` du kit (on y voit `assembly_kit` et `data` ; relevé le 24.09.2026). Un pack bâti par BOB arriverait donc dans `assembly_kit/retail/data/`, et non dans le dossier `data` du jeu. **Nous ne l'avons pas vérifié dans Warhammer III** pour un pack : c'est une déduction, et la voie `[Pack]` elle-même n'y est pas éprouvée. Après un passage, cherchez le pack aux deux endroits (sa date de modification le trahit), et recopiez-le à la main dans `data/` du jeu s'il n'y est pas. *Schéma : Où est passé mon pack ?.* Dans le schéma : Où est passé mon pack ? · ? · Voie non éprouvée dans Warhammer III · déduit d'une règle [Copy] et du guide de Rome II · Cherchez-le aux deux endroits · sa date de modification le trahit · ? · `/retail/data/` · sans doute ici : chez nous, a mené dans le kit ; Rome II y range son pack · `/data/` · là où le jeu lit les packs · Recopiez-le à la main, s'il est resté dans le kit · Ouvrez-le dans RPFM · BOB ne sait pas rouvrir un pack. · terrain/battles// et la tuile, rien d'autre : ni la carte d'exemple, ni un .pack · Activez-le au lanceur · puis testez en jeu. · La voie éprouvée : faire le pack avec RPFM Si vous essayez la règle [Pack] : trouver le pack, le recopier dans le dossier data du jeu, le vérifier dans RPFM. ## Ouvrir BOB et lui donner du travail BOB s'ouvre par le lanceur Steam de l'Assembly Kit (*Exporter: BOB*), par son exécutable `bob.modder.x64.exe`, ou depuis Terry (*Process with BOB*, Ctrl+P), qui lui passe le travail. En ligne de commande, on ne lui connaît que l'option `-no_console`, celle que passe le lanceur. Ouvert par Steam ou par son exécutable, BOB montre sa fenêtre et attend qu'on lui choisisse du travail. Ouvert par Terry, il travaille en arrière-plan, et ses messages s'affichent en bas à droite de Terry. La ligne de commande ne sert qu'à l'ouvrir : le travail se choisit dans la fenêtre, ou dans Terry. *Schéma : Trois portes vers BOB : le lanceur Steam, l'exécutable, Terry.* Dans le schéma : Trois portes vers BOB · Lanceur Steam · de l'Assembly Kit · `Exporter: BOB` · qui passe · `-no_console` · Son exécutable · dans l'Assembly Kit · `binaries/bob.modder.x64.exe` · Terry · dans son menu File · `Process with BOB` · `ou Ctrl+P` · lui passe le travail · BOB : sa fenêtre · `BOB - Select Data Files To Build` · `Un nœud` · `Une action` · `Start` · il attend qu'on lui choisisse du travail · avant Start : Terry et le jeu fermés · En arrière-plan · Messages en bas à droite de Terry · Un nouveau BOB à chaque fois · Aucune option connue à part -no_console : -h ou --help ouvrent · « Illegal option format », qui bloque BOB. Ne l'essayez pas non plus sur Terry ni sur Tweak. BOB s'ouvre par le lanceur Steam de l'Assembly Kit (Exporter: BOB), par son exécutable ou depuis Terry. Les deux premières portes ouvrent sa fenêtre, où vous lui choisissez le travail ; Terry, lui, passe le travail à BOB, et chaque Process with BOB démarre un nouveau BOB. ### Depuis Terry - Dans Terry : **File → Process with BOB** (Ctrl+P), ou le bouton en globe avec une flèche vers la droite (barre d'outils *Basic*). C'est la voie des tutoriels pour le terrain. - Terry écrit ce qu'il demande (processeurs, dossiers, sorties voulues) dans un fichier de configuration, puis lance BOB en arrière-plan ; les messages s'affichent en bas à droite de Terry. Chaque *Process with BOB* démarre un nouveau BOB. - Ce qu'il propose de bâtir dépend du type de projet (tuile, tile map de bataille, tile map de campagne) ; les options de BOB sont dans les *Settings* de Terry. - Inutile de fermer Terry : c'est lui qui lance BOB. Enregistrez d'abord : CA conseille d'enregistrer souvent, car Terry plante parfois. - Les pages du wiki de CA écrites pour le kit de 2016 parlent d'*Export Map* : dans Warhammer III, c'est **Process with BOB**, puis le pack (RPFM, ou une règle `[Pack]`, non éprouvée dans Warhammer III). **Comment vérifier que ça a marché.** Suivez les messages jusqu'à la fin, puis lisez `bob.log` dans `binaries` : le nombre d'actions annoncé en première ligne, autant de lignes `(STATUS: Finished)`, et `Exit code: 0` à la fin. ### Depuis la fenêtre de BOB Cochez le nœud, choisissez l'action ou ``, puis Start. Trois usages types : | Travail | Nœud et action | Ce qu'il faut savoir | |---|---|---| | Exporter la base | nœud `database` → `` | chez nous : 3 788 actions en 109 secondes ; un dossier par table dans `working_data/db/` (1 694), avec un fichier `data` chacun. Utile quand un outil veut la base au format du jeu : voir « Exporter la base du kit », plus bas | | Les textes | l'option *Retail Pack* | décrite par la page [Localisation](https://tw-modding.com/wiki/Localisation) du wiki tw-modding, écrite pour Warhammer II ; non vérifiée dans Warhammer III. Le `.loc` produit contient toutes les lignes, avec les mêmes risques qu'une table exportée : voie conseillée, RPFM ([le guide RPFM](https://bretonia.dev/atelier/rpfm/)) | | Le startpos | nœud `campaigns` de la colonne Working Data → *Campaign / Process start pos ()* | cette action lance le jeu ; chez nous, elle a échoué (« Startpos file not found after running the game! »), même pour une campagne de CA. Les trois voies du startpos : *Build Startpos* de RPFM, l'action *Process start pos* de BOB, ou un `user.script.txt` écrit à la main. Chez nous, seule l'écriture à la main a marché : [le guide des outils](https://bretonia.dev/atelier/outils/) | Avant de lancer BOB depuis sa fenêtre, ou d'enregistrer un pack dans `working_data`, **fermez Terry et le jeu** : Terry ouvert verrouille `working_data`. *Process with BOB*, lancé depuis Terry, n'est pas concerné. **Comment vérifier que ça a marché.** Les actions sont vertes, `bob.log` finit par `Exit code: 0`, et les fichiers attendus sont apparus avec la date du passage. ### La ligne de commande BOB n'a **aucune aide intégrée**, et on ne lui connaît que `-no_console`, l'option que lui passe le lanceur Steam. Le lanceur du kit propose trois options : | Option du lanceur Steam | Programme lancé | |---|---| | *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`, sans option | Pour un travail répétitif, préparez les `rules.bob` et les fichiers par script, puis lancez le passage d'un clic sur Start, ou depuis Terry. > **Jamais d'options devinées** : Ne lancez jamais BOB, Terry ou Tweak avec des options devinées. Sur BOB, `-h` et `--help` ouvrent une boîte « Illegal option format » qui **bloque** le programme, et un script qui attend sa fin reste suspendu ; ne l'essayez pas non plus sur Terry ni sur Tweak. Pour connaître les options d'un outil, regardez ce que son lanceur officiel lui passe (le tableau ci-dessus), ou demandez à la communauté. ## Ce que BOB produit Pour le terrain, une sortie de BOB reprend **le chemin de sa source**, sous `working_data` au lieu de `raw_data`. Une tile map de bataille rangée dans `raw_data/terrain/battles/ma_carte/` sort donc dans `working_data/terrain/battles/ma_carte/`. C'est ce qui permet de retrouver ce qu'un passage a écrit. Exemple : la carte de bataille d'exemple livrée avec le kit (`assembly_kit_example_tile_map` et sa tuile `assembly_kit_example_tile`) donne : *Schéma : Où BOB écrit : le même chemin, trois exceptions.* Dans le schéma : Où BOB écrit · Pour le terrain : le même chemin · `raw_data/` · `terrain/battles/ma_carte/` · un passage de BOB · `working_data/` · `terrain/battles/ma_carte/` · le même chemin · `tile_map.bmd` · `tile_list.bin` · `map_info.xml` · `…` · Trois exceptions · L'export de la base · un dossier par table, un fichier data dedans · `working_data/db/_tables/data` · et aussi, dans raw_data, des tables start_pos_… : `raw_data/EmpireDesignData/campaigns//` · `[Copy]` · `→ /…` · chez nous : `assembly_kit/retail/…` · `[Pack]` · ? · `→ /data/` · son pack ; non éprouvé dans Warhammer III · BOB réécrit ses sorties à chaque passage · Une retouche à la main dans working_data disparaît au passage suivant : corrigez la source. · Une sortie neuve porte la date du passage. Pour le terrain, une sortie de BOB reprend le chemin de sa source, sous working_data au lieu de raw_data : c'est ainsi qu'on retrouve ce qu'un passage a écrit. Trois exceptions : l'export de la base, et les règles [Copy] et [Pack], qui écrivent sous . | Dossier de sortie | Fichiers | |---|---| | `working_data/terrain/battles//` : la 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///` : la tuile | `tile_height_map.compressed_map`, `blend0.dds`, `bmd_data.bin`, les listes d'herbe et d'arbres | Pour une campagne, les sorties vont dans `working_data/terrain/campaigns//` et `working_data/campaign_maps//`. Trois exceptions à la règle du même chemin : - **L'export de la base** écrit un dossier par table, `working_data/db/
_tables/`, avec un fichier `data` dedans ; et aussi, pour chaque campagne, des tables de départ (`start_pos_…`) dans `raw_data/EmpireDesignData/campaigns//`, donc dans `raw_data`. - **Une règle `[Copy]`** écrit sous `` : chez nous, dans le dossier `assembly_kit/retail/…` du kit. - **Une règle `[Pack]`** écrit son pack sous `/data/` : voir « Le mot », plus haut. Deux conséquences pratiques : - **BOB réécrit ses sorties à chaque passage.** Une retouche faite à la main dans `working_data` (une liste de textures, une collection d'éclairage…) disparaît au passage suivant. Corrigez la source, ou faites la retouche par un script que vous relancez après chaque passage. - **Terry ouvert verrouille `working_data`.** Avant de lancer BOB depuis sa fenêtre, ou d'enregistrer un pack dans `working_data`, fermez Terry et le jeu ; *Process with BOB*, lancé depuis Terry, n'est pas concerné. **Comment vérifier qu'une sortie est neuve.** Regardez sa date de modification : ce doit être celle du passage. Un fichier plus ancien vient d'un passage précédent, et votre changement n'a pas été bâti. ## Les journaux de BOB BOB écrit ses journaux dans le dossier `binaries` du kit, à côté de son exécutable. **Ils ne gardent que le dernier passage** : chaque passage efface le précédent. Pour comparer deux passages, copiez les journaux ailleurs avant le passage suivant. | Journal | Ce qu'on y lit | |---|---| | `bob.log` | le journal principal. Sa première ligne annonce le nombre d'actions retenues (`N action(s) were selected for execution.`) ; viennent ensuite une ligne `=== Processeur / Action (…) (STATUS: Finished) ===` par action faite, les durées (`All actions took … msecs`), puis le code de sortie (`Exit code: 0` sur nos passages réussis) | | `bob_warnings.log` | les avertissements, dont les « Failed to find tile » : à lire après chaque passage de terrain | | `bob_plugin_error.log` | « Couldn't create all processors… » à chaque passage lancé par Terry, sans effet sur le terrain | | `bob_error.log`, `bob_startup_error.log`, `bob_db.log` | les autres journaux, que leur nom décrit | ### Lire un passage en trois minutes *Schéma : Lire bob.log en trois minutes.* Dans le schéma : Lire un passage en trois minutes · `bob.log` · dans binaries/ : le dernier passage seulement · `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` · La première ligne annonce N actions ; Exit code: 0 doit clore le journal. · Une ligne STATUS: Finished par action faite : il en faut N. · bob_warnings.log : les Failed to find tile, à compter. · Au moindre doute : les autres journaux du dossier. · `bob_warnings.log` · `Failed to find tile for 'points …', …` · `Failed to find tile for 'points …', …` · `Failed to find valid quadtree node …` · chaque Failed to find tile est un trou dans le terrain : visez 0 · quadtree : un objet écarté, son pivot est hors de la carte · `bob_plugin_error.log` · `Couldn't create all processors,` · `check that BOB has been built.` · connu : il paraît à chaque passage lancé par Terry, sans effet sur le terrain · Exit code: 0 + N lignes STATUS: Finished · + 0 Failed to find tile = réussi · Carte de campagne : Exit code: 0, mais 6 actions sur 15 (le fichier Terry et 5 masques) : la limite du kit ; faites un témoin Extraits schématiques. Après chaque passage, dans binaries : bob.log (N actions annoncées, une ligne STATUS: Finished par action faite, Exit code: 0), puis bob_warnings.log. Les journaux ne gardent que le dernier passage. 1. Ouvrez `bob.log`. La première ligne dit combien d'actions ont été retenues ; la dernière doit dire `Exit code: 0`. 2. Comptez les lignes `(STATUS: Finished)` : une par action faite. Comparez au nombre de la première ligne, et à ce que vous attendiez. Un passage incomplet se voit là, même sans erreur. 3. Ouvrez `bob_warnings.log` et comptez les « Failed to find tile » : chacun est un trou dans le terrain. 4. Au moindre doute, ouvrez les autres journaux du même dossier. Un `Exit code: 0` ne suffit donc pas : comptez aussi les actions. ## Les messages à connaître Quatre messages reviennent souvent. La colonne « Où » dit dans quel journal les chercher : | Message | Où | Ce qu'il veut dire | Que faire | |---|---|---|---| | `Failed to find tile` | `bob_warnings.log` | Aucune tuile de la base de tuiles ne correspond au motif peint à cet endroit de `tile_map.png` : une route trop fine, une pointe de côte d'un seul hex… Résultat : un **trou** dans le terrain. | Corriger le motif dans `tile_map.png` ([le guide Terry](https://bretonia.dev/atelier/terry/)), faire un nouveau passage, recompter. Le but est zéro. | | `Failed to find valid quadtree node` | `bob_warnings.log` | Une entité (un objet posé, un plan d'eau…) a son **pivot** hors de la carte. BOB l'écarte : elle manque dans les fichiers compilés. | Ramener le pivot dans la carte, dans Terry, puis faire un nouveau passage. | | `Couldn't create all processors, check that BOB has been built.` | `bob_plugin_error.log` | Un processeur demandé manque au kit. | Rien, si le reste du passage va au bout : nous le voyons à chaque passage lancé par Terry, sans effet sur le terrain. | | `prefab root … does not have a valid TargetPath` | à vérifier | Le dossier `raw_data/art/prefabs/battle/` et sa règle `[Prefab]` ne font pas partie du passage. | Faire entrer ce dossier, avec sa règle, dans le passage. | Pour une carte de campagne, un « Failed to find tile » vient du motif peint dans `tile_map.png` : le schéma ci-dessous, repris du [guide Terry](https://bretonia.dev/atelier/terry/), montre ce que BOB accepte. *Schéma : Mer, côte, routes dans tile_map.png.* Dans le schéma : Mer, côte, routes · `tile_map.png : 1 hex = 2 × 2 pixels` · La mer · `sea · 83, 141, 213` · en jaune : la côte (voir dessous) · plan d'eau à 0, pivot dans la carte fond sous 0 partout, même sous la terre · La côte · une bande d'un hex ; chacun, · 1 à 3 voisins de mer d'un seul tenant · une pointe d'un hex : « Failed to find tile », un trou · `sea_coast · 255, 255, 0` · `cliff_gen · 253, 3, 1` · rivage (sea_coast) ou falaise (cliff_gen) : même règle. · par hex entiers : 0 échec ; tracée au pixel : 148 (notre carte) · Les routes · un bloc plein de 2 × 2 pixels par hex · un trait d'un pixel : des trous · Après chaque passage de BOB, comptez les « Failed to find tile » de bob_warnings.log : objectif 0. · Établi sur notre chantier et le projet de ChaosRobie ; CA ne le documente pas. Dans tile_map.png, chaque hex est un bloc de 2 × 2 pixels : la mer se déclare par sa couleur, la côte se peint en une bande d'un hex, les routes en blocs pleins. Tout écart donne des « Failed to find tile », donc des trous. Et l'absence de message en est un aussi : pour une carte de campagne que la base du jeu ne connaît pas, BOB ne lance que 6 actions sur 15, sans rien dire. Voir « BOB et une carte de campagne », plus bas. ## Pas à pas : trois travaux types *Schéma : Trois travaux types, et comment vérifier chacun.* Dans le schéma : Trois travaux types · Compiler une carte de bataille · dans Terry, sans ouvrir la fenêtre de BOB · `la tile map` · Passage 1 : Ctrl+P, puis rechargez-la · `bob.log` · À lire avant le passage suivant · `la tuile` · Map Properties : végétation legacy décochée ; passage 2 : Ctrl+P · `bob.log` · À lire aussitôt · Vérifier après chaque passage : Exit code: 0, autant de lignes STATUS: Finished que la première ligne annonce d'actions ; 0 « Failed to find tile » dans bob_warnings.log. · Exporter la base du kit · d'abord : Terry et le jeu fermés · `database → ` · Dans la fenêtre de BOB · `Start` · Tout passe au vert · `working_data/db/` · Un dossier par table · Vérifier : Exit code: 0 ; un dossier par table, avec son fichier data, à la date du passage (1 694 chez nous). · Bâtir un pack · deux voies · `RPFM` · La voie éprouvée · ou · `règle [Pack]` · ? · Non éprouvée dans Warhammer III · Vérifier : ouvrez-le dans RPFM ; terrain/battles// et la tuile, rien d'autre (ni la carte d'exemple, ni un .pack). Trois travaux types, et pour chacun la façon de vérifier : une carte de bataille (Terry lance BOB), l'export de la base (dans la fenêtre de BOB) et le pack (RPFM, la voie éprouvée ; la règle [Pack] de BOB n'est pas éprouvée dans Warhammer III). ### Compiler une carte de bataille La peinture, les zones et la création de la tile map sont dans [le guide Terry](https://bretonia.dev/atelier/terry/). Voici la part de BOB : 1. Enregistrez, puis **ouvrez la tile map** (le projet de `raw_data/terrain/battles//`) et lancez **File → Process with BOB**. Rechargez-la ensuite pour vérifier. 2. **Rouvrez la tuile.** Dans *Map Properties*, décochez la génération de végétation *legacy*, puis **Process with BOB**. 3. Retenez l'ordre : la tile map passe toujours avant la tuile. Ensuite, quand vous retouchez la tuile, seule la tuile se réexporte. 4. Mettez en pack avec RPFM, la voie éprouvée : `working_data/terrain` (sans la carte d'exemple du kit), une ligne dans `battles_tables` dont la `specification` vaut `terrain/battles//` (barre finale comprise), un texte et une image : voir [le guide Terry](https://bretonia.dev/atelier/terry/). 5. Posez le pack dans `data/` du jeu avec une vignette carrée du même nom, activez-le dans le lanceur, et testez par *Bataille personnalisée*. **Comment vérifier que ça a marché.** Après **chaque** passage, puisque les journaux ne gardent que le dernier : - `bob.log` finit par `Exit code: 0`, compte autant de lignes `(STATUS: Finished)` que sa première ligne annonce d'actions, et ses actions portent sur le projet que vous venez de traiter ; - `bob_warnings.log` ne compte aucun « Failed to find tile » ; - après le passage de la tile map, `working_data/terrain/battles//` contient `tile_map.bmd`, `tile_list.bin`, `lf_normal.dds`, `full_lf_logic_map.compressed_map` et `map_info.xml`, à la date du passage ; - en jeu, la carte apparaît dans *Bataille personnalisée*, et le terrain n'a pas de trou. ### Exporter la base du kit Pourquoi : vos tables éditées dans Dave sont des XML de `raw_data/db` ; l'export les écrit au format du jeu, un dossier par table dans `working_data/db/`. Cela sert quand un outil veut la base au format du jeu (chez nous, pour le startpos). Pour un mod, ce n'est pas ce qu'on empaquette : voir l'encadré ci-dessous. 1. Fermez Terry et le jeu. 2. Ouvrez BOB par le lanceur Steam (*Exporter: BOB*) ou par son exécutable (`bob.modder.x64.exe`, dans `binaries`). 3. Cochez le nœud `database` et choisissez `` : BOB ajoute de lui-même les dépendances, comme le nœud *Database Export*. 4. Cliquez sur Start, et attendez que tout soit vert. Chez nous : 3 788 actions en 109 secondes. **Comment vérifier que ça a marché.** `bob.log` finit par `Exit code: 0`, et `working_data/db/` contient un dossier par table, avec son fichier `data`, à la date du passage (1 694 chez nous). L'export écrit aussi, pour chaque campagne, des tables de départ (`start_pos_…`) dans `raw_data/EmpireDesignData/campaigns//` : ne soyez pas surpris de les y trouver. > **Exporter, oui ; tout empaqueter, non** : Une table exportée par le kit emporte **toutes** ses lignes, pas seulement celles que vous avez changées. Mise telle quelle dans un pack, elle nuit à la compatibilité avec les autres mods. Pour un mod, n'ajoutez que vos lignes, dans un fragment de table à votre nom : c'est le travail de RPFM ([le guide RPFM](https://bretonia.dev/atelier/rpfm/)). ### Bâtir un pack Deux voies mènent au pack, et le schéma du début de ce guide les montre côte à côte : - **RPFM**, la voie éprouvée. Vous créez le pack, et vous y ajoutez le dossier voulu de `working_data`. C'est la voie du tutoriel de carte de bataille du wiki tw-modding ([le guide RPFM](https://bretonia.dev/atelier/rpfm/)). - **La règle `[Pack]` de BOB**, non éprouvée dans Warhammer III. Un `rules.bob` avec `[Pack]` (voir les exemples plus haut) dit à BOB quels fichiers de `working_data` réunir, et dans quel pack ; une carte de bataille la demande dans ses deux dossiers. Nous ne savons pas quel nœud cocher pour que BOB bâtisse ce pack dans Warhammer III (dans le kit de Rome II, on cochait `mod.pack` dans l'arbre *retail* ; celui de Warhammer III, Retail Data, montre `assembly_kit` et `data`, et nous n'y avons rien lancé), et `` peut le faire atterrir dans le dossier `retail` du kit. **Comment vérifier que ça a marché.** BOB ne sait pas rouvrir un pack : ouvrez-le dans RPFM. Il doit contenir vos fichiers sous le chemin que le jeu attend (pour une carte de bataille, `terrain/battles//`, celui que cite `battles_tables`), et rien d'autre : ni la carte d'exemple du kit, ni un autre `.pack`. Vérifiez enfin qu'il est dans `data/` du jeu. ## BOB et une carte de campagne La documentation de CA prévient que le kit public ne prend en charge que la création de **tuiles de bataille**, et le kit de Warhammer III ne livre aucune donnée brute de terrain de campagne. La communauté a pourtant reconstitué un projet Terry **de type campagne** (ChaosRobie, pour *Immortal Empires Expanded*), et BOB a un module pour la campagne, `bob_campaign`. Le projet est décrit dans [le guide Terry](https://bretonia.dev/atelier/terry/), la moitié logique de la carte dans [le guide CAIME](https://bretonia.dev/atelier/caime/). ### L'ordre des passages Le tutoriel de carte de campagne du wiki tw-modding donne cet ordre, pour une carte que la base du jeu connaît (pour une carte neuve, voir « La limite », plus bas). BOB cherche le résultat des premières étapes dans votre pack, et il lit les packs du dossier `data` du jeu : d'où les allers-retours. 1. **Le relief** d'abord : les étapes suivantes en dépendent et le lisent dans votre pack. Mettez-le dans votre pack, dans `data` du jeu, puis fermez et rouvrez BOB. 2. **La tile map** : de nouveau dans le pack, puis fermez et rouvrez BOB. 3. **La global tile map** (routes et falaises), que BOB tire de la tile map de votre pack. 4. **`global_props.bin`**, les objets posés : à refaire chaque fois qu'une région est ajoutée ou retirée (BOB lit alors le `map.hex` de CAIME, qui doit être à jour avec la base) ; jusqu'à dix minutes, selon le tutoriel. Le projet de ChaosRobie range d'ailleurs ses objets par région, dans un calque `.layer` chacune. Depuis Terry, chaque *Process with BOB* démarre un nouveau BOB. *Schéma : Campagne : l'ordre des passages.* Dans le schéma : Campagne : l'ordre des passages · pour une carte que la base du jeu connaît · Carte inconnue de la base du jeu (celle des packs de CA) : BOB ne lance que 6 actions sur 15, sans message. Un témoin, puis la communauté. · Le relief · les étapes suivantes le lisent dans votre pack · `full_height_map.dds` · `full_logic_map.compressed_map` · Le relief dans votre pack, le pack dans le dossier data du jeu, puis fermer et rouvrir BOB · La tile map · `tile_list.bin` · `tile_mask.dds` · `patch_mask.dds` · La tile map dans votre pack, puis fermer et rouvrir BOB · La global tile map · routes et falaises, tirées de la tile map de votre pack · `global_map/tile_list.bin` · Les objets posés · BOB lit le map.hex de CAIME, à jour avec la base ; à refaire à chaque région ajoutée ou retirée ; jusqu'à dix minutes, selon le tutoriel · `global_props.bin` · Generate Camera Height Map : cette action fait planter BOB ; camera_heightmap.png se fabrique à part (le tutoriel : une approximation tirée du relief, mise à l'échelle). L'ordre du tutoriel de carte de campagne de tw-modding. BOB lit les packs du dossier data du jeu : après le relief, puis après la tile map, le pack y va, puis l'on ferme et rouvre BOB ; depuis Terry, chaque Process with BOB démarre un nouveau BOB. **Comment vérifier que ça a marché.** Dans `bob.log`, comparez le nombre d'actions de la première ligne aux lignes `(STATUS: Finished)`. Un passage complet sur un terrain de campagne compte 15 actions ; pour une carte que la base du jeu ne connaît pas, BOB n'en lance que 6 (voir plus bas). Puis comptez les « Failed to find tile » de `bob_warnings.log`, comme pour une bataille. ### Trois choses à savoir avant de compiler - **Terry a besoin d'un terrain déjà compilé** pour ouvrir un projet de campagne en 3D : sans lui, il plante à l'ouverture. Tant que rien n'est compilé, ouvrez le projet avec *3D View* décoché dans *Open…* - L'action *Generate Camera Height Map* **fait planter BOB** (le tutoriel le signale aussi). `camera_heightmap.png` et le masque de corruption se fabriquent à part. - **Une campagne a aussi besoin d'un terrain de bataille** : le dossier `terrain/battles//` que nomme la colonne `terrain_folder` de sa zone jouable de campagne. Sans lui, le jeu plante à la première bataille terrestre, même entre deux IA, donc souvent dès la première fin de tour. C'est une tile map de bataille, que BOB compile comme telle ; celle de CA porte aussi des lieux de bataille et des cartes de captage. *Schéma : Une campagne, deux terrains.* Dans le schéma : Une campagne, deux terrains · La zone jouable de campagne · `campaign_map_playable_areas` · `terrain_folder = ` · Le terrain de campagne · `terrain/campaigns//` · le relief, les tuiles et les objets de la carte · Le terrain de bataille · `terrain/battles//` · une tile map de bataille ; celle de CA porte aussi des lieux de bataille et des cartes de captage · Sans ce terrain de bataille : plantage à la première bataille terrestre, même entre deux IA, donc souvent dès la première fin de tour. Une carte de campagne a deux terrains : le sien, et un terrain de bataille, que nomme la colonne terrain_folder de sa zone jouable de campagne. ### La limite : une carte que la base du jeu ne connaît pas Un passage complet sur un terrain de campagne compte 15 actions (chez nous, environ une minute une fois le relief compressé, 25 minutes la première fois). Pour une carte que la base du jeu (celle des packs de CA) ne connaît pas, BOB n'en lance que 6, sans message ; l'ajouter à la base du kit ou à un pack de mod n'y change rien. Nous ne connaissons pas de voie officielle pour lever cette limite : faites un témoin, puis demandez à la communauté. Les 6 actions sont le fichier Terry et cinq masques : ni relief, ni textures, ni carte logique, ni brouillard. Et **aucun message** ne le signale : ni erreur, ni avertissement. *Schéma : Six actions seulement : le témoin.* Dans le schéma : Six actions seulement ? · Combien d'actions annonce bob.log ? · plus de 6 · Pas la limite · 15 chez nous pour un passage complet ; puis comptez les · Failed to find tile de bob_warnings.log · Faites un témoin · un projet connu pour bon, copié sous un autre nom, puis passé dans BOB · Et le témoin ? · plus de 6 · Votre projet · est en cause : cherchez dans vos fichiers · 6 aussi · Limite du kit · votre projet n'est pas en cause : demandez à la communauté · ne forcez pas l'outil · Les 6 actions d'une carte inconnue · le fichier Terry et cinq masques ; ni relief, ni textures, ni carte logique, ni brouillard ; et aucun message. Six actions au lieu de quinze, sans message : un témoin dit si c'est votre projet ou la limite du kit. Le **témoin**, avant de chercher dans vos fichiers : prenez un projet connu pour bon, copiez-le sous un autre nom, et faites-en un passage. S'il n'obtient lui aussi que 6 actions, votre projet n'est pas en cause. Si vous butez sur cette limite, parlez-en à la communauté (le Discord de l'équipe CAIME, le wiki tw-modding) plutôt que de chercher à forcer l'outil. ## Les pièges de BOB *Schéma : Les pièges de BOB, au fil d'un passage.* Dans le schéma : Les pièges, au fil d'un passage · En préparant · [Terrain] local sans PrefabRoot · recopiez-le, ou [+Terrain] · Le joker * s'arrête aux dossiers · commencez le filtre par ... · La tuile sans la règle [Pack] · la même règle dans les deux dossiers · Une table exportée, entière · vos lignes seules, avec RPFM · Une retouche à la main dans working_data · corrigez la source · En lançant BOB · -h, --help : « Illegal option format » · aucune option devinée · Terry ou le jeu ouverts · fermez-les avant Start · Un nœud coché, puis un clic ailleurs · choisissez une action · Une action seule · prenez · BOB gardé ouvert (campagne) · fermez et rouvrez-le · Une fenêtre introuvable · Alt+Tab, puis Windows + flèche du haut · En vérifiant · Des journaux écrasés · lisez-les après chaque passage · 6 actions sur 15, sans message · carte inconnue : un témoin · n'est pas forcément le jeu · cherchez aussi dans le kit · Un pack bâti par BOB · ouvrez-le dans RPFM Quinze pièges, rangés selon le moment où ils mordent : en préparant, en lançant BOB, en vérifiant. En rouge le piège, après la flèche verte sa parade. - **Des options devinées** (`-h`, `--help`) : une boîte « Illegal option format » bloque BOB et le script qui l'attend. Ne l'essayez pas non plus sur Terry ni sur Tweak. - **Un nœud coché, puis un clic ailleurs** : sélection annulée, sans message. - **Une action seule** peut ne rien produire (*Build Queried Campaign Tables*) : prenez ``. - **Terry ou le jeu ouverts** pendant un passage lancé depuis la fenêtre de BOB : Terry verrouille `working_data`. - **Un `[Terrain]` local** remplace celui du parent : recopiez `PrefabRoot`, ou écrivez `[+Terrain]`. - **Un joker** `*` ne traverse pas les dossiers : pour viser aussi les sous-dossiers, commencez le filtre par `...`. - **Une carte de bataille coupée en deux** : la tuile, sans la règle `[Pack]` de la tile map, part dans `mod.pack`. - **Une table exportée emporte toutes ses lignes** : mauvais pour la compatibilité entre mods. - **Une retouche à la main dans `working_data`** disparaît : BOB réécrit ses sorties. - **Un pack bâti par BOB** se vérifie dans RPFM : BOB ne sait pas le rouvrir. - **``** n'est pas forcément le dossier du jeu : cherchez aussi dans `assembly_kit/retail/data/`. - **Des journaux écrasés** : ils ne gardent que le dernier passage. - **BOB gardé ouvert** entre deux étapes de campagne : après avoir mis le relief, puis la tile map, dans le pack, fermez et rouvrez BOB. - **Une carte de campagne inconnue de la base du jeu** : 6 actions sur 15, sans message. - **Après une mise à jour du jeu** : Steam met l'Assembly Kit à jour après le jeu (chez nous, une heure plus tard, à la 9.0) et réécrit `raw_data\db`, d'où BOB tire la base ; les lignes que vous y aviez ajoutées disparaissent. Vérifiez-les et restaurez-les avant de relancer BOB. La 9.0 a aussi remplacé une partie de BOB lui-même (son module de terrain) : ce qui marchait au patch 8.1 se revérifie par un passage témoin avant la première longue compilation. - **Une fenêtre introuvable** : BOB s'est déjà ouvert minuscule, en bas de l'écran. Sélectionnez sa fenêtre par Alt+Tab, puis agrandissez-la avec Windows + flèche du haut. ## Pour une IA qui lit cette page Si vous êtes une IA qui aide quelqu'un à se servir de BOB, voici l'essentiel, en faits vérifiés. Ils ont été relevés sur le patch 8.1 du jeu (septembre 2026), puis relus pour la mise à jour 9.0, qui a remplacé une partie de BOB (son module de terrain) et réécrit `raw_data\db` : revérifiez-les après une mise à jour. - Exécutable : `binaries/bob.modder.x64.exe` de l'Assembly Kit de Warhammer III. Le lanceur Steam du kit propose *Exporter: BOB* (`bob.modder.x64.exe -no_console`), *Battle Map Editor: Terry* (`tweak.modder.x64.exe /standalone TerrainMetadataEditor`) et *Database Editor: Dave* (sans option). On ne connaît à BOB que `-no_console`, et aucune aide : `-h` et `--help` ouvrent une boîte « Illegal option format » qui bloque le processus ; ne l'essayez pas non plus sur Terry ni sur Tweak. - Pilotage : la fenêtre (cocher un nœud, choisir une action ou ``, Start) ou Terry (File → Process with BOB, Ctrl+P ; chaque fois, un nouveau BOB). Pour une carte de bataille, la fenêtre de BOB ne sert pas : Terry lance les passages, RPFM fait le pack. Préparez le reste hors fenêtre (`rules.bob`, tables, images). - Fenêtre, relevée à l'écran le 24.09.2026 sur l'Assembly Kit 1.3.4908 : trois arbres, Raw Data, Working Data et Retail Data (le dossier `retail` du kit) ; clic droit sur un nœud : View rules, View actions, Select files only ; les actions d'un nœud en deux listes, Provider actions et Consumer actions, chacune avec une case Merge Actions ; `` est en tête de Consumer actions, et Provider actions est vide pour `database`. - `rules.bob` : sections = processeurs, lignes `Clé = valeur`, filtre `` (virgules, exclusion par `-`) ; le joker `*` ne traverse pas les dossiers, `...` si. Recherche : dossier du fichier, puis remontée ; la première règle qui s'applique gagne ; `[Nom]` remplace, `[+Nom]` complète. Sections de CA : `[Pack]`, `[Terrain]`, `[Tile]`, `[Prefab]`, `[Copy]`, `[+AssetGraph]` ; le fichier de campagne de ChaosRobie ajoute `[Prop]`, `[Entity]`, `[Mesh]`, `[Texture]`. - Une carte de bataille occupe deux dossiers de `working_data`, la tile map et la tuile : la même règle `[Pack]` doit être posée dans chacun, sinon la tuile part dans `mod.pack`. - Packs : la voie éprouvée est RPFM. La voie `[Pack]` de BOB n'est pas éprouvée dans Warhammer III (nœud à cocher inconnu ; `` observé : `assembly_kit/retail/…`). Vérifiez où le pack est apparu, puis ouvrez-le dans RPFM. - Sorties : pour le terrain, même chemin que la source, sous `working_data`. Exceptions : l'export de la base écrit `working_data/db/
_tables/data`, et aussi des tables de départ par campagne dans `raw_data/EmpireDesignData/campaigns/` ; `[Copy]` et `[Pack]` écrivent sous ``. - Journaux : `binaries/bob.log` et ses voisins, dernier passage seulement. Première ligne de `bob.log` : `N action(s) were selected for execution.`, à comparer aux lignes `(STATUS: Finished)` ; dernière : `Exit code: 0`. « Failed to find tile » et « Failed to find valid quadtree node » sont dans `bob_warnings.log` ; « Couldn't create all processors… », dans `bob_plugin_error.log`, sans effet. Succès : `Exit code: 0` **et** le bon nombre d'actions **et** zéro « Failed to find tile ». - Avant de lancer BOB depuis sa fenêtre, ou d'enregistrer un pack dans `working_data`, fermez Terry et le jeu ; *Process with BOB*, lancé depuis Terry, n'est pas concerné. - Campagne : BOB lit les packs du dossier `data` du jeu. Ordre : le relief, mis dans le pack, puis fermer et rouvrir BOB ; la tile map, dans le pack, puis fermer et rouvrir BOB ; la global tile map ; `global_props.bin` (lit le `map.hex` de CAIME, à refaire à chaque région ajoutée ou retirée, jusqu'à dix minutes). *Generate Camera Height Map* fait planter BOB. - Limite : pour une carte que la base du jeu (celle des packs de CA) ne connaît pas, BOB ne lance que 6 actions sur 15, sans message ; l'ajouter à la base du kit ou à un pack de mod n'y change rien. Aucune voie officielle connue pour la lever : un témoin, puis la communauté. - Startpos : trois voies, *Build Startpos* de RPFM, l'action *Process start pos* de BOB, ou un `user.script.txt` écrit à la main ; chez nous, seule l'écriture à la main a marché ([le guide des outils](https://bretonia.dev/atelier/outils/)). - Pages de CA de 2016 : leur *Export Map* est devenu Process with BOB, puis un pack. - Demandez à l'humain avant de lancer le jeu, de piloter l'écran ou de publier ; ne supprimez rien : rangez, seul l'humain supprime. - Ni rétro-ingénierie ni contournement d'un outil de CA : quand un outil bute, un témoin, puis la communauté (Discord de CAIME, tw-modding). - Voir aussi : [le guide Terry](https://bretonia.dev/atelier/terry/), [le guide RPFM](https://bretonia.dev/atelier/rpfm/), [les outils du moddeur](https://bretonia.dev/atelier/outils/), [modder avec une IA](https://bretonia.dev/atelier/ia/). ## Sources et liens - Wiki de Creative Assembly : [Rules.bob](https://wiki.totalwar.com/w/Rules.bob_Documentation.html), [BoB (Attila)](https://wiki.totalwar.com/w/Total_War:_ATTILA_BoB.html) et [Terry, introduction](https://wiki.totalwar.com/w/TWW_Assembly_Kit_Terry_Intro). Les pages « TWW » datent du kit de Total War: WARHAMMER (2016) : certains libellés ont changé depuis. - Wiki tw-modding : [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) (partie Warhammer III de ChaosRobie : Process with BOB depuis Terry, ses messages), [Beginner's Guide](https://tw-modding.com/wiki/Tutorial:Beginner%27s_Guide) et [Localisation](https://tw-modding.com/wiki/Localisation). - Heaven Games : [le guide de l'Assembly Kit de Rome II](https://rome2.heavengames.com/cgi-bin/forums/display.cgi?action=ct&f=48,6,,30) (2014), pour la fenêtre et les packs. - Le kit de Warhammer III lui-même, relu sans rien y changer : ses `rules.bob`, la carte d'exemple, `documentation/pack/pack/compression.txt`, les journaux de `binaries` et les trois options de son lanceur Steam. La fenêtre de BOB (ses trois arbres, le menu du clic droit, la fenêtre des actions) a été relevée à l'écran le 24.09.2026 sur l'Assembly Kit 1.3.4908, sans rien lancer. - Nos autres guides : [Terry](https://bretonia.dev/atelier/terry/), [RPFM](https://bretonia.dev/atelier/rpfm/), [CAIME](https://bretonia.dev/atelier/caime/), [les outils du moddeur](https://bretonia.dev/atelier/outils/) et [modder avec une IA](https://bretonia.dev/atelier/ia/) ; et [l'atelier](https://bretonia.dev/atelier/). ## Questions fréquentes ### Qu'est-ce que BOB, dans l'Assembly Kit de Total War: Warhammer III ? Le bâtisseur du kit : il transforme les sources de `raw_data` (tables de la base, projets de terrain de Terry) en fichiers du jeu dans `working_data`, et sait les réunir en packs. Il s'ouvre par le lanceur Steam de l'Assembly Kit (Exporter: BOB), par son exécutable `bob.modder.x64.exe`, ou depuis Terry (File → Process with BOB, Ctrl+P), qui lui passe le travail. ### Faut-il ouvrir BOB pour une carte de bataille ? Non. Terry lance BOB lui-même (File → Process with BOB, Ctrl+P), sur la tile map puis sur la tuile, et RPFM fait le pack. La fenêtre de BOB sert surtout à exporter la base du kit. ### Où sont les journaux de BOB ? Dans le dossier `binaries` de l'Assembly Kit : `bob.log`, `bob_warnings.log`, `bob_error.log`, `bob_plugin_error.log`, `bob_startup_error.log` et `bob_db.log`. Ils ne gardent que le dernier passage. ### Comment savoir si un passage de BOB a réussi ? La première ligne de `bob.log` annonce le nombre d'actions retenues ; il doit y avoir autant de lignes `STATUS: Finished`, et le journal doit finir par `Exit code: 0`. `bob_warnings.log` ne doit compter aucun Failed to find tile, et les fichiers de sortie doivent porter la date du passage. Un pack se vérifie dans RPFM. ### J'ai coché un dossier et BOB n'a rien fait : pourquoi ? Un nœud ne reste coché que si une de ses actions l'est : cocher puis cliquer ailleurs annule la sélection sans message. Et une action seule peut ne rien produire ; choisissez , qui ajoute les dépendances. ### BOB s'est lancé mais je ne vois rien : que faire ? Lancé depuis Terry, BOB travaille en arrière-plan : ses messages s'affichent en bas à droite de Terry, et `bob.log` dit ce qu'il a fait. Ouvert par Steam ou par son exécutable, sa fenêtre s'est déjà ouverte minuscule, en bas de l'écran : sélectionnez-la par Alt+Tab, puis agrandissez-la avec Windows + flèche du haut. Si un script l'a lancé avec une option devinée, une boîte « Illegal option format » le bloque peut-être. ### Quelles options de ligne de commande BOB accepte-t-il ? On ne lui connaît que `-no_console`, celle que passe le lanceur Steam (Exporter: BOB). BOB n'a pas d'aide : `-h` et `--help` ouvrent une boîte « Illegal option format » qui le bloque. N'essayez pas d'options devinées, ni sur BOB, ni sur Terry, ni sur Tweak. ### Où BOB dépose-t-il le pack qu'il bâtit ? La règle `[Pack]` l'écrit dans `/data/`. Chez nous, `` a désigné un dossier `retail` à l'intérieur du kit (`assembly_kit/retail/`), comme dans le guide du kit de Rome II ; ce n'est pas confirmé pour un pack dans Warhammer III, où cette voie n'est pas éprouvée. Cherchez-le là, puis recopiez-le dans `data/` du jeu. La voie éprouvée reste RPFM. ### Mon pack ne contient que la tile map : pourquoi ? Une carte de bataille occupe deux dossiers de `working_data` : la tile map et la tuile (`terrain/tiles/battle///`). Si seule la tile map porte votre règle `[Pack]`, la tuile remonte jusqu'au `rules.bob` du sommet et part dans `mod.pack`. Posez la même règle dans le dossier de la tuile, ou faites le pack avec RPFM. ### Que veut dire « Failed to find tile » ? Qu'aucune tuile de la base de tuiles ne correspond au motif peint à cet endroit de `tile_map.png` (route trop fine, pointe de côte d'un seul hex…). Chaque occurrence, relevée dans `bob_warnings.log`, est un trou dans le terrain : corrigez le motif et faites un nouveau passage, jusqu'à zéro. ### Pourquoi BOB ne compile-t-il pas tout le terrain de ma carte de campagne neuve ? Pour une carte que la base du jeu (celle des packs de CA) ne connaît pas, BOB ne lance que 6 actions sur 15, sans message ; l'ajouter à la base du kit ou à un pack de mod n'y change rien. Nous ne connaissons pas de voie officielle pour lever cette limite : faites un témoin (un projet connu pour bon, copié sous un autre nom), puis demandez à la communauté. ### Faut-il fermer Terry avant de lancer BOB ? Avant de lancer BOB depuis sa fenêtre, ou d'enregistrer un pack dans `working_data`, fermez Terry et le jeu : Terry ouvert verrouille `working_data`. Process with BOB, lancé depuis Terry, n'est pas concerné.