Adopter une mission Foothold sur la chaîne v6 (la « moulinette »)¶

Foothold est une mission communautaire (par Lekaa) qui évolue plusieurs fois par mois. Ce guide décrit la moulinette : une procédure reproductible que n'importe quel membre VEAF peut relancer à chaque nouvelle version upstream, pour produire les .miz VEAF (Modern et Cold-War) depuis un seul dossier de mission.

Architecture : code générique, connaissance auteur en donnée (voir ADR 0007) et config amont intacte + override partiel validé lexicalement (voir ADR 0008). Le détail de chaque commande est dans CONVERT_OTHER et la référence mission.yaml.

Prérequis¶

veaf-tools (ou veaf-tools.exe) à jour.
L'archive de release Foothold de la carte visée (p. ex. Caucasus) — voir ci-dessous.
Le profil de conversion foothold (livré avec les outils).

Où récupérer l'upstream¶

Foothold est publié sur GitHub : leka1986/Lekas-Foothold, onglet Releases. Une release fournit un .zip par carte (Caucasus, Persian Gulf, Sinaï, Syrie, Cold War Germany, Kola, Irak, Afghanistan, Normandie WWII), chacun contenant :

Fichier	Ce qu'on en fait
`Foothold_<carte>_<version>.miz`	c'est l'entrée de la moulinette
`Foothold Config Manager <version>.exe`	ignoré — voir la mise en garde
`Foothold_Manual_v<x>.pdf`	documentation amont, utile à lire
`Getting Started.url`	raccourci vidéo

Passez le .zip directement à convert-other : il adopte le .miz qu'il contient et ignore le reste. Pas besoin de dézipper à la main.

Les neuf cartes d'un coup. Une release contient une archive par carte. Depuis un clone du dépôt, tools/Convert-FootholdBatch.ps1 les adopte toutes en une passe, en choisissant le bon profil pour chacune (il regarde dans l'archive, pas son nom) :
.\tools\Convert-FootholdBatch.ps1 -InputFolder <dossier-des-zips> -OutputFolder <dossier-missions> -Validate
Aux releases suivantes, ajoutez -Update : les scripts sont rafraîchis et chaque mission.yaml réglé est préservé. Comptez environ une minute par mission.

Vos dossiers de mission n'ont pas besoin de porter le nom des archives : le script apparie chaque archive au dossier de la même carte (il lit le théâtre des deux côtés), donc Foothold_CA_4.7.0_Multi_Language….zip rafraîchit bien VEAF-Foothold-Caucasus. Il annonce pour chaque mission le dossier retenu et pourquoi.

Seuls comptent les dossiers adoptés par convert-other (ceux qui ont un convert-other-state.yaml) : le dossier de sortie peut donc contenir d'autres missions sur les mêmes cartes, comme les Open Training. Exception : Sinaï et Sinaï Nord sont deux missions Foothold sur la même carte. Copiez leurs archives sous le nom de leur dossier (VEAF-Foothold-Sinai.zip, VEAF-Foothold-SinaiNorth.zip) : un dossier qui porte le nom de l'archive passe en premier. De même pour toutes les cartes lors de la première mise à jour d'une mission adoptée avant l'apparition de convert-other-state.yaml.

Quel profil pour quelle carte¶

Carte	Profil
Caucasus, Persian Gulf, Sinaï, Syrie, Cold War Germany, Kola, Irak, Afghanistan	`foothold`
Normandie WWII	`foothold-ww2`

La Normandie est une autre famille, d'où son profil : son fichier de config s'appelle Foothold Config WW2.lua, il n'a pas de global Era (la Seconde Guerre mondiale n'a pas de sélecteur d'ère) ni de StartNormal, et la mission n'embarque aucune CTLD Foothold — la CTLD VEAF n'y est donc pas incompatible (elle reste OFF par défaut, mais vous pouvez l'activer).

Si vous adoptez la Normandie avec le profil foothold, validate vous arrête : le config_override viserait Foothold Config.lua, absent de cette mission, et l'override serait alors chargé en dernier — après le script de setup qui a déjà lu les réglages — donc sans aucun effet.

Vue d'ensemble¶

.zip release   ──(1) convert-other --profile foothold──►  dossier mission v6
                                                          │
                              (2) réglage mission.yaml ◄──┘
                                                          │
                          (3) validate  ──►  (4) build  ──►  <base>_MODERN.miz
                                                              <base>_COLD_WAR.miz
                                                          │
                                          (5) test DCS ◄──┘

Nouvelle version Lekaa ──► convert-other --update ──► (re)validate ──► build

1. Initialiser (adopter)¶

veaf-tools convert other Foothold_CA_4.4.1_Multi_Language_Coldwar-Modern-Vietnam.zip <dossier-mission> --profile foothold

convert-other extrait le .miz (de l'archive si besoin), détecte les scripts chargés par les triggers natifs (dans l'ordre), et génère un mission.yaml avec :

un bloc custom_scripts: ordonné (Moose, zoneCommander, Foothold Config, setup, CTLD Foothold, Splash, AIEN, EWRS… — l'ordre de chargement d'origine), délais compris : Lekaa ne charge pas tout d'un bloc — 5 scripts arrivent 3 secondes après les premiers, et AIEN 12 secondes après. convert-other lit ces délais dans les triggers d'origine et écrit delay_seconds: en face des scripts concernés, ce qui reproduit l'étalement (voir delay_seconds) ;
un strip_native_triggers: listant les triggers de chargement natifs (le build les supprime pour éviter un double chargement) ;
les modules VEAF du profil (RADIO, SPAWN, WEATHER, SHORTCUTS, SECURITY, REMOTE) ;
un marqueur conversion_profile: foothold (le build/validate refusent un module incompatible — Foothold embarque sa propre CTLD, donc la CTLD VEAF reste OFF) ;
un scaffold config_override: commenté ciblant Foothold Config.lua.

Pourquoi l'étalement compte¶

Ce n'est pas de la coquetterie de fidélité. AIEN inventorie les groupes terrestres une seule fois, au chargement (son propre commentaire dit « launched once at mission start and collect everything relevant that is already there »). Or Foothold crée une partie de ses groupes après coup, depuis des tâches planifiées qui démarrent à partir de 2 secondes.

Charger AIEN à l'instant zéro lui présente donc un monde que ces tâches n'ont pas encore peuplé — et le symptôme est silencieux : aucune erreur dans le journal, simplement une IA terrestre qui ne gère jamais les groupes créés par Foothold. C'est la raison des 12 secondes de Lekaa, et la raison pour laquelle un delay_seconds: détecté ne doit pas être retiré à la légère.

2. Régler le `mission.yaml`¶

Trois ajustements, tous config-only (on ne touche jamais aux scripts upstream) :

a. Community scripts VEAF (déjà coupés par le profil)¶

Foothold embarque ses propres bibliothèques (Moose, sa CTLD, AIEN, EWRS, Splash…) en custom_scripts. Les community scripts VEAF doivent donc rester OFF — sinon, par exemple, l'AIEN de VEAF écrase celui de Foothold et la mission plante. Le profil foothold scaffolde déjà ces désactivations dans le bloc modules: (et pas dans un bloc community_scripts: séparé, qui serait ignoré dès que modules: existe) — rien à faire, vérifiez juste leur présence :

modules:
  # … modules VEAF …
  # ── Community scripts OFF ──
  stts: false
  ctld: false
  aien: false
  csar: false
  hercules: false
  skynet: false
  tum: false

MiST n'est pas dans la liste : il n'est plus injecté par défaut. Les scripts VEAF ne l'appellent plus, ni aucun script communautaire livré ici, ce qui épargne 336 Ko à chaque mission. Si l'un de vos propres scripts appelle mist., le build s'en aperçoit et le réinjecte tout seul en vous disant lequel.

b. Override partiel de la config Foothold¶

Décommentez le bloc config_override: et n'y mettez que les globals que vous changez (le reste de Foothold Config.lua reste intact et se met à jour tout seul à la prochaine version). Deux contrôles au validate :

chaque clé est validée lexicalement contre le code injecté — une faute de frappe ou un renommage amont fait échouer validate et le build ;
le target doit désigner un script de la mission. Sinon l'override serait chargé en dernier, après le script de setup qui a déjà lu les réglages, et n'aurait donc aucun effet — une panne silencieuse, désormais bloquée.

config_override:
  target: "Foothold Config.lua"
  values:
    Era: Modern          # défaut ; surchargé par variante ci-dessous
    AutoRestart: false
    FootholdLocale: FR   # langue des messages Foothold à l'écran

FootholdLocale (config amont V1.0.9) accepte EN, DE, FR, ES, RU, PT-BR, TR, IT, zh-CN, zh-TW. Elle ne force pas la langue du menu radio des joueurs, qui reste réglable par chacun en jeu.

⚠️ La config externe du Config Manager (à ne pas installer)¶

Depuis la config V1.0.9, Foothold Config.lua cherche un fichier de config externe et, s'il le trouve, l'applique par-dessus les valeurs embarquées dans le .miz :

<Saved Games>\DCS…\Missions\Saves\Foothold Config.lua

C'est le canal du Foothold Config Manager (l'exécutable livré dans l'archive) : son bouton Import MIZ Config installe ce fichier. Conséquences à connaître :

notre config_override gagne quand même : le veaf-config-override.lua généré est chargé après le script de config, donc il réassigne les globals en dernier — ADR 0008 reste valable ;
mais un tel fichier posé dans le Saved Games d'un serveur modifie silencieusement toutes les missions Foothold de cette instance, y compris les nôtres, pour tous les réglages que nous ne surchargeons pas explicitement ;
Foothold affiche en plus un avertissement à l'écran (FOOTHOLD_CONFIG_EXTERNAL_OUTDATED) quand ce fichier externe est plus vieux que la config embarquée.

Donc : n'installez pas la config externe du Config Manager sur un serveur VEAF. La configuration d'une mission VEAF vit dans son mission.yaml, versionnée avec le dossier de mission et validée au build — ce qu'un fichier dans Saved Games n'est pas. Le Config Manager reste utile hors ligne pour explorer les réglages disponibles et voir ce que chaque option fait.

c. Variantes Modern / Cold-War¶

L'ère Foothold est pilotée par le global Era, qui accepte quatre valeurs — "Modern", "Coldwar", "Gulfwar" (le nom de l'ère Cold-War côté Irak) et "Vietnam". C'est une différence de config, donc on émet plusieurs .miz en un seul build via build_variants: :

mission:
  name: VEAF-Foothold-Caucasus

build_variants:
  - MODERN
  - COLD_WAR

profiles:
  MODERN:
    mission:
      era: MODERN
    config_override:
      values:
        Era: Modern
  COLD_WAR:
    mission:
      era: COLD_WAR
    config_override:
      values:
        Era: Coldwar

Le même schéma donne une variante Vietnam si on la veut (Era: Vietnam) : les missions récentes de Lekaa embarquent les appareils et les armements de l'époque, sélectionnés par Era. Sur la carte Irak, l'ère Cold-War s'appelle Gulfwar.

3. Valider¶

veaf-tools mission validate <dossier-mission>

Vérifie la syntaxe, la sémantique des modules, l'existence des custom_scripts, les incompatibilités du profil, et que chaque segment de clé config_override existe dans le code Foothold injecté.

4. Construire les deux variantes¶

veaf-tools mission build <dossier-mission>

Un seul build produit deux .miz : …_MODERN.miz et …_COLD_WAR.miz. Chaque variante : config amont intacte → petit veaf-config-override.lua réassignant Era (chargé entre la config et le setup) → triggers natifs supprimés → custom_scripts chargés dans l'ordre déclaré → spawns/data VEAF injectés.

Pour --profile <X> seul (une variante précise, suffixée de son nom) ou les options de build, voir la référence mission.yaml.

5. Tester dans DCS¶

Ouvrez chaque .miz dans DCS et vérifiez le comportement iso-fonctionnel (menu radio VEAF présent, moteur Foothold opérationnel, équipements cohérents avec l'ère). C'est l'étape de validation finale avant de publier le dossier mission.

Mettre à jour (nouvelle version Lekaa)¶

Quand Foothold sort une nouvelle release, téléchargez la nouvelle archive et ré-importez-la dans le même dossier :

veaf-tools convert other <nouvelle_release.zip> <dossier-mission> --profile foothold --update

--update rafraîchit les scripts tiers et la base de mission, préserve votre mission.yaml réglé, et normalise les noms versionnés (Moose_<date>.lua → Moose.lua, Splash_Damage_<version>_leka.lua → Splash_Damage.lua).

Il aligne aussi les delay_seconds: sur l'étalement de la nouvelle version, supprime les scripts que Lekaa ne fournit plus et réécrit custom_scripts: sur ce que charge la nouvelle version, dans son ordre de chargement. C'est ce qui couvre un renommage amont : en 5.3.0, zoneCommander.lua devient zoneCommanderv2.lua sur les dix cartes, et l'ancienne liste aurait chargé l'ancien moteur avec la nouvelle config. Vos propres scripts restent dans la liste, après ceux de Lekaa.

Le rapport (convert-other-report.md) énumère tout : scripts ajoutés, mis à jour, supprimés, entrées de custom_scripts: ajoutées ou retirées, et chaque délai écrit. Relisez-le, puis revalidez et reconstruisez. Voir CONVERT_OTHER.

convert-other-state.yaml apparaît dans le dossier de mission : c'est la liste des scripts que la version amont charge, et c'est elle qui permet de distinguer un script abandonné par Lekaa d'un script que vous avez ajouté. Versionnez-le avec la mission.