Aller au contenu

Modules et scripts communautaires

La famille où l'on se demande le plus souvent « est-ce que j'ai cassé quelque chose ? ». Souvent, non — et c'est même une des raisons d'être de cette page.

Le fait qui explique presque tout

La plupart des scripts communautaires sont activés par défaut. Vous n'avez rien à écrire dans mission.yaml pour que CTLD ou CSAR soient candidats à l'embarquement : ils sont là sauf si vous les retirez.

C'est confortable, mais ça a un effet de bord désagréable : un avertissement peut vous parler d'un module que vous n'avez jamais demandé, et le message se lit alors comme une accusation. Pour sortir un module :

modules:
  CTLD: false

Deux exceptions, dans l'autre sens. TUM et MIST sont opt-in : absents sauf si vous écrivez explicitement TUM: true ou MIST: true. TUM parce qu'il impose un contrat de conception à la mission ; MiST parce que plus aucun script VEAF ne l'appelle, et qu'embarquer 336 Ko pour personne n'avait plus de sens. Le build rallume quand même MiST tout seul s'il repère un appel dans l'un de vos scripts — voir MiST a été injecté pour vos scripts.

CTLD est activé, mais sans configuration

CTLD est activé mais aucun ctld-config.yaml n'a été trouvé dans le dossier mission — CTLD utilisera ses valeurs par défaut. Créez-en un avec ctld-tools.exe, à télécharger depuis https://github.com/VEAF/CTLD/releases (les releases de CTLD 2 sont des pre-releases : passez par l'onglet Releases).

Quand il apparaît. Vous avez explicitement écrit CTLD dans modules: de votre mission.yaml, et il n'y a pas de ctld-config.yaml dans le dossier de mission.

Ce que ça change. CTLD tourne avec ses réglages d'origine : les types d'unités logistiques, les zones de troupes, les points de largage sont ceux du script, pas les vôtres.

L'issue. Créer le fichier avec ctld-tools.exe. Le lien du message est le bon endroit — et la précision sur les pre-releases est importante : les versions de CTLD 2 n'apparaissent pas dans la liste principale des releases GitHub.

Ce que ce n'est pas. Pas une erreur, et CTLD fonctionne. Si ses réglages par défaut vous vont, vous pouvez ignorer ce message indéfiniment.

CTLD est là parce qu'il est là

CTLD est dans cette mission parce que les scripts communautaires sont activés par défaut — votre mission.yaml ne le mentionne nulle part. Il n'y a pas de ctld-config.yaml ici, donc CTLD tourne simplement avec ses propres réglages : rien n'est cassé, vous pouvez ignorer ce message. Pour retirer CTLD de la mission, ajoutez 'CTLD: false' sous 'modules:' dans mission.yaml. Pour le configurer au contraire, créez ctld-config.yaml avec ctld-tools.

Rien n'est cassé. Ce message existe parce que le précédent, affiché dans cette situation-là, disait en substance « allez télécharger un outil » à quelqu'un qui n'avait jamais entendu parler de CTLD. Il a été séparé exprès.

La différence avec le message précédent, et c'est toute la subtilité :

Vous avez écrit CTLD dans modules: Vous n'avez rien écrit
Message « CTLD est activé mais aucun fichier… » « CTLD est dans cette mission parce que… »
Ce qu'on vous propose Créer la configuration Retirer CTLD, ou le configurer

Les issues. Ne rien faire, ou écrire CTLD: false sous modules: si vous ne voulez pas de CTLD dans votre mission.

CTLD sans aucun point logistique

════════════════════════════════════════════════════════════════ ATTENTION — CTLD : AUCUN POINT LOGISTIQUE modules.CTLD.manage_logistics est à false et, dans ctld-config.yaml, logisticUnitTypes et troopZoneShipTypes sont vides. Aucune FARP ni aucun porte-avions placé dans l'éditeur ne sera un point de chargement. Si ce n'est pas voulu, repassez manage_logistics à true, ou renseignez ces listes avec ctld-tools. ════════════════════════════════════════════════════════════════

Dans l'éditeur. Vos FARP et vos porte-avions sont bien là, visibles, posés — et aucun ne sera un point de chargement CTLD. Les hélicoptères ne pourront ni embarquer des troupes ni prendre de cargaison nulle part.

Pourquoi c'est encadré. C'est une combinaison légitime — on peut vouloir gérer sa logistique entièrement à la main — mais jamais un accident sur lequel se taire. D'où l'encadré : c'est la seule manière de ne pas le rater dans une sortie de build.

Les issues. Remettre manage_logistics: true pour que VMCT complète les listes, ou les renseigner vous-même avec ctld-tools.

CTLD : les types logistiques ont été complétés

CTLD : gestion automatique de la logistique — logisticUnitTypes complété avec FARP, … Votre ctld-config.yaml n'est pas modifié ; c'est la copie injectée dans la mission qui l'est.

Tout va bien. Le message a une deuxième phrase pour une bonne raison : votre fichier sur le disque n'est pas touché. Ce qui change, c'est la copie remise au moteur. Sans cette précision, vous liriez une chose dans ctld-tools pendant qu'une autre tourne en jeu.

Pour l'arrêter. manage_logistics: false sous modules.CTLD — mais relisez le message précédent avant, c'est exactement le chemin qui y mène.

CTLD : un nom de ctld-config.yaml n'est pas dans la mission

'extract1' dans extractableGroups de ctld-config.yaml n'est pas dans la mission : CTLD l'ignorera avec un avertissement « not found » au démarrage. Le retirer (dans ctld-tools), ou le placer dans l'éditeur de mission.

D'où ça vient, presque toujours. Le catalogue de CTLD donne des exemples : extract1 … extract25 et logistic1 … logistic10. Aucune mission VEAF ne les contient, et une mission créée avant FIX-IN-GAME-TEST-FINDINGS les a gardés : 35 avertissements au démarrage, qui noient les autres. Une mission créée depuis part avec les deux listes vides.

Les issues. Vider la liste dans ctld-tools, ou n'y laisser que les groupes (extractableGroups) et les unités (logisticUnits) que la mission contient vraiment. Écrire [] seul sur sa ligne : le lecteur YAML de CTLD lit extractableGroups: [] # note comme le texte "[] # note".

CTLD : ctld-config.yaml est écrit pour un autre catalogue

ctld-config.yaml est écrit pour le catalogue CTLD 2.0.0, les outils livrent le 2.2.0. Réglages absents, que CTLD prend à leur valeur par défaut : enableParachuteDrop, crateDropExtraDistance, crateSpawnGap. veaf-tools ctld-upgrade les ajoute.

Ce que ça veut dire. Votre fichier porte la version du catalogue CTLD pour laquelle il a été écrit (configVersion), et une version des outils plus récente livre un CTLD plus récent. La mission marche : CTLD prend chaque réglage absent à sa valeur par défaut, et l'annonce aux joueurs au démarrage. C'est un avertissement, pas une erreur.

L'issue. veaf-tools mission ctld-upgrade dans le dossier de mission : il ajoute chaque réglage manquant à sa valeur par défaut, dans la section où le catalogue le range, et met configVersion à jour. Aucune de vos valeurs ne change, et les listes ne sont pas touchées : une liste absente est un retrait voulu. Seule exception : une liste que CTLD a ajoutée après la version de votre fichier (les caisses et chargements de la Fat Cow sont arrivés avec le catalogue 2.3.0). Vous ne pouvez pas l'avoir retirée : la commande l'écrit, et validate la compte parmi les réglages manquants.

Deux messages peuvent l'accompagner, que la commande ne traite pas :

  • des réglages que le catalogue ne connaît plus : CTLD les ignore, vous pouvez les retirer dans ctld-tools ;
  • des nouveautés dans des tables que la mission possède (capabilitiesByType.UH-1H.crateSpawnSector, par exemple) : CTLD lit ces tables en entier, sans retomber sur le catalogue, donc la mission garde l'ancien comportement. Les ajouter change le jeu ; c'est à vous de le décider, dans ctld-tools.

Ces deux listes ne sortent que tant que les versions diffèrent : ctld-upgrade les affiche une dernière fois, puis validate n'en parle plus. Notez-les avant de lancer la commande si vous comptez y revenir.

Des fichiers son manquent

Des fichiers son requis par un module communautaire activé ne sont fournis ni par les outils ni par la mission : beacon.ogg. Ajoutez-les dans src/mission/l10n/DEFAULT/ sinon la fonctionnalité associée sera muette (ex. beacons CTLD).

Ce que ça veut dire. Un module activé appelle un son que ni les outils ni votre dossier ne fournissent. En jeu, la fonctionnalité marchera — silencieusement.

Où le fichier doit aller. Dans src/mission/l10n/DEFAULT/, et nulle part ailleurs. Un son posé ailleurs dans la mission (dans le dossier des planchettes, par exemple) ne compte pas : les scripts le cherchent à cet endroit précis.

Les issues. Ajouter le fichier, ou désactiver le module qui le réclame.

TUM sans zones de territoire

TUM est activé mais aucune zone de territoire BLUFOR, REDFOR n'a été trouvée — TheUniversalMission s'arrête au démarrage sans elles.

Dans l'éditeur. TUM a besoin d'au moins une zone de déclenchement dont le nom commence par BLUFOR et d'une dont le nom commence par REDFOR — la casse n'a pas d'importance. Ce sont les territoires de départ des deux camps.

Ce qui se passe sans elles. TUM s'arrête à l'initialisation. Pas de message en jeu, pas de menu : le module est simplement absent. Cet avertissement de build est donc la seule notification que vous aurez.

Les issues. Créer les zones dans l'éditeur, ou désactiver TUM dans mission.yaml.

Ce que ce n'est pas — et attention à la réciproque. Le contrôle ne vérifie que les noms des zones. Le contrat de TUM va plus loin : chaque territoire doit aussi posséder un aérodrome. Deux zones correctement nommées sur du terrain vide font donc disparaître l'avertissement sans que TUM démarre pour autant. Le silence de ce contrôle ne garantit pas que TUM fonctionnera.

Un module est incompatible avec le profil de conversion

modules : « CTLD » est incompatible avec le profil de conversion « foothold » et doit rester désactivé.

Au build, c'est un refus pur et simple :

Build impossible : le(s) module(s) CTLD sont incompatibles avec le profil de conversion « foothold ». Désactivez-les dans mission.yaml.

Ce que ça veut dire. Votre mission.yaml porte un conversion_profile, et ce profil déclare certains modules VEAF incompatibles. Pour foothold, c'est CTLD : une mission Foothold embarque son propre CTLD dans ses custom_scripts, et charger les deux ensemble les fait entrer en conflit.

L'issue, unique. Désactiver le module :

modules:
  CTLD: false

Ce que ce n'est pas. Pas une opinion sur la qualité du module — c'est une question de double-chargement. Et c'est un des rares messages de cette documentation qui arrête vraiment le build.

Un module toujours actif ne peut pas être désactivé

Le module 'UNITS' est toujours actif et ne peut pas être activé ou désactivé (enable: false) — supprimez la clé 'enable' de son entrée dans mission.yaml.

Celui-ci arrête le build. C'est une erreur, pas un avertissement : le .miz n'est pas écrit.

Les modules concernés. UNITS, TIME, CACHE, EVENTS, MARKERS et COMMANDS. Ce sont les fondations du framework VEAF : tout le reste en dépend, alors les activer ou les désactiver n'a pas de sens.

Ce qui le déclenche exactement. Uniquement la forme développée, avec une clé enable ou enabled à l'intérieur :

modules:
  UNITS:
    enable: false      # ← refusé

L'issue. Retirer cette clé. Vous pouvez garder l'entrée pour configurer le module ; c'est seulement le fait de prétendre l'allumer ou l'éteindre qui est refusé.

Un id de script communautaire est inconnu

ID de script communautaire inconnu 'ctdl' dans 'community_scripts:' ; ignoré.

Presque toujours une faute de frappe, ou le nom d'un script retiré des outils depuis. L'entrée est ignorée — donc si vous cherchiez à désactiver ce script, sachez que ça n'a rien désactivé du tout.

Au passage : community_scripts: est la forme dépréciée. Voir ci-dessous.

lua_modules: et community_scripts: sont dépréciés

Déprécié : 'lua_modules:' et 'community_scripts:' sont remplacés par 'modules:' — merci de mettre à jour votre mission.yaml

Et si vous avez les deux formes à la fois :

'modules:' et 'lua_modules:'/'community_scripts:' sont tous deux présents — 'modules:' a la priorité

Ce que ça veut dire. Les anciennes sections marchent encore, mais modules: les remplace toutes les deux : un seul bloc pour les modules VEAF et les scripts communautaires.

Le piège quand les deux coexistent. modules: gagne, entièrement. Un module que vous croyez activé dans lua_modules: ne l'est pas s'il n'est pas dans modules: — c'est la cause la plus vicieuse d'un module qui « ne démarre pas » sans qu'aucun message ne le dise.

L'issue. Fusionner dans modules:, puis supprimer les deux anciennes sections. Voir mission.yaml et ses modules.

Pour aller plus loin