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§

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.

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.

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

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

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.

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

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.

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.

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 <All>, puis Start. 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. 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 :

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.

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 vont dans working_data/terrain/campaigns/<carte>/ et working_data/campaign_maps/<carte>/.

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

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

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, montre ce que BOB accepte.

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§

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 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/<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 : 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/<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 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 <retail> 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/<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.

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

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

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.

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§

• 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 <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 : BOB ne sait pas le rouvrir.
• <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.
• 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 <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 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 ; <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/ ; [Copy] et [Pack] écrivent sous <retail>.
• 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).
• 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, 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 sur l'Assembly Kit 1.3.4908, sans rien lancer.
• Nos autres guides : Terry, RPFM, CAIME, les outils du moddeur et modder avec une IA ; et l'atelier.

Questions fréquentes