TheCreepero/event-pack-create

Event Pack : créer un pack ou ajouter des événements

Planifie un pack ou de nouveaux événements, jusqu'au moindre texte, effet et image, dans un seul fichier de plan que event-pack-implement exécute. Lisez docs/source-format.md et docs/style-guide.md avant la Phase 4.

Règles

• Chaque fait est vérifié sur sa page. Un fait n'entre dans la fiche factuelle que depuis un KEEP ou FIX de la Phase 3a, avec sa source et sa citation ; aucun détail qu'aucune page vérifiée ne mentionne n'entre dans un texte, aussi plausible soit-il.
• La licence est la décision de l'outil. Une image n'entre dans le plan qu'après que build.ps1 -FetchPicture ... -DryRun a affiché ACCEPTED pour elle.
• L'éditeur valide chaque texte. Aucun plan n'est PRÊT avec un événement pour lequel l'éditeur n'a pas renvoyé KEEP lors de son dernier tour.
• Le pack livré n'est pas modifié ici. Cette compétence écrit le plan, le dossier sous research/<key>/ et les fichiers sous scratch/ ; source/ et packs/ changent lors de l'implémentation du plan. La seule exception est -NewPack pour un tout nouveau pack (Phase 0) ; la vignette du pack est créée lors de l'implémentation (Phase 3, étape 5).
• Les dossiers sont conservés. Chaque dossier reste dans research/<key>/, jamais supprimé ni réduit, même si le plan est abandonné : les candidats non retenus et les faits non utilisés sont le point de départ de la prochaine expansion du pack. Les seuls ajouts sont les lignes Used: et Checked: de la Phase 5.4. Le dossier est commité avec le plan lors de son envoi, ou sur demande du propriétaire.
• Ne posez au propriétaire que les questions de la Phase 0 et de la Phase 2.

Phase 0 : périmètre

1. Demandez au propriétaire, en un seul message : le pays (et son tag si pas évident), la période (par défaut : 1936 jusqu'au début de sa guerre, plus ses premiers mois), le nombre d'événements (par défaut 10 à 15), les types à privilégier ou éviter, et tout ce que le pack ne doit pas toucher. Enregistrez les réponses dans la section « Décisions » du plan.
2. Nouveau pack : confirmez le tag avec la compétence hoi4-vanilla-lookup (Get-HoiCountry), puis powershell -File .\build.ps1 -NewPack -Pack <key> -Tag <TAG> -DisplayName "<Pays>" ; cela génère une première vignette sur l'écran de chargement par défaut de la famille avec le New-HoiThumbnail.ps1 du Modding Manager (ou copie assets/thumbnail_master.png et affiche la commande si cela ne peut pas s'exécuter), vignette qui sera remplacée en Phase 3. Écrivez source/<key>/workshop-intro.bbcode : deux ou trois phrases simples décrivant le pack, et les lignes d'information rédigées par -NewPack.
3. Copiez docs/plans/TEMPLATE-pack.md vers docs/plans/<YYYY-MM-DD>-<key>-<quoi>.md et remplissez l'en-tête, le « Contexte » et les « Décisions ». Pour un pack existant : notez le dernier identifiant d'événement ; les nouveaux identifiants continuent à partir de celui-ci.

Phase 1 : recherche

1. Si research/<key>/ existe, lisez ses dossiers. Les candidats sans marque Used: qui correspondent à la période et aux types sont candidats pour ce plan également ; notez leurs clés. Un candidat avec une ligne Checked: a été vérifié sur ses pages ; jugez-le d'après le lieu nommé par sa ligne Checked: la plus récente, pas d'après les faits écrits en dessous. La fiche factuelle qui s'y trouve contient tous les faits vérifiés. Les sections « Vérification des faits » d'un plan ne contiennent que les corrections et les abandons, donc les faits du dossier qu'elle ne nomme pas ont été conservés. S'il est retenu, il passe quand même par la Phase 3a.
2. Candidats souhaités : environ une fois et demie le nombre d'événements souhaités, moins les candidats utilisables des phases précédentes. Répartissez-les en lots d'au plus 12, chacun couvrant sa propre tranche de la période (pour 30 : 1936, 1937-1938, 1939-1940), et lancez un ep-historical-researcher par lot, tous en parallèle, chacun avec : le pays, le tag, sa tranche de période, son nombre de candidats, les types de la Phase 0, les titres des événements existants du pack, chaque candidat des dossiers précédents (clé, date, une ligne), et son propre chemin research/<key>/<YYYY-MM-DD>-dossier.md (avec -2 et suivants pour les autres lots, ou si ce jour en a déjà un). Attendez tous les résumés.

Phase 2 : choisir

Lisez les nouveaux dossiers. Éliminez les candidats dont les faits clés sont UNVERIFIED, qui ne peuvent pas remplir 40 mots avec des faits cités, ou qui doublonnent un candidat d'un autre lot. Montrez les autres au propriétaire, avec les candidats utilisables des dossiers précédents marqués comme tels, sous forme d'une liste courte (clé, date, type, condition : fenêtre de date ou état du jeu, une ligne), avec votre recommandation de ceux à garder et pourquoi, et recueillez son choix.

Phase 3 : images

1. Lancez ep-picture-researcher avec les événements retenus : clé, date, lieu et les idées d'images du dossier.
2. Pour chaque événement, exécutez powershell -File .\build.ps1 -FetchPicture -Pack <key> -File "<File:...>" -Key <clé image> -DryRun sur sa première proposition ; en cas de REJECTED, essayez la suivante. Un événement sans fichier accepté reçoit une image vanilla (vanilla:GFX_report_event_<nom>, trouvée avec Find-HoiUsage de la compétence hoi4-vanilla-lookup) et une note dans le plan.
3. Choisissez le recadrage et la tonalité par image : warm pour les photographies en noir et blanc (cela correspond aux images du jeu), none pour les illustrations en couleur ; un recadrage autre que 50 uniquement si la note de recadrage du chercheur le demande.
4. Remplissez le tableau « Images » du plan avec ce que les tests à blanc ont affiché.
5. Vignette, pour un nouveau pack ou un pack sans packs.<key>.background dans assets/thumbnail.json : l'arrière-plan est l'une des images d'événement du pack, pas un écran de chargement vanilla. Le New-HoiThumbnail.ps1 du Modding Manager dessine le reste dans la mise en page fixe des Event Packs (la bordure du jeu, « EVENT PACK » et le pays sur la plaque en bas, le drapeau du tag du pack en haut à droite), donc seuls l'image et son recadrage sont à choisir. Choisissez une image qui a affiché ACCEPTED, de préférence PD ou CC0 ; CC BY convient aussi, car la description Workshop générée crédite chaque image utilisée par un événement. Regardez l'image et nommez l'endroit où se trouve son sujet : la plaque couvre environ le tiers inférieur du carré et le drapeau son coin supérieur droit, donc privilégiez une image dont le sujet peut se situer au milieu supérieur. Une image paysage remplit toute la hauteur du carré, donc le recadrage ("center", "left", "right") ne la déplace que latéralement ; une image portrait remplit sa largeur, et "top" ou "bottom" maintient le sujet visible ; les fractions de centrage [x, y] le placent entre les deux. Écrivez Thumbnail: <clé image>, crop <recadrage> et remplissez l'étape 4 des « Étapes d'implémentation » avec la clé de l'image, le recadrage en JSON, et le chemin absolu du Modding Manager comme <Manager root> (le dossier deux niveaux au-dessus de ce dépôt). Ses commandes prennent -Path ., donc la répétition de la Phase 5 rend et écrit uniquement sa copie. Un test à sec ne télécharge rien, donc la vignette est créée lors de l'implémentation, après l'étape 3, à partir de la copie sauvegardée par -FetchPicture dans sources-cache/<key>/ (le rendu Commons, jusqu'à 1600 px de large), jamais à partir du DDS 210x176. Un pack qui a déjà sa propre vignette : écrivez Thumbnail: unchanged et faites lire l'étape 4 comme Thumbnail unchanged: nothing to run., pour que les numéros d'étape restent.

Phase 3a : vérifier

S'exécute après le choix du propriétaire, en même temps que la Phase 3 si vous le souhaitez ; une citation d'un chercheur est une piste, pas encore une vérification.

1. Lancez ep-audit-researcher sur les événements retenus, au maximum cinq par agent, tous en parallèle. Collez chaque section d'événement du dossier entière ; n'envoyez pas d'images.
2. Seuls les faits KEEP et FIX sont conservés, chacun avec la source et la citation retournées par le vérificateur. Un événement avec moins de 40 mots de détails vérifiés retourne en Phase 2 pour un remplacement, et le remplacement passe aussi par la Phase 3a.
3. Remplissez la section « Vérification des faits » du plan : agents et événements par agent ; par événement vérifié (y compris les remplacés), les comptes KEEP, FIX et DROP, chaque fait corrigé avec sa correction et chaque fait abandonné ; les événements remplacés.

Phase 4 : écrire

1. Écrivez la section de chaque événement retenu dans le bloc markdown fact-sheets du plan à partir des seuls résultats de sa Phase 3a : chaque ligne de fait est - <fait>. Source: <URL> (<titre de page>). Quote: «<ligne de la page>». Ne recopiez jamais un fait de dossier directement.
2. Écrivez les événements dans le bloc json events : pour un pack existant, partez du source/<key>/events.json actuel et ajoutez-y. Suivez docs/source-format.md pour chaque champ et docs/style-guide.md pour chaque texte. Effets petits et correspondant à leur option ; une idée temporisée uniquement si l'événement la mérite. Trois règles que l'éditeur vous impose :
   • Aucune affirmation obtenue en joignant deux faits, à moins qu'une seule citation ne mentionne l'affirmation jointe.
   • Titres et rôles tels qu'ils étaient à la date de l'événement, pas tels qu'ils sont devenus plus tard.
   • Le texte reste vrai chaque jour de la fenêtre fire : rien qu'il qualifie de récent ou d'à venir ne peut être déjà terminé, ou ne pas encore s'être produit, un autre jour de la fenêtre.
   • Un événement concernant une guerre, ou la préparation à une guerre, est conditionné par l'état du jeu dans fire.trigger (voir AGENTS.md), pas par une date ; son texte ne mentionne aucune date historique pour le début de la guerre ou les préparatifs. Un événement de temps de paix est bloqué une fois que le pays est en guerre. Avant qu'un déclencheur n'entre dans le plan, recherchez sa portée avec Find-HoiDoc, et recherchez chaque tag, état et drapeau qu'il nomme au début de la fenêtre (Get-HoiState, Get-HoiCountryHistory, Find-HoiUsage) : un déclencheur qui est un script valide peut néanmoins n'être jamais vrai dans une partie normale (un pays qui n'existe pas au début, un état qu'un autre pays possède). Une recherche promise par le plan pour plus tard est effectuée avant que le plan ne soit PRÊT.
3. Vérifiez les déclencheurs avant que l'éditeur ne les voie. Lancez l'agent trigger-checker (le Agents/trigger-checker.md du Modding Manager, installé au niveau utilisateur ; Antigravity passe ce fichier à invoke_subagent) avec le chemin du plan, les clés des événements et le tag du pack. Il résout chaque fire.trigger par rapport aux fichiers du jeu à la date de fire.after de l'événement et répond, par événement, si le déclencheur peut être vrai dans la fenêtre, combien de temps il tient face à la vérification hebdomadaire, si le texte est faux dans un cas que le déclencheur autorise, et si la fenêtre correspond aux dates du texte. Appliquez chaque FIX tel que donné, repassez les événements modifiés, et enregistrez le verdict de chaque événement dans la section « Vérification des déclencheurs » du plan : OK, le FIX avec le déclencheur qui a remplacé l'ancien, ou OPEN avec la sonde et son résultat ou la décision du propriétaire. Un plan avec un événement OPEN qui n'a ni résultat de sonde ni décision du propriétaire n'est pas PRÊT. Les conditions suggérées par l'éditeur sont des pistes pour cette étape, pas des déclencheurs.
4. Lancez ep-editor avec le chemin du plan (son bloc markdown fact-sheets est la fiche factuelle) et les clés des événements. Appliquez chaque REWRITE tel que donné ; abandonnez ou remplacez un REJECT (retour en Phase 2 pour un remplacement). Enregistrez chaque tour dans le « Registre de l'éditeur ». Renvoyez les événements modifiés à l'éditeur jusqu'à ce que chaque événement soit KEEP ; au maximum trois tours, puis demandez au propriétaire.
5. Jugez l'intro Workshop du pack, source/<key>/workshop-intro.bbcode : lancez workshop-editor en mode mod (le docs/workshop-text-style.md du Modding Manager (..\..\docs\workshop-text-style.md), section « Auditing a page ») avec le dossier mod (la racine du dépôt) et ce fichier, après que Test-WorkshopText.ps1 -Mod "Event Packs" -Pack <key> a réussi. L'intro ne dit que ce que montrent les fichiers events.json et pictures.json du pack (le nombre d'événements, quels événements ont une image de période, quels sont les effets) et utilise le libellé des intros des autres packs pour le même fait. Appliquez chaque REWRITE, exécutez -Generate, Sync-WorkshopRegions.ps1 et la vérification mécanique à nouveau, puis renvoyez l'intro jusqu'à ce qu'elle soit KEEP ; au maximum trois tours, puis demandez au propriétaire. Enregistrez les tours dans le « Registre de l'éditeur ».

Phase 5 : validation

1. Répétez le plan sans toucher au dépôt : robocopy . scratch\rehearsal /MIR /XD .git scratch artifacts sources-cache, puis dans scratch\rehearsal exécutez les étapes 1 à 8 du plan exactement comme écrit (elles n'écrivent que la copie). Chaque étape doit produire ce qu'elle dit devoir produire ; corrigez le plan, pas la copie, et répétez. L'étape 4 modifie le fichier assets\thumbnail.json de la copie ; ouvrez l'aperçu qu'elle nomme avec l'outil Read, et choisissez une autre image ou un autre recadrage si la plaque de titre ou le drapeau couvre le sujet. L'étape 8 dessine chaque événement comme la fenêtre du jeu (scratch\rehearsal\artifacts\workshop-images\<key>/) : ouvrez les images avec l'outil Read, et raccourcissez un titre ou une option pour lequel le rendu affiche un [WARN] : il déborde de sa boîte dans le texte en dessous [GUW-027].
2. Remplissez la section « Événements », listez dans « Conservé après jugement » tout [WARN] que -Check -Pack <key> ou -RenderEvents -Pack <key> de la répétition a affiché et qui persiste, et mettez Status: READY.
3. Supprimez la copie : Remove-Item -Recurse -Force scratch\rehearsal.
4. Marquez les dossiers, dans chaque section de la clé du candidat (dossier et addendum inclus) :
   • Chaque événement du plan PRÊT reçoit une ligne Used: <nom du fichier de plan> juste sous son en-tête ## <key>.
   • Chaque candidat vérifié en Phase 3a, y compris les remplacés, reçoit ensuite une ligne en dessous (en dessous de son en-tête s'il n'a pas de Used:, en dessous de toute ligne Checked: antérieure) : Checked: <nom du fichier de plan>, <K> kept, <F> fixed, <D> dropped. The facts below are the researcher's notes, not the checked ones: see <où>. Les comptes sont les siens issus de la « Vérification des faits ». <où> est source/<key>/fact-sheets.md pour un événement du plan, et the plan's "Fact verification" pour un événement remplacé.
   • Ne changez rien d'autre dans un dossier. Un candidat jamais vérifié reste non marqué, comme le chercheur l'a écrit.

Phase 6 : transmission

Faites rapport au propriétaire : le chemin du plan, les chemins des dossiers avec le nombre de candidats qu'ils gardent pour plus tard, les événements avec leurs titres, les licences des images (combien PD, CC0, CC BY), l'image et le recadrage de la vignette, les totaux de la vérification des faits, les totaux de l'éditeur, et le fait que event-pack-implement l'exécutera. Puis arrêtez-vous.

Antigravity : passez le chemin de chaque consigne d'agent à invoke_subagent ; si aucun sous-agent ne peut être lancé, lisez la consigne et effectuez le travail vous-même, en gardant le travail de l'éditeur dans un passage séparé qui ne lit que le brouillon, la fiche factuelle et le guide de style.