BOB, le guide : compiler le terrain et bâtir des packs avec l'Assembly Kit de Total War: Warhammer III

Ce que fait BOB§

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 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.

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.

Le vocabulaire§

Ouvrir BOB et lui donner du travail§

L'Assembly Kit s'installe par Steam (Bibliothèque → Outils). Sur une installation Steam, il est dans <Steam>/steamapps/common/Total War WARHAMMER III/assembly_kit/ ; BOB et ses journaux sont dans son dossier binaries. Le jeu, lui, lit les packs dans <Steam>/steamapps/common/Total War WARHAMMER III/data/.

BOB s'ouvre de trois façons : 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). Ouvert par Steam ou par son exécutable, BOB montre sa fenêtre et attend qu'on lui choisisse du travail (voir « La fenêtre de BOB », juste après). Ouvert par Terry, il travaille en arrière-plan, et ses messages s'affichent en bas à droite de Terry.

Depuis Terry§

• Dans Terry : File → Process with BOB (Ctrl+P), ou le bouton en globe avec une flèche vers la droite. C'est la voie des tutoriels pour le terrain.
• Terry écrit ce qu'il demande (processeurs, dossiers, sorties voulues) dans un fichier de configuration, binaries/BOB/_terry_auto_configuration.xml, puis lance BOB en arrière-plan avec ce fichier (voir « La ligne de commande », plus bas). 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).
• Inutile de fermer Terry : c'est lui qui lance BOB. Enregistrez d'abord votre projet.
• Les tutoriels disent souvent « exporter » une carte : dans Warhammer III, c'est Process with BOB, puis le pack (voir « Bâtir un pack », plus bas).

Comment vérifier que ça a marché. Suivez les messages jusqu'à la fin, puis lisez bob.log : voir « Les journaux de BOB », plus bas.

Depuis la fenêtre de BOB§

Cochez le nœud, choisissez l'action ou <All>, puis Start : le détail est dans « La fenêtre de BOB », juste après. Trois usages types :

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 (les packs qu'on y pose, notamment). Process with BOB, lancé depuis Terry, n'est pas concerné. Cette règle vaut pour tout le guide.

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 pas d'aide en ligne de commande ; on connaît deux commandes officielles, celles de ses lanceurs : -no_console (lanceur Steam) et celle que Terry lui passe. Le lanceur Steam du kit propose trois options :

Terry, lui, lance BOB avec une commande plus longue (relevée le 21.09.2026, patch 8.1) :

BOB.modder.x64.exe /dont_stop_on_error /nosplashscreen /get_latest_rules -no_console /offline /configuration:_terry_auto /workspace: "/changelist:Terry (<chemin du projet>.terry)"

/configuration:_terry_auto désigne le fichier binaries/BOB/_terry_auto_configuration.xml, que Terry écrit : c'est lui qui dit à BOB quoi bâtir (processeurs, dossiers, sorties voulues). La ligne de commande ne sert donc pas qu'à ouvrir BOB : avec /configuration:, elle lui donne aussi son travail.

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.

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).

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.

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 <All>, en tête de Consumer actions, pour les prendre toutes. Avec <All>, 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.

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.

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 :

Pour une campagne, les sorties de BOB vont dans working_data/terrain/campaigns/<carte>/ (relief, carte logique, tuiles, masques, global_map/). Le dossier working_data/campaign_maps/<carte>/ reçoit les fichiers de CAIME, camera_heightmap.png, que BOB ne sait pas faire (voir « BOB et une carte de campagne », plus bas), et la liste des arbres que BOB y écrit (action Campaign Trees : display/trees/trees.campaign_tree_list) : mettez-la dans votre pack, sinon la carte n'a pas d'arbres.

Trois exceptions à la règle du même chemin :

• L'export de la base écrit un dossier par table, working_data/db/<table>_tables/, avec un fichier data dedans ; et aussi, pour chaque campagne, des tables de départ (start_pos_…) et un .pack, dans raw_data/EmpireDesignData/campaigns/<campagne>/, donc dans raw_data.
• Une règle [Copy] écrit sous <retail> : chez nous, dans le dossier assembly_kit/retail/… du kit.
• Une règle [Pack] écrit son pack sous <retail>/data/ : voir « Le mot <retail> », plus bas.

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 : voir « Depuis la fenêtre de BOB », plus haut.

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.

Lire un passage en trois minutes§

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: : il en faut une par action annoncée. Finished : faite. FinishedWithWarnings : faite, mais lisez bob_warnings.log. Failed : ratée ; le passage finit alors par Exit code: 1, et bob_error.log dit pourquoi. DependencyFailed : pas faite, parce qu'une action dont elle dépend a échoué ; cherchez la première Failed. Comparez aussi au nombre 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 (sauf sur la dernière rangée du terrain de bataille d'une campagne, hors de la grille et sans effet : 1 chez nous pour la Saison, 3 pour Expanded).
4. Au moindre doute, ouvrez les autres journaux du même dossier.

Un Exit code: 0 ne suffit donc pas : comptez aussi les actions. Nous avons relevé les trois premiers statuts le 22.09.2026, au patch 8.1, et DependencyFailed le 03.10.2026, au patch 9.0.2.

Les messages à connaître§

Cinq messages reviennent souvent. La colonne « Où » dit dans quel journal les chercher :

Pour une carte de campagne, un « Failed to find tile » signale un motif de l'export CAIME que BOB ne peut pas associer à une tuile. Corrigez les couches dans CAIME, puis réexportez ; ne retouchez pas tile_map.png à la main (seule exception : jusqu'à CAIME 1.0.1, l'image sort à l'envers et se retourne verticalement ; depuis la 1.1.0, elle sort nord en haut). Motifs connus sans tuile : une côte sur la rangée 0, la dernière rangée ou la dernière colonne de la grille ; un isthme d'un hex où deux falaises se croisent ; et les bouts de falaise (cliff_gen_ends) que CAIME pose autour de chaque plage : liés à la plage, ils laissent un trou côté falaise (la carte des Empires de CA n'en a que 36 pour 412 plages ; sur notre carte Saison Expanded, nous les repeignons en cliff_gen, un écart assumé). Le schéma vient du guide Terry.

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 au lieu d'une douzaine, sans rien dire. Voir « BOB et une carte de campagne », plus bas.

Pas à pas : trois travaux types§

Compiler une carte de bataille§

La peinture, les zones et la création de la tile map sont dans le guide Terry. Voici la part de BOB.

1. Enregistrez, puis ouvrez la tile map (le projet de raw_data/terrain/battles/<carte>/) 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/<carte>/ (barre finale comprise), un texte et une image : voir le guide 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 une ligne STATUS: Finished par action annoncée en première ligne (pour FinishedWithWarnings et Failed, voir « Les journaux de BOB »), 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/<carte>/ 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 <All> : 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 (20.09.2026, patch 8.1) : 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, le 20.09.2026, patch 8.1). L'export écrit aussi, pour chaque campagne, des tables de départ (start_pos_…) et un .pack dans raw_data/EmpireDesignData/campaigns/<campagne>/ : ne soyez pas surpris de les y trouver.

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).
• La règle [Pack] de BOB, non éprouvée dans Warhammer III. Un rules.bob avec [Pack] (voir « Les rules.bob du kit, ligne à ligne », plus bas) 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 <retail> peut le faire atterrir dans le dossier retail du kit.

Comment vérifier que ça a marché. Ouvrez le pack dans RPFM, qui montre ce qu'il contient. Il doit contenir vos fichiers sous le chemin que le jeu attend (pour une carte de bataille, terrain/battles/<carte>/, 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.

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.

Pour une carte de bataille faite dans Terry, vous n'avez pas à en écrire : le tutoriel de tw-modding n'en fait écrire aucun, ceux du kit suffisent. Cette section sert à comprendre ce que fait BOB, et à écrire vos propres règles.

La syntaxe§

• Chaque [Section] désigne un processeur ; en dessous, une ligne par réglage : Clé = valeur.
• La clé <Files> 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 (voir plus bas).
• 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 :

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.

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.

Les rules.bob du kit, ligne à ligne§

Rien ne vaut des règles réelles. Les quatre premiers fichiers sont livrés par CA dans le kit ; le dernier est un modèle, calqué sur la carte d'exemple, pour la voie [Pack], non éprouvée dans Warhammer III. Chaque bloc se recopie tel quel ; les notes numérotées dessous l'expliquent ligne à ligne.

Premier fichier : working_data/rules.bob§

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

1. <Files> = -*.pack : tous les fichiers, sauf les packs ; le signe - exclut.
2. PackFile : le pack à bâtir. Pour le mot <retail>, 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 : 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.

Troisième fichier : raw_data/terrain/tiles/battle/rules.bob§

[Tile]
    <Files> = ...*.terry, ..._settings.xml
    TileDatabaseType = battle
    PrefabRoot = art/prefabs/battle

1. <Files> : les projets .terry et les fichiers _settings.xml de tous les sous-dossiers, grâce aux trois points.
2. TileDatabaseType = battle : le type de la base de tuiles, ici celle des batailles.
3. PrefabRoot : le même dossier de prefabs que la règle [Terrain] du deuxième fichier.

Quatrième fichier : raw_data/art/prefabs/battle/rules.bob§

[Prefab]
    <Files> = ...*.terry
    TargetPath = prefabs
    RootFolder = true

1. <Files> = ...*.terry : les prefabs sont des projets .terry, dans tous les sous-dossiers.
2. TargetPath : c'est la clé que réclame le message « prefab root … does not have a valid TargetPath » (voir « Les messages à connaître »), quand ce dossier manque au passage.
3. RootFolder = true : gardez-le tel que CA le donne.
4. Pour des prefabs de campagne, le tutoriel Custom Campaign Settlement Skins fait poser la même règle dans raw_data/art/prefabs/campaign/rules.bob, avec TargetPath = prefabs/campaign.

Un modèle : 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 = <retail>/data/ma_carte.pack
    PackType = mod

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. La compression (non essayée) : la documentation du kit (documentation/pack/pack/compression.txt) décrit deux clés à ajouter à un [Pack], Compressed = true et CompressionType = LZ4 (ou ZSTD). Elle 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). Nous ne l'avons pas essayée.

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.

Le mot <retail> : ce que nous savons, et ce que nous ne savons pas§

Les règles de pack écrivent PackFile = <retail>/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 <retail>/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). Sur notre disque, le 25.09.2026, assembly_kit/retail/ ne contenait pourtant que assembly_kit/.

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.

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, la moitié logique de la carte dans le guide 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 faut le fermer et le rouvrir pour qu'il le voie : d'où les allers-retours. Le tutoriel ne dit pas où poser ce pack ; chez nous, BOB monte tous les packs de <jeu>\data (mods compris) et ceux de assembly_kit\working_data. Un BOB en cours tient ouverts les packs de <jeu>\data : les remplacer échoue (WinError 32) tant qu'il n'a pas fini. Attention : ce pack lui donne des fichiers ; pour savoir si la carte existe, BOB ne consulte que la base des packs de CA (voir « La limite »).

1. Le relief d'abord : les étapes suivantes en dépendent et le lisent dans votre pack. Mettez-le dans votre pack, 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.

« Fermer et rouvrir BOB » vaut pour sa fenêtre. Depuis Terry, rien à faire : 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:. Chez nous, un passage complet de campagne qui aboutit compte 12 actions : Terry file, Color Overlay, Color Overlay (Sea), Snow Mask, Campaign Shroud Heights, Patch Visibility Mask, Tilemap, Campaign Global Blendmap, Corruption Mask, Global Tilemap, Campaign Heightmap et Campaign Trees (bob.log du 25.09.2026, patch 9.0 ; même compte le 04.10.2026, patch 9.0.2, code 0). Le premier essai, le 21.09.2026, en retenait 15, dont Initialise warscape et Generate Camera Height Map, qui fait planter BOB (voir ci-dessous). Pour une carte que la base du jeu ne connaît pas, BOB n'en lance que 6 (voir « La limite »). Puis comptez les « Failed to find tile » de bob_warnings.log, comme pour une bataille.

Ce que les actions lourdes (Tilemap, Global Tilemap, Campaign Global Blendmap, Campaign Shroud Heights, Campaign Heightmap) ont écrit dans working_data/terrain/campaigns/<carte>/ lors de notre premier passage complet (21.09.2026, patch 8.1) : full_height_map.dds (le relief compilé), full_logic_map.compressed_map (la carte logique), tile_map.tiles, tile_list.bin, tile_mask.dds, patch_mask.dds, shroud_heights.dds, et dans global_map/ : global_blend.dds, texture_arrays.xml et tile_list.bin ; en plus des cinq masques. Campaign Trees écrit la liste des arbres dans working_data/campaign_maps/<carte>/display/trees/. Un fichier absent ou plus ancien que le passage : l'action qui l'écrit n'a pas tourné.

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…
• Chez nous, l'action Generate Camera Height Map fait planter BOB (le tutoriel dit que Terry plante en la produisant). camera_heightmap.png se fabrique donc à part (le tutoriel : une approximation tirée du relief, mise à l'échelle, avec le bloc tEXt du PNG réglé).
• Une campagne a aussi besoin d'un terrain de bataille : le dossier terrain/battles/<dossier>/ 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.

Ce que BOB ne fait pas, ou réécrit, pour une campagne§

• Pas de lf_normal.dds (l'éclairage lointain du relief) : BOB n'en produit pas pour une campagne (constaté le 21.09.2026, patch 8.1). Il se fabrique à part (le tutoriel le fait exporter de Terry en .bmp, puis convertir par BOB : non essayé chez nous) ; dans tous les cas, il suit le relief et a la taille de full_height_map.dds.
• Les arbres écrêtés : Campaign Trees ne place aucun arbre au-delà de z = world_width × 2/√3 (world_width : l'attribut du .terry, voir le guide Terry). Sur une carte plus profonde que cela, les arbres se tassent sur une rangée (54 027 sur une seule rangée pour notre carte Saison Expanded) : contrôlez la liste d'arbres après chaque passage.
• Pas de camera_heightmap.png : voir ci-dessus. Il se range dans working_data/campaign_maps/<carte>/, à côté des fichiers de CAIME.
• Le brouillard (shroud_heights.dds) : il suit le calque HeightShroud du projet (Fill from terrain dans Terry, selon le tutoriel) ; pour notre carte, BOB l'a écrit plat, à 1,0 partout (22.09.2026, patch 8.1). Nous le recalculons après chaque passage.
• La liste des textures du sol et la collection d'éclairage (environment_collection.xml) : BOB les écrit d'après le projet Terry (pour l'éclairage, d'après ses zones, les entités ECEnvironmentVolume) et les réécrit à chaque passage. Une retouche faite dans working_data disparaît : mettez-la dans le projet, ou refaites-la par script après chaque passage. Deux pièges : la liste des textures (global_map/texture_arrays.xml) cite toujours les 144 groupes de Warhammer III, pas les textures de votre projet, et un groupe que le catalogue de variantes (.assetdb) ne déclare pas prend la dernière texture (sol gris) ; sans aucune zone EnvironmentVolume, BOB n'écrit pas environment_collection.xml, et la carte n'a pas d'éclairage.
• Le masque de corruption, lui, BOB le compile depuis le calque CorruptionMask du projet (action Corruption Mask de nos passages).

La limite : une carte que la base du jeu ne connaît pas§

Le 21.09.2026 (patch 8.1), notre premier passage complet de campagne a duré environ 25 minutes, surtout pour compresser le relief, avant de planter sur Generate Camera Height Map ; le soir même, un passage complet, relief compris, prenait moins d'une minute. Nos passages suivants ont duré de 15 secondes à 2 minutes (All actions took de bob.log), 42 secondes le 25.09.2026 au patch 9.0, pour 12 actions. 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 Terry file, qui écrit les objets posés (global_props.bin, global_props_sound.bin), et cinq masques : ni relief, ni tuiles, ni textures, ni carte logique, ni brouillard (chez nous, les objets seuls prennent de 11 à 24 secondes, pas dix minutes). Et aucun message ne le signale : ni erreur, ni avertissement.

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).

Les pièges de BOB§

• Des options devinées (-h, --help, -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.
• Une ligne mod <pack>; dans binaries/bob_project.script.txt ou binaries/project.script.txt : BOB lit ces fichiers s'ils existent, et cette ligne le fait planter au démarrage (21.09.2026, patch 8.1). Retirez-la avant de lancer BOB.
• 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 <All>.
• 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, qui montre ce qu'il contient.
• <retail> 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.
• Une action Failed ou FinishedWithWarnings : comptez les lignes STATUS: de bob.log, pas seulement Exit code: 0.
• BOB gardé ouvert entre deux étapes de campagne, quand vous travaillez depuis sa fenêtre : après avoir mis le relief, puis la tile map, dans le pack, fermez et rouvrez BOB. Depuis Terry, rien à faire.
• Une carte de campagne inconnue de la base du jeu : 6 actions au lieu d'une douzaine, 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. Chaque mise à jour peut aussi remplacer BOB et Terry : la 9.0 l'a fait (exécutable et tous les modules de BOB), puis la 9.0.2 (binaires datés du 01.10.2026, nouvelle empreinte du module de terrain). Comptez vos lignes, puis faites un passage témoin avant la première longue compilation (kit 9.0.2 : passage de terrain revérifié le 04.10.2026, 12 actions, code 0).
• Un pack de data à remplacer pendant un passage : BOB tient ouverts les packs de <jeu>\data ; le remplacement échoue (WinError 32). Attendez la fin du passage.
• 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é BOB (son exécutable et tous ses modules) et réécrit raw_data\db ; la 9.0.2 les a de nouveau remplacés, et un passage de terrain y a été revérifié le 04.10.2026 (12 actions, code 0) : revérifiez-les après une mise à jour.

• Exécutable : binaries/bob.modder.x64.exe de l'Assembly Kit de Warhammer III (Steam : <Steam>/steamapps/common/Total War WARHAMMER III/assembly_kit/). 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). Terry lance BOB avec /dont_stop_on_error /nosplashscreen /get_latest_rules -no_console /offline /configuration:_terry_auto /workspace: "/changelist:Terry (<projet>.terry)" ; le fichier binaries/BOB/_terry_auto_configuration.xml dit quoi bâtir (relevé au patch 8.1). BOB n'a pas d'aide : -h, --help et -help ouvrent une boîte « Illegal option format » qui bloque le processus ; n'essayez aucune autre option, ni sur Terry ni sur Tweak. Une ligne mod <pack>; dans binaries/bob_project.script.txt ou project.script.txt fait planter BOB au démarrage.
• Pilotage : la fenêtre (cocher un nœud, choisir une action ou <All>, 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 : 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 ; <All> est en tête de Consumer actions, et Provider actions est vide pour database.
• rules.bob : sections = processeurs, lignes Clé = valeur, filtre <Files> (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 ; <retail> 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/<table>_tables/data, et aussi des tables de départ par campagne dans raw_data/EmpireDesignData/campaigns/ (avec un .pack par campagne) ; [Copy] et [Pack] écrivent sous <retail>. Campagne : working_data/terrain/campaigns/<carte>/ ; working_data/campaign_maps/ reçoit CAIME, camera_heightmap.png et, de BOB, la liste des arbres (display/trees/trees.campaign_tree_list, à mettre dans le pack).
• 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, FinishedWithWarnings, Failed ou DependencyFailed) ; dernière : Exit code: 0, ou Exit code: 1 si une action a échoué (bob_error.log dit pourquoi ; un raster .tif qui n'a pas la taille déclarée y donne « Wrong size, expecting W×H »). « 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 : ordre du tutoriel de tw-modding : le relief, mis dans votre 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. Un passage complet qui aboutit compte 12 actions chez nous. BOB ne produit pas lf_normal.dds pour une campagne, écrit le brouillard plat pour une carte neuve, et réécrit à chaque passage la liste des textures du sol et environment_collection.xml d'après le projet Terry (pas d'EnvironmentVolume, pas de collection ; un groupe de sol non déclaré dans un .assetdb prend la dernière texture). Campaign Trees n'écrit aucun arbre au-delà de z = world_width × 2/√3, et écrit la liste des arbres dans working_data/campaign_maps/<carte>/display/trees/. Un BOB en cours tient les packs de <jeu>\data ouverts (WinError 32).
• Limite : pour une carte que la base du jeu (celle des packs de CA) ne connaît pas, BOB ne lance que 6 actions au lieu d'une douzaine (les objets posés et cinq masques), 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é. Notre méthode, hors des voies officielles et assumée : BOB lancé sous débogueur, la commande de Terry, un enregistrement fourni avec les minx et maxx du kit quand la recherche de la carte échoue ; empreinte de la DLL vérifiée à chaque version.
• 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).
• Export de la base : il réécrit le sous-type de certains personnages en default dans les tables de départ, clé refusée par le validateur de mods de Warhammer III ; pour un mod, seulement vos lignes, avec RPFM.
• Les tutoriels disent « exporter » une carte : dans Warhammer III, c'est 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.
• Lire et documenter un format de fichier, comme le font RPFM et CAIME : oui. Modifier les programmes de CA ou contourner leurs limites : non, avec une exception assumée de l'atelier : BOB lancé sous débogueur pour le terrain d'une carte neuve (ci-dessus). Quand un outil bute, un témoin, puis la communauté (Discord de CAIME, tw-modding).
• Voir aussi : le guide Terry, le guide RPFM, les outils du moddeur, modder avec une IA.

Sources et liens§

• Wiki de Creative Assembly : Rules.bob, BoB (Attila) et Terry, introduction. Les pages « TWW » datent du kit de Total War: WARHAMMER (2016) : certains libellés ont changé depuis.
• Wiki tw-modding : Map Making for WH3 (WakaWaka300), Campaign Map Making for Warhammer III, Custom Campaign Settlement Skins (partie Warhammer III de ChaosRobie : Process with BOB depuis Terry, ses messages), Beginner's Guide et Localisation.
• Heaven Games : le guide de l'Assembly Kit de Rome II (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, sans rien lancer. Les bob.log de nos passages (21 au 25.09.2026), et la comparaison des fichiers du kit avant et après la mise à jour 9.0.
• Nos autres guides : Terry, RPFM, CAIME, les outils du moddeur et modder avec une IA ; et l'atelier.

Questions fréquentes