Les outils du moddeur de campagne : vue d'ensemble, startpos, plantages et essais

La boîte à outils en un coup d'œil§

Une campagne passe par huit familles d'outils. Aucun ne fait tout, chacun a son domaine, et presque tous ont un piège. Les quatre premiers ont leur propre guide.

• CAIME (Campaign AI Map Editor)

  L'éditeur du Campaign Map Toolkit, pour la moitié logique de la carte : régions, sols, climats, routes, villes, et ses exports (Map Data, pathfinding, frontières).

  Le guide CAIME

• RPFM (Rusted PackFile Manager)

  Ouvrir, créer et modifier les packs : tables, textes, scripts, images ; ajouter une unité, une faction, un seigneur ; se laisser piloter par une IA (serveur MCP).

  Le guide RPFM

• Terry

  L'éditeur de terrain en 3D de l'Assembly Kit : relief, textures, végétation, objets, zones logiques.

  Le guide Terry

• BOB

  Le bâtisseur de l'Assembly Kit : il transforme les sources en fichiers du jeu et en packs, selon des fichiers rules.bob.

  Le guide BOB

• Dave et Tweak

  Dave (CA l'écrit « DaVE » : DaVE.retail.x64.exe ; le lanceur Steam dit Database Editor: Dave) édite les tables en XML de l'Assembly Kit (la base que lisent CAIME et BOB) ; Tweak est l'éditeur dont Terry est un mode.

  Steam → Bibliothèque → Outils

• Un langage de script

  Python chez nous : tout ce qui se répète, déclarer des tables, produire des couches, contrôler un pack, lancer des essais.

• WinDbg (cdb)

  Lire les vidages de plantage du jeu. cdb.exe est dans le sous-dossier amd64 du paquet, hors du PATH.

  winget install Microsoft.WinDbg --scope user

• Les journaux du jeu

  Savoir ce que le jeu a vraiment fait : chargement, scripts, données refusées.

  Voir « Quand le jeu plante », plus bas

Les mots du métier§

Les mots propres à la carte (hex, couche, swatch, lookup…) sont dans le guide CAIME.

Qui fait quoi, de la base au jeu§

Toute la chaîne d'une carte neuve, avec l'outil de chaque étape et les fichiers qu'elle produit :

• La base : les tables de l'Assembly Kit (Dave, ou les XML par script), ou celles d'un pack (RPFM).
• La moitié logique : CAIME, puis ses exports : le guide CAIME.
• La moitié visuelle, en même temps : Terry, puis BOB : Terry, BOB. Le mur d'une carte neuve est là : pour une carte que la base du jeu ne connaît pas, BOB ne lance que 6 actions au lieu d'une douzaine, et nous ne connaissons pas de voie officielle pour aller plus loin ; notre méthode, hors des voies officielles et assumée comme telle : BOB lancé sous débogueur (« Le terrain d'une carte de campagne en bref », plus bas).
• Le pack : RPFM rassemble tout : le guide RPFM.
• Le tour 0 : le jeu lui-même génère le startpos à partir de ce pack (plus bas) ; les fichiers qu'il produit retournent dans le pack, qu'on reconstruit.

L'Assembly Kit en bref§

L'Assembly Kit est le kit officiel de Creative Assembly (Steam → Bibliothèque → Outils). Trois dossiers comptent : binaries (ses programmes), raw_data (ce que les outils lisent : tables en XML, terrain, cartes) et working_data (ce qu'ils produisent) ; à côté, dave (Dave) et documentation. Sauvegardez avant d'écrire dans raw_data\db (des copies horodatées) : c'est la base que lisent CAIME et BOB.

• Dave édite les tables raw_data\db\*.xml ; elles s'écrivent aussi par script.
• Tweak (binaries\tweak.modder.x64.exe) est l'éditeur de CA. Pendant les exports Map Data et Dynamic Resources de CAIME, Tweak et Terry doivent être fermés (Terry est un mode de Tweak). Ne comptez pas sur l'alerte de CAIME : elle cherche un programme nommé Tweak.AssemblyKit, alors que celui du kit de Warhammer III s'appelle tweak.modder.x64.exe.
• Terry, un mode de Tweak : la page de CA, écrite pour le kit de Warhammer I, le présente comme l'outil des cartes de campagne et des champs de bataille, et précise que le kit ne permet de créer que des tuiles de bataille ; nous constatons la même chose dans le kit de Warhammer III, dont le dossier raw_data\terrain ne contient que la bataille. Ouvert, Terry verrouille working_data : le guide Terry.
• BOB transforme les sources en fichiers du jeu et en packs, selon des fichiers rules.bob. 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. BOB n'a pas d'aide en ligne de commande ; on connaît deux commandes officielles, celles de ses lanceurs (encadré ci-dessous) : le guide BOB.

RPFM et les packs en bref§

Un mod de Total War est un fichier .pack : une archive de tables, de textes (.loc), de scripts Lua, d'images et de modèles. RPFM ouvre ceux du jeu en lecture et fabrique les vôtres ; depuis la version 5, son serveur MCP permet à une IA de le piloter. Tout est dans le guide RPFM, avec trois procédures complètes : ajouter une unité, une faction, un seigneur légendaire.

• N'écrasez pas une table du jeu : donnez à vos fragments un nom à vous. Quand deux fragments donnent la même clé, le jeu garde celui dont le nom trie en premier ; un fragment nommé comme le fichier du jeu (data__) le remplace tout entier.
• Ne redéfinissez pas un texte du jeu : les .loc d'un mod valent pour toutes les langues. Pour une seconde langue, chez nous : un second pack qui ne contient que son .loc, sous le même chemin, et qui passe devant (! en tête de son nom).
• Dans data, un pack passe devant les fichiers en vrac : un fichier régénéré (un startpos) ne compte qu'une fois remis dans le pack.

Le terrain d'une carte de campagne en bref§

Ni le kit de Warhammer III ni celui de Warhammer I ne livrent de données brutes de terrain de campagne. Terry sait pourtant ouvrir un projet de type campagne : ChaosRobie l'a prouvé. Pour Immortal Empires Expanded, un mod qu'il a fait avec l'équipe de CAIME, il a reconstitué la carte des Empires Immortels en projet Terry, et il a partagé ce projet avec la communauté. Le dossier du projet, la taille de ses rasters, ses conventions et ses limites sont dans le guide Terry ; l'ordre des passages de BOB dans le guide BOB.

Un passage complet qui aboutit sur un terrain de campagne compte 12 actions (15 si camera_heightmap.png est demandé, et l'action ajoutée fait planter BOB ; 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é. Le témoin : un projet connu pour bon, copié sous un autre nom ; s'il s'arrête aussi à 6 actions, vos fichiers ne sont pas en cause.

Notre méthode, assumée : nos cartes neuves ont obtenu leurs 12 actions par un outil à nous, hors des voies officielles. Il lance BOB avec la commande exacte que Terry lui passe, sous le débogueur cdb, et lui fournit les limites de la carte que sa base ne connaît pas ; rien n'est modifié sur disque en dehors des sorties normales de BOB. C'est la seule voie que nous connaissions pour le terrain d'une carte neuve ; nous la disons franchement, et le détail est dans le guide BOB.

La position de départ (startpos)§

Le startpos (startpos.esf) est la sauvegarde du tour 0 : factions, régions, personnages, armées, diplomatie. Chaque campagne n'a qu'un fichier de départ, et un mod ne peut pas le compléter : il le remplace en entier (« there can be only one startpos », dit le wiki du modding). Deux mods qui touchent au startpos d'une même campagne ne se combinent donc pas.

On écrit les tables start_pos_* dans l'Assembly Kit (Dave), mais le jeu ne lit pas ses XML. Pour la génération, on les lui sert dans un pack à part, chargé seulement le temps de la génération ; elles n'entrent jamais dans le pack que l'on joue. Seuls les fichiers générés y vont.

C'est le jeu lui-même qui fabrique le startpos, dans un mode spécial piloté par le fichier %APPDATA%\The Creative Assembly\Warhammer3\scripts\user.script.txt, qu'il lit au lancement. Le nôtre, pour une carte neuve : une ligne mod par pack, la génération, les données de l'IA, puis la fermeture du jeu.

mod mon_mod.pack;
mod mes_tables_de_depart.pack;
process_campaign_startpos ma_campagne;
process_campaign_ai_map_data;
quit_after_campaign_processing;

Trois voies mènent à ce mode : 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é. RPFM (clic droit sur la racine du pack → Build Startpos) écrit lui-même le user.script.txt de la génération, mais n'y met qu'une ligne mod : celle du pack ouvert. Notre génération lit deux packs (le mod et celui des tables de départ) : nous écrivons donc le script à la main. Une ligne add_working_directory, que nous avions essayée pour la génération, faisait sortir le jeu en neuf secondes sans rien produire ; pour jouer, elle charge pourtant bien un mod : c'est la génération qu'elle casse.

Le générer§

En bref, les cinq temps de la génération :

1. Les tables de départ

   Les tables start_pos_*, au format du jeu, dans un pack de génération ; à côté, le pack du mod, à jour.

   piège : le jeu ne lit pas les XML du kit

2. Le script du jeu

   user.script.txt charge les packs et demande la génération, puis la fermeture du jeu.

   piège : à remettre comme avant, ensuite

3. Le jeu, en mode spécial

   Il crée le monde de la campagne, l'enregistre, puis se referme. Steam doit tourner.

   piège : refermé ne veut pas dire réussi : vérifiez la date du fichier

4. Le tour 0

   Le startpos, et, pour une carte neuve, les données de cheminement de l'IA, écrits en vrac dans data.

   startpos.esf, hlp_data.esf, spd_data.esf

5. Dans le pack

   Les trois fichiers rejoignent le pack du mod, qu'on reconstruit.

   piège : le pack passe devant les fichiers en vrac

Pas à pas, comme nous le faisons ; l'ordre compte : le pack du mod d'abord, puis la génération, puis le pack reconstruit.

1. Le pack du mod, construit et posé dans le dossier data du jeu, à jour (scripts compris) : la génération lit ses tables (campaigns, la carte…) et fait tourner ses scripts.
2. Le pack de génération, posé lui aussi dans data : il contient les tables start_pos_* (voir « Le pack de génération », plus bas).
3. Le script : gardez une copie de user.script.txt s'il existe, puis écrivez-y les lignes données plus haut : une ligne mod par pack, la génération, la fermeture.
4. Le dossier des données de l'IA, pour une carte neuve : créez le dossier vide <jeu>\data\campaign_maps\<carte>\ avant de lancer le jeu. Sans lui, ni hlp_data.esf ni spd_data.esf ne sont écrits, sans message, et la campagne plante au réglage du joueur. Build Startpos de RPFM le crée seul.
5. La génération : Steam ouvert et le jeu fermé, lancez directement l'exécutable du jeu (Warhammer3.exe), puis attendez qu'il se referme seul, sans toucher à sa fenêtre. Chez nous, un fichier steam_appid.txt qui contient 1142710 (le numéro Steam du jeu), posé à côté de l'exécutable, évite que le jeu lancé directement repasse par Steam ; RPFM, lui, lance le jeu par Steam.
6. Les fichiers produits : le jeu écrit <jeu>\data\campaigns\<campagne>\startpos.esf ; avec process_campaign_ai_map_data, chez nous, hlp_data.esf et spd_data.esf dans <jeu>\data\campaign_maps\<carte>\. Vérifiez leur date et leur heure.
7. Le pack reconstruit : copiez ces fichiers dans les sources du mod, reconstruisez le pack, puis retirez les copies en vrac de data : le pack passe devant elles.
8. Le ménage : remettez user.script.txt comme avant ; laissé tel quel, quit_after_campaign_processing; referme le jeu à chaque lancement. Rangez aussi le pack de génération hors de data jusqu'à la prochaine génération : sinon il apparaît dans le lanceur, où l'on pourrait le cocher.

• process_campaign_startpos ne prend qu'un argument, la clé de la campagne.
• Avec process_campaign_ai_map_data, le jeu écrit aussi les données de cheminement de l'IA (hlp_data.esf, spd_data.esf), indispensables à une carte neuve : sans elles, le jeu plante au réglage du joueur. Le jeu ne les écrit que si le dossier <jeu>\data\campaign_maps\<carte>\ existe déjà. Durée très variable : de 16 à 22 s chez nous (400 × 440 et 560 × 905 hex) ; le tutoriel de carte de campagne de tw-modding compte moins d'une minute pour spd, environ cinq minutes pour hlp sur une carte moyenne et bien plus d'une heure sur une grande ; RPFM compte de 10 à 30 minutes.
• À notre connaissance, ces commandes ne sont pas documentées publiquement : nous les avons vérifiées sur le patch 8.1 du jeu, puis avec les mises à jour 9.0 et 9.0.2 (septembre et octobre 2026). Revérifiez-les après une mise à jour.
• Charger un mod : pour jouer, on coche le mod dans le lanceur ; pour générer un startpos à la main, une ligne mod <pack>; par pack dans user.script.txt. Lancé directement, l'exécutable ne charge que les packs ainsi nommés.
• Les trois fichiers vont dans le pack : campaigns/<campagne>/startpos.esf, campaign_maps/<carte>/hlp_data.esf et campaign_maps/<carte>/spd_data.esf.
• Avec RPFM (clic droit sur la racine du pack → Build Startpos) : le pack doit être dans le dossier data, la campagne déclarée dans le pack (campaigns_tables), et le jeu fermé ; tout ce que lit la génération doit être dans ce seul pack. Par son serveur MCP, build_starpos répond « Success » en zéro seconde : cela veut dire « jeu lancé », pas « startpos construit » ; attendez que le jeu se referme, puis appelez build_starpos_post et build_starpos_cleanup. Avec RPFM 5.1 ou plus, une session MCP inactive 5 minutes est fermée : pendant une génération longue, envoyez une commande légère toutes les 2 à 3 minutes (list_open_packs) ou rouvrez le pack avant build_starpos_post (déduit du code de RPFM, pas encore essayé). Le détail : le guide RPFM.

Le pack de génération§

C'est un pack de mod ordinaire, créé avec RPFM, qui ne sert qu'à la génération. Il contient les tables start_pos_* au format du jeu : des tables de pack, pas les XML du kit. Chez nous, la ligne campaigns de la campagne et les autres tables que lit la génération restent dans le pack du mod, chargé en même temps ; avec Build Startpos de RPFM, qui ne charge qu'un pack, tout doit être dans celui-là.

• Chez nous, il a été construit une fois à partir des tables de départ que l'export de la base par BOB écrit, au format du jeu, pour chaque campagne (raw_data\EmpireDesignData\campaigns\<campagne>\), sans les XML ni campaigns (le guide BOB décrit cet export). Ensuite, chaque ligne ajoutée au kit y a été recopiée par script, à travers le serveur MCP de RPFM.
• Relisez ce que BOB écrit : il avait mis default comme sous-type à certains de nos personnages, valeur que le jeu refuse dans un pack de mod ; nous avons remis celles du kit.
• À la main, dans la fenêtre de RPFM : créer un pack, y ajouter une table et y coller des lignes, dans le guide RPFM.
• Contrôle avant de lancer le jeu : chaque valeur qui renvoie à une autre table (une faction, un sous-type, un groupe d'IA) doit y exister. Sinon, le validateur du jeu nomme l'enregistrement fautif (encadré plus bas).

Ce qu'un startpos exige : les plantages que nous avons vécus§

• Chaque colonie a un emplacement primary (start_pos_region_slot_templates) : sans lui, le startpos se génère quand même, et le jeu plante au chargement.
• Chaque faction a un groupe d'IA qui contient une personnalité : sinon, plantage.
• Sans start_pos_starting_general_options, aucun seigneur n'est choisissable à l'écran de sélection.
• Dans start_pos_regions, rebel_faction_name et long_description restent vides : un texte (le « PLACEHOLDER » du kit) fait planter la création du monde, sans vidage ni rapport de plantage : le journal s'arrête juste après le chargement des mods.
• Le modèle d'emplacement se prend chez CA, pour la sous-culture du maître : le trio d'une colonie (modèle primary de start_pos_region_slot_templates, primary_building, port_building) existe tel quel chez CA pour la même sous-culture ; jamais un modèle *_port sur une région sans port. Sinon la génération passe, et le chargement plante (9.0.2). Une région qui change de maître prend modèles ET bâtiments dans la culture du nouveau maître.
• Une faction que CA fait partir en horde, sans région, ne reçoit pas de colonie au départ : même plantage au chargement (9.0.2).
• Une colonie portuaire garde 16 + 3 hex (16 principaux, 3 de port) : en 19 + 3, ou en 16 + 1 et 16 + 2, le chargement plante alors que CAIME valide la carte (le guide CAIME, « Les villes »).
• campaigns.mask reste vide, comme dans toutes les campagnes du kit : un masque non vide fait planter la génération (9.0.2). Copiez une ligne campaigns qui marche, champ par champ.
• L'aperçu de la carte à l'écran de sélection (preview_width × preview_height de campaign_map_playable_areas) a le rapport du monde, hauteur 600 (CA : 750 × 600) ; sinon la carte y paraît déformée. Régénérez le startpos après tout changement de cette ligne.
• Jamais de table *_ownership_content_pack_junctions pour une clé à vous (faction, zone jouable, bataille…) : le jeu se ferme en 9 à 13 s, sans rapport ni mp_log (constaté à la génération du startpos, 9.0.2). Un verrou de DLC se fait par script.
• Un personnage de départ placé en (0, 0) rejoint en garnison la colonie que lui donne start_pos_character_to_settlements ; sans ce lien, il apparaît dans le coin de la carte, en case (1, 1).
• Une campagne scriptée se génère APRÈS ses scripts : c'est pendant la génération que les scripts passent le compteur de sauvegarde (__save_counter) de 0 à 1 ; cm:is_new_game() le lit. Avec un startpos plus ancien que les scripts, chaque partie neuve est prise pour une sauvegarde : ni introduction, ni missions, et le script_log écrit « reconstructing markers and listeners from saved data ». Si vos scripts plantent pendant la génération, le compteur reste aussi à 0 : relisez le script_log de la génération (constaté sur le patch 8.1, le 23.09.2026).
• Contrôle avant le jeu : comparez la structure du nouveau startpos à celle d'un startpos qui charge (mêmes blocs, mêmes enfants).

Quand le jeu plante : lire les indices§

Cinq questions, dans l'ordre ; chaque « oui » dit quel fichier ouvrir :

• %APPDATA%\The Creative Assembly\Warhammer3\crash_report\bad_mods_report.txt : les données refusées. Dans le même dossier, les vidages .mdmp ; le *.stack.txt ne dit presque rien, le vidage, si.
• %APPDATA%\The Creative Assembly\Warhammer3\logs\mp_log.txt : où en était le chargement (base lue, somme de contrôle, création de l'environnement de campagne).
• Le journal des scripts : un fichier script/enable_console_logging non vide dans un pack chargé, et le jeu écrit script_log_JJMMAA_HHMM.txt dans son dossier (vide, le fichier est ignoré). Les clics, même simulés, y sont notés avec le chemin du composant.
• Le vidage au débogueur : installez WinDbg (winget install Microsoft.WinDbg --scope user). cdb.exe n'est pas dans le PATH : PowerShell donne le dossier du paquet par (Get-AppxPackage Microsoft.WinDbg*).InstallLocation, et cdb.exe est dans son sous-dossier amd64. Puis, dans PowerShell, $cdb = "<dossier>\amd64\cdb.exe" (<dossier> : ce dossier du paquet), et & $cdb -z <vidage.mdmp> -c ".ecxr; k 40; q". Sans .ecxr, vous regardez le fil du rapporteur de plantage, pas le fil fautif.
• Lire le verdict : le code 0xC0000005 avec une lecture à une adresse nulle ou presque nulle, c'est un pointeur nul : souvent, pas toujours, une donnée attendue manque. Cherchez d'abord dans vos tables ce que le jeu n'a pas trouvé.
• Rangez les plantages par cas testé et par adresse : l'adresse dépend de la campagne et de la version du jeu ; notez la version du jeu à côté de chaque adresse. Après une mise à jour, les anciennes adresses ne se comparent plus.
• Un plantage qui va et vient : jugez sur une série. Chez nous (mise à jour 9.0, 25.09.2026), le jeu plantait au rendu de la carte, au hasard, jusque dans une partie normale, et le serveur de RPFM (rpfm_server, version 5.0.6) gardait la mémoire de chaque pack construit : près de 70 Go après une nuit ; le serveur relancé, trois essais sont passés. Ce n'était pas la cause : le même plantage est revenu sur un PC redémarré, serveur éteint. Trois essais réussis ne prouvent rien : au moins dix par variante. La cause désignée depuis (jeu en 9.0.2) : des montagnes et des falaises posées en objets avec le matériau 49 des tuiles de terrain, alors que CA n'emploie que les matériaux 68, 86 ou 97 pour ses montagnes en objets ; une piste encourageante, pas encore une preuve (le guide Terry).
• La fuite de mémoire de rpfm_server est réelle (5.0.6 : chaque connexion MCP crée une session jamais libérée, de 2 à 10 Go ; la 5.1.0 la corrige) : relancer le serveur avant un essai reste une bonne hygiène. Mesurez sa mémoire privée ((Get-Process rpfm_server).PrivateMemorySize64, ou « Mémoire validée »), pas la mémoire de travail : chez nous, 91 Mo de mémoire de travail pour 9,4 Go de mémoire privée. Au-delà de 8 Go, relancez-le.
• Le jeu se ferme en quelques secondes sans rien écrire (ni rapport, ni mp_log) : une table *_ownership_content_pack_junctions pour une clé à vous ? Retirez-la. Sinon, retirez une table à la fois, sur une copie du pack, jusqu'à trouver la fautive.
• Steam doit être lancé : sinon le jeu se referme en quelques secondes, et l'on croit à un plantage.

Tester sans jouer : les parties automatiques§

Pour savoir si une campagne tient trente tours, inutile de les jouer. Notre méthode :

• Un pack d'essai séparé (créé pour l'essai, retiré après) contient un script Lua qui clique dans l'interface comme un joueur : menu, campagne, seigneur, début de partie, fin de tour. Les composants se désignent par leur chemin dans l'interface.
• all_players_ai; dans user.script.txt fait passer les tours du joueur, mais sa faction ne joue pas (chez nous : aucune recrue, aucun bâtiment) : ce mode éprouve les autres factions et la stabilité, pas la faction du joueur. À notre connaissance, cette commande n'est pas documentée publiquement : vérifiée sur le patch 8.1 et les mises à jour 9.0 et 9.0.2.

• À la fin : bilan des tours, relecture du script_log, des vidages s'il y en a. Puis user.script.txt remis comme avant et le pack d'essai retiré, même après un arrêt forcé.
• Les limites : en mode « l'IA joue tout », aucune mission n'est émise pour une IA. Ce mode teste la stabilité (IA, invasions, dilemmes) ; l'histoire et les mécaniques d'un seigneur se testent en mode joueur.
• Un évènement qui n'arrive jamais : sur notre carte, FactionTurnStart n'arrivait à aucun script, sous all_players_ai comme en mode joueur, alors que FactionBeginTurnPhaseNormal arrivait à chaque tour. La cause : dans le jeu publié, les conditions de tous les écouteurs d'un évènement sont évaluées dans une seule boucle, sans protection ; une condition qui plante annule l'évènement pour tous les scripts, ceux de CA comme les vôtres, sans rien écrire au journal. Un rappel qui plante fait de même (mise à jour 9.0).
• Attraper ces erreurs : chez nous, une version protégée de la méthode core:event_callback de la bibliothèque de CA, qui nomme au journal chaque écouteur fautif, une fois. La variable evt_callback de cette bibliothèque est locale à son fichier : la remplacer depuis un autre script n'a aucun effet. Et un essai ne prouve un écouteur que par une ligne de journal écrite par cet écouteur.
• Les fautifs, chez nous : trois écouteurs de CA (wh3_campaign_bonus_values.lua), deux de Mère Ostankya et un de Yuan Bo, dont la condition plantait à chaque début de tour : ils attendent des systèmes de Kislev et de Cathay que notre campagne ne charge pas. Leurs erreurs attrapées, l'évènement est revenu.
• Le remède retenu : retirer ces écouteurs par leur nom au démarrage de la campagne (core:remove_listener), plutôt que créer des variables factices. Vérifié depuis dans trois parties automatiques de trois tours, l'IA jouant tout (25.09.2026, mise à jour 9.0) : écouteurs retirés, FactionTurnStart reçu à chaque tour ; pas encore en mode joueur.
• Le menu, en détail : la liste des seigneurs ne montre que ceux de la race choisie (campaign_select_new > culture_list) ; l'écran s'ouvre sur la dernière campagne choisie ; un script de menu ne lance qu'une fois par session (chez nous, un drapeau gardé par core:svr_save_bool), sinon, revenu au menu, il relance en boucle. Nos clics passent par find_uicomponent, GetProperty et SimulateLClick, relancés toutes les deux secondes par core:get_tm():real_callback.
• La fin de tour ne passe qu'après avoir fermé une à une les notifications : à chaque tour en mode joueur, au tour 1 seulement sous all_players_ai (les tours suivants se jouent seuls).
• La caméra à hauteur de jeu, posée sur le chef dès le premier tour : un essai doit reproduire ce que vit un joueur. Au patch 8.1, tous nos plantages de rendu dont la hauteur de caméra était notée au journal sont survenus caméra très haute (la carte entière à l'écran). En 9.0, un plantage de rendu est aussi arrivé en partie normale ; la mémoire de la machine, d'abord soupçonnée, n'en était pas la cause (« Quand le jeu plante », plus haut).
• Un script d'essai qui doit se charger à coup sûr va dans script\campaign\mod\, sous un nom qu'aucun autre fichier ne charge déjà : un fichier déjà chargé est sauté, sans erreur. Le script_log du menu est écrasé si la campagne démarre dans la même minute (même nom de fichier) : donnez au menu un journal à lui.

Nos conseils d'atelier§

• Quand un outil de CA ne fait rien sans erreur, la condition est quelque part : le témoin d'abord, puis les journaux ; si rien ne parle, demandez à la communauté (Discord de CAIME, tw-modding).
• Un validateur rouge est un avis, pas une réponse : les cartes de CA échouent elles-mêmes à certains contrôles. C'est le jeu qui tranche.
• Prenez une photo avant chaque mise à jour du jeu (versions des fichiers, tables utiles) pour comparer après.
• Après une mise à jour du jeu, ne construisez rien avant d'avoir vérifié raw_data\db : Steam met l'Assembly Kit à jour après le jeu (à la 9.0, une heure plus tard chez nous) et, à chaque mise à jour du jeu ou du kit (9.0 le 24.09, 9.0.2 le 27.09), réécrit raw_data\db ; toutes les lignes que vous y aviez ajoutées disparaissent (chez nous, le terrain, working_data et les packs n'ont pas été touchés). Gardez une copie de vos tables à la fin de chaque séance qui y écrit (une copie « avant écriture » ne contient pas la dernière écriture) et des scripts qu'on peut rejouer sans dommage ; restaurez vos lignes, puis mettez à jour les schémas de RPFM et régénérez son cache des dépendances.
• Après une restauration du kit, comptez avant de construire : une restauration qui ne prend que la copie la plus récente de chaque table peut en oublier ; comptez chaque lot contre sa source, comparez les tables start_pos_* au pack de génération AVANT toute synchronisation qui supprime (lignes du pack absentes du kit : 0 attendu ; chez nous, 19 lignes de départ ne vivaient plus que dans ce pack), et repassez les retouches faites hors des scripts.
• Jugez en jeu, face à une référence : les chiffres d'un audit ne voient pas ce que voit le joueur.

Pour une IA qui lit cette page§

Si vous êtes une IA qui aide quelqu'un à générer un startpos, lire un plantage ou lancer des parties d'essai dans Total War: Warhammer III, voici l'essentiel, vérifié sur un vrai chantier. Ces faits ont été relevés sur le patch 8.1 du jeu, relus pour la mise à jour 9.0 (septembre 2026), puis corrigés le 5 octobre 2026 des faits prouvés en 9.0.2 : revérifiez-les après une mise à jour.

• Demandez à l'humain avant de lancer le jeu, de piloter l'écran ou de publier ; ne supprimez rien : rangez, seul l'humain supprime.
• Startpos : c'est le jeu qui le génère. Dans %APPDATA%\The Creative Assembly\Warhammer3\scripts\user.script.txt (gardez-en d'abord une copie) : une ligne mod <pack>; par pack posé dans data, puis process_campaign_startpos <campagne>; (un seul argument), process_campaign_ai_map_data; pour une carte neuve, et quit_after_campaign_processing;. Steam lancé, Warhammer3.exe lancé directement ; attendez que le jeu se referme ; remettez ensuite le fichier comme avant. Sortie : <jeu>\data\campaigns\<campagne>\startpos.esf.
• Par le serveur MCP de RPFM : build_starpos répond « Success » dès que le jeu est lancé. Attendez que le jeu se ferme, puis appelez build_starpos_post (il range startpos.esf dans le pack et remet user.script.txt), puis build_starpos_cleanup ; sans build_starpos_post, quit_after_campaign_processing; reste et referme le jeu à chaque lancement. RPFM n'écrit qu'une ligne mod, celle du pack ouvert : tout ce que lit la génération doit y être.
• Les tables start_pos_* s'écrivent dans le kit, mais le jeu ne lit pas ses XML : servez-les dans un pack de génération, jamais dans le pack joué. %APPDATA%\The Creative Assembly\Warhammer3\crash_report\bad_mods_report.txt nomme l'enregistrement refusé, un à la fois.
• Trois fichiers vont dans le pack : campaigns/<campagne>/startpos.esf, campaign_maps/<carte>/hlp_data.esf et campaign_maps/<carte>/spd_data.esf. Un pack passe devant les fichiers en vrac : reconstruisez-le, puis retirez les copies en vrac de data.
• Campagne scriptée : générez le startpos après les scripts (compteur de sauvegarde à 1), sinon ni introduction ni missions.
• Exigences : un emplacement primary par colonie, dont le trio (modèle, primary_building, port_building) existe tel quel chez CA pour la sous-culture du maître ; aucune colonie au départ pour une faction que CA fait partir en horde ; ports en 16 + 3 ; un groupe d'IA avec une personnalité par faction ; start_pos_starting_general_options pour l'écran de sélection ; rebel_faction_name et long_description vides dans start_pos_regions ; campaigns.mask vide ; aucune table *_ownership_content_pack_junctions pour une clé à vous ; pour une carte neuve, <jeu>\data\campaign_maps\<carte>\ créé avant la génération.
• Plantage : suivez l'arbre du diagnostic ; 0xC0000005 avec une lecture à l'adresse 0 veut souvent dire, pas toujours, qu'une donnée attendue manque ; l'adresse dépend de la campagne et de la version du jeu.
• Parties d'essai : un pack d'essai séparé, retiré après (et, après tout arrêt forcé, user.script.txt nettoyé) ; lancement par l'interface ; notifications passées une à une (à chaque tour en mode joueur, au tour 1 sous all_players_ai) ; caméra à hauteur de jeu ; personne ne touche au PC ; un témoin ; au moins dix essais par variante pour un plantage aléatoire.
• Plantage intermittent : jugez sur une série (au moins dix essais par variante), jamais sur trois réussites. La fuite de mémoire de rpfm_server (5.0.6, corrigée en 5.1.0) est réelle, mais n'était pas la cause de notre plantage de rendu ; mesurez sa mémoire privée et relancez-le au-delà de 8 Go. Cause désignée (9.0.2, piste, pas une preuve) : montagnes posées en objets au matériau 49 des tuiles.
• Jeu qui se ferme sans rien écrire : pensez aux angles morts de bad_mods_report.txt (jonction de propriété de DLC sur une clé à vous, campaigns.mask non vide) ; retirez une table à la fois sur une copie du pack.
• Évènement de script jamais reçu : une condition d'écouteur qui plante l'annule pour tous les scripts, sans journal. Chez nous, FactionTurnStart manquait en mode joueur comme sous all_players_ai, à cause de trois écouteurs de CA (Mère Ostankya, Yuan Bo) chargés sans leurs systèmes ; retirés par leur nom au démarrage de la campagne, l'évènement arrive à chaque tour (vérifié sous all_players_ai, 9.0). Attrapez et nommez les erreurs des écouteurs ; un écouteur ne se prouve que par sa propre ligne de journal.
• Après chaque mise à jour du jeu ou du kit (9.0, puis 9.0.2) : Steam met l'Assembly Kit à jour plus tard et réécrit raw_data\db, lignes ajoutées perdues ; vérifiez-le avant toute construction, restaurez les lignes, comptez chaque lot contre sa source, comparez les start_pos_* au pack de génération avant toute synchronisation qui supprime, puis schémas de RPFM et cache des dépendances.
• Jamais d'options devinées (BOB, Terry, Tweak) ; une sauvegarde avant d'écrire dans raw_data\db ; un validateur rouge est un avis, c'est le jeu qui tranche.
• 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, dite franchement dans le guide BOB : BOB lancé sous débogueur pour le terrain d'une carte neuve. Quand un outil bute, un témoin, puis la communauté (Discord de CAIME, tw-modding).

Sources et liens§

• Manuel de RPFM et RPFM For Dummies (wiki tw-modding).
• Campaign Map Making for Warhammer III et Startpos (wiki tw-modding).
• Documentation des scripts, tenue par Vandy.
• Terry, introduction (écrite pour le kit de Warhammer I) et Rules.bob (wiki de Creative Assembly).
• Documentation de CAIME.
• Nos guides : CAIME, RPFM, Terry, BOB, modder avec une IA.

Questions fréquentes