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 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 : binaries (ses programmes), raw_data (ce que les outils lisent : tables en XML, terrain, cartes) et working_data (ce qu'ils produisent). Sauvegardez avant d'écrire dans raw_data\db : c'est la base que lisent CAIME et BOB.

• Dave édite les tables raw_data\db\*.xml ; elles s'écrivent aussi par script, sauvegarde d'abord.
• 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. En ligne de commande, on ne lui connaît que l'option -no_console, celle que passe le lanceur : 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.
• 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 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é. 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.

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é ce jour-là seulement ; 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. Trois voies y mènent : 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, faisait sortir le jeu en neuf secondes sans rien produire.

Le générer§

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

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

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 ci-dessous : une ligne mod par pack, la génération, la fermeture.
4. La génération : Steam ouvert et le jeu fermé, lancez directement l'exécutable du jeu (Warhammer3.exe ; chez nous, un fichier steam_appid.txt était posé à côté, comme le fait RPFM), puis attendez qu'il se referme seul, sans toucher à sa fenêtre.
5. 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.
6. 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.
7. Le ménage : remettez user.script.txt comme avant ; laissé tel quel, quit_after_campaign_processing; referme le jeu à chaque lancement.

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

• 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. Durée très variable : 16 s chez nous (400 × 440 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 annonce 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 la mise à jour 9.0 (septembre 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. 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 à huit de nos personnages, valeur que le jeu refuse dans un pack de mod ; nous avons remis celles du kit.
• Nos notes ne décrivent pas la recopie à la main, dans la fenêtre de RPFM, des lignes du kit vers ce pack. Pour créer un pack, y ajouter une table et y coller des lignes : 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.
• 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 à 1 (cm:is_new_game()). Avec un startpos plus ancien que les scripts, chaque partie neuve est prise pour une sauvegarde : ni introduction, ni missions.
• L'export Map Data de CAIME (MapDataBuilder, qui s'appuie sur une DLL du kit) a écrit chez nous un map_data.esf en variante ESF 0xABCB, alors que ceux que livre CA sont en 0xABCA ; la génération plantait tant qu'il n'était pas converti. Demandez à l'équipe de CAIME si votre version écrit déjà la bonne variante.
• 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.
• 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 aussi les tours du joueur par l'IA ; chez nous, elle ne recrute ni ne construit pour lui : ce mode éprouve 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 la mise à jour 9.0.

• À 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.
• Les fautifs, chez nous : une fois les erreurs des écouteurs attrapées et nommées au journal, trois écouteurs de CA sont apparus (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 (essai de trois tours, l'IA jouant tout). 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, n'a pas encore été vérifié en partie. Et un essai ne prouve un écouteur que par une ligne de journal écrite par cet écouteur.
• Chez nous, frontend.start_campaign (la fonction Lua de lancement du menu) refermait la campagne au bout de deux ou trois secondes : on lance par l'interface, comme un joueur.
• Au tour 1, la fin de tour ne passe qu'après avoir fermé une à une les notifications.
• 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. Chez nous, les plantages de rendu dont la caméra était relevée sont tous survenus caméra très haute, et aucun n'a été vu en jeu normal.
• 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 message.
• Personne ne touche au PC pendant l'essai : un clic humain le fausse.
• Toujours un témoin : un cas connu pour bon, rejoué à l'identique (même commande, options comprises), à côté du vôtre.
• Un plantage qui va et vient : au moins dix essais par variante avant de conclure ; d'ici là, dites « piste », pas « cause ».

Nos conseils d'atelier§

• Sauvegardez avant d'écrire dans raw_data\db : des copies horodatées. Une panne du premier soir n'a été résolue que parce qu'on pouvait comparer avec le dernier état qui marchait.
• Ne lancez jamais un outil avec des options devinées : cherchez-les dans la documentation, ou dans ce que son lanceur officiel lui passe (BOB : -no_console).
• 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 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.
• 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, puis relus pour la mise à jour 9.0 (septembre 2026) : 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 ; 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.
• 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 du tour 1 passées une à une ; caméra à hauteur de jeu ; personne ne touche au PC ; un témoin ; au moins dix essais par variante pour un plantage aléatoire.
• É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. Attrapez et nommez les erreurs des écouteurs ; un écouteur ne se prouve que par sa propre ligne de journal.
• Après une mise à jour du jeu : 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, 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.
• 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).

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