Event Pack: Erstellen eines Pakets oder Hinzufügen von Ereignis…

Event Pack: Erstellen eines Pakets oder Hinzufügen von Ereignissen

Plant ein Paket oder neue Ereignisse bis hin zu jedem Text, Effekt und Bild in einer einzigen Plan-Datei, die event-pack-implement ausführt. Lies docs/source-format.md und docs/style-guide.md vor Phase 4.

Regeln

• Jede Tatsache wird auf ihrer Seite überprüft. Eine Tatsache gelangt nur aus einer Phase 3a KEEP oder FIX mit ihrer Quelle und ihrem Zitat in das Faktenblatt; ein Detail, das keine geprüfte Seite angibt, gelangt nicht in einen Text, wie plausibel es auch sein mag.
• Die Lizenz ist die Entscheidung des Tools. Ein Bild gelangt nur dann in den Plan, wenn build.ps1 -FetchPicture ... -DryRun ACCEPTED dafür ausgegeben hat.
• Der Redakteur gibt jeden Text frei. Kein Plan wird READY, wenn der Redakteur nicht in der letzten Runde für jedes Ereignis KEEP zurückgegeben hat.
• Das ausgelieferte Paket wird hier nicht berührt. Dieses Skill schreibt den Plan, das Dossier unter research/<key>/ und Dateien unter scratch/; source/ und packs/ ändern sich, wenn der Plan umgesetzt wird. Die einzige Ausnahme ist -NewPack für ein brandneues Paket (Phase 0); das eigene Thumbnail des Pakets wird bei der Implementierung erstellt (Phase 3, Schritt 5).
• Dossiers werden aufbewahrt. Jedes Dossier bleibt in research/<key>/, wird nie gelöscht oder beschnitten, auch wenn der Plan verworfen wird: Die nicht ausgewählten Kandidaten und die nicht verwendeten Fakten sind der Ausgangspunkt für die nächste Erweiterung des Pakets. Die einzigen Ergänzungen sind die Zeilen Used: und Checked: von Phase 5.4. Es wird mit dem Plan committet, wenn der Plan ausgeliefert wird, oder auf Anweisung des Besitzers.
• Stelle dem Besitzer nur die Fragen aus Phase 0 und Phase 2.

Phase 0: Umfang

1. Frage den Besitzer in einer Nachricht: das Land (und dessen Tag, falls nicht offensichtlich), den Zeitraum (Standard: 1936 bis zum Beginn seines Krieges, plus die ersten Monate), die Anzahl der Ereignisse (Standard: 10 bis 15), zu betonende oder zu vermeidende Arten und alles, was das Paket nicht berühren darf. Halte die Antworten im Abschnitt "Entscheidungen" des Plans fest.
2. Ein neues Paket: Bestätige den Tag mit dem hoi4-vanilla-lookup Skill (Get-HoiCountry), dann führe powershell -File .\build.ps1 -NewPack -Pack <key> -Tag <TAG> -DisplayName "<Country>" aus; es rendert ein erstes Thumbnail über dem standardmäßigen Ladebildschirm der Familie mit dem New-HoiThumbnail.ps1 des Modding Managers (oder kopiert assets/thumbnail_master.png und gibt den Befehl aus, wenn dies nicht ausgeführt werden kann), das in Phase 3 ersetzt wird. Schreibe source/<key>/workshop-intro.bbcode: zwei oder drei einfache Sätze über das Paket und die Infoszeilen, die -NewPack entworfen hat.
3. Kopiere docs/plans/TEMPLATE-pack.md nach docs/plans/<YYYY-MM-DD>-<key>-<was>.md und fülle den Header, "Kontext" und "Entscheidungen" aus. Bei einem bestehenden Paket: Notiere die letzte Ereignis-ID; neue IDs werden fortlaufend daran anschließend vergeben.

Phase 1: Recherche

1. Wenn research/<key>/ existiert, lies dessen Dossiers. Deren Kandidaten ohne Used:-Markierung, die in den Zeitraum und die Arten passen, sind ebenfalls Kandidaten für diesen Plan; notiere ihre Schlüssel. Ein Kandidat mit einer Checked:-Zeile wurde auf seinen Seiten überprüft; bewerte ihn nach dem Ort, den seine neueste Checked:-Zeile nennt, nicht nach den darunter geschriebenen Fakten. Ein Faktenblatt dort enthält jede überprüfte Tatsache. Die "Faktenprüfung" eines Plans enthält nur die Korrekturen und Streichungen, daher wurden die Fakten des Dossiers, die es nicht nennt, beibehalten. Wenn ausgewählt, durchläuft es dennoch Phase 3a.
2. Gewünschte Kandidaten: etwa eineinhalb Mal so viele wie die gewünschten Ereignisse, abzüglich der verwendbaren früheren Kandidaten. Teile sie in Durchläufe von höchstens 12 auf, die jeweils einen eigenen Abschnitt des Zeitraums abdecken (für 30: 1936, 1937-1938, 1939-1940), und entsende einen ep-historical-researcher pro Durchlauf, alle parallel, jeweils mit: dem Land, Tag, seinem Zeitabschnitt, seiner Anzahl von Kandidaten, den Arten aus Phase 0, den Titeln der bestehenden Ereignisse des Pakets, jedem Kandidaten der früheren Dossiers als Schlüssel, Datum und eine Zeile, und seinem eigenen Pfad research/<key>/<YYYY-MM-DD>-dossier.md (mit -2 und höher für die anderen Durchläufe oder wenn an diesem Tag bereits eines existiert). Warte auf jede Zusammenfassung.

Phase 2: Auswahl

Lies die neuen Dossiers. Streiche Kandidaten, deren Schlüsselfakten UNVERIFIED sind, die nicht 40 Wörter mit zitierten Fakten füllen können oder die einen Kandidaten eines anderen Durchlaufs duplizieren. Zeige dem Besitzer den Rest, wobei die verwendbaren früheren Kandidaten als solche markiert sind, als kurze Liste (Schlüssel, Datum, Art, Tor: Datumsfenster oder Spielzustand, eine Zeile) mit deiner Empfehlung, welche behalten werden sollten und warum, und nimm seine Wahl entgegen.

Phase 3: Bilder

1. Entsende ep-picture-researcher mit den ausgewählten Ereignissen: Schlüssel, Datum, Ort und die Bildideen des Dossiers.
2. Führe für jedes Ereignis powershell -File .\build.ps1 -FetchPicture -Pack <key> -File "<Datei:...>" -Key <Bildschlüssel> -DryRun auf seinem ersten Vorschlag aus; bei REJECTED versuche den nächsten. Ein Ereignis ohne akzeptierte Datei erhält ein Vanilla-Bild (vanilla:GFX_report_event_<name>, gefunden mit Find-HoiUsage des hoi4-vanilla-lookup Skills) und einen Vermerk im Plan.
3. Wähle Beschnitt und Tonung pro Bild: warm für Schwarzweißfotografien (es passt zu den eigenen Bildern des Spiels), none für Farbkunst; ein anderer Beschnitt als 50 nur, wenn die Beschnittnotiz des Forschers danach fragt.
4. Fülle die Tabelle "Bilder" im Plan mit dem, was die Trockenläufe ausgegeben haben.
5. Thumbnail, für ein neues Paket oder eines ohne packs.<key>.background in assets/thumbnail.json: Der Hintergrund ist eines der eigenen Ereignisbilder des Pakets, kein Vanilla-Ladebildschirm. Der New-HoiThumbnail.ps1 des Modding Managers zeichnet den Rest im einen festen Event Pack-Layout (die Spielumrandung, "EVENT PACK" und das Land auf dem Titelband unten, die Flagge des Paket-Tags oben rechts), daher sind das Bild und sein Beschnitt die einzigen Entscheidungen. Wähle ein Bild, das ACCEPTED ausgegeben hat, bevorzugt PD oder CC0; CC BY ist auch in Ordnung, da die generierte Workshop-Beschreibung jedes Bild, das ein Ereignis verwendet, angibt. Betrachte das Bild und benenne, wo sich sein Motiv befindet: Das Band bedeckt etwa das untere Drittel des Quadrats und die Flagge seine obere rechte Ecke, daher bevorzuge ein Bild, dessen Motiv in der oberen Mitte sitzen kann. Ein Querformatbild füllt die gesamte Höhe des Quadrats aus, daher verschiebt der Beschnitt ("center", "left", "right") es nur seitwärts; ein Hochformatbild füllt seine Breite aus, und "top" oder "bottom" hält das Motiv darin; [x, y]-Zentrierungsbrüche platzieren es dazwischen. Schreibe Thumbnail: <Bildschlüssel>, Beschnitt <Beschnitt> und fülle Schritt 4 von "Implementierungsschritte" mit dem Bildschlüssel, dem Beschnitt als JSON und dem absoluten Pfad des Modding Managers als <Manager-Root> (der Ordner zwei Ebenen über diesem Repository). Seine Befehle verwenden -Path ., daher rendert die Phase 5-Probe nur in ihre Kopie und schreibt nur in diese. Ein Trockenlauf lädt nichts herunter, daher wird das Thumbnail bei der Implementierung nach Schritt 3 aus der Kopie erstellt, die -FetchPicture in sources-cache/<key>/ speichert (die Commons-Wiedergabe, bis zu 1600 px breit), niemals aus der 210x176 DDS. Ein Paket, das bereits ein eigenes Thumbnail hat: Schreibe Thumbnail: unverändert und lasse Schritt 4 Thumbnail unverändert: nichts auszuführen. lauten, damit die Schrittnummern erhalten bleiben.

Phase 3a: Überprüfung

Läuft nach der Wahl des Besitzers, gleichzeitig mit Phase 3, wenn du möchtest; ein Zitat eines Forschers ist eine Spur, noch keine Überprüfung.

1. Entsende ep-audit-researcher auf die ausgewählten Ereignisse, höchstens fünf pro Agent, alle parallel. Füge den gesamten Dossier-Abschnitt jedes Ereignisses ein; sende keine Bilder.
2. Nur KEEP- und FIX-Fakten werden fortgesetzt, jeweils mit der Quelle und dem Zitat, das der Prüfer zurückgegeben hat. Ein Ereignis, das mit weniger als 40 Wörtern geprüfter Details zurückbleibt, geht zurück zu Phase 2 für einen Ersatz, und der Ersatz durchläuft ebenfalls Phase 3a.
3. Fülle die "Faktenprüfung" des Plans: Agenten und Ereignisse pro Agent; pro geprüftem Ereignis, einschließlich ersetzter, die KEEP-, FIX- und DROP-Anzahlen, jede korrigierte Tatsache mit ihrer Korrektur und jede gestrichene Tatsache; die ersetzten Ereignisse.

Phase 4: Schreiben

1. Schreibe den Abschnitt jedes ausgewählten Ereignisses im Block markdown fact-sheets des Plans ausschließlich aus seinen Phase 3a-Ergebnissen: Jede Tatsachenzeile ist - <Tatsache>. Quelle: <URL> (<Seitentitel>). Zitat: «<Zeile von der Seite>». Kopiere niemals eine Dossier-Tatsache direkt hinein.
2. Schreibe die Ereignisse in den Block json events: Bei einem bestehenden Paket beginne mit dem aktuellen source/<key>/events.json und erweitere es. Befolge docs/source-format.md für jedes Feld und docs/style-guide.md für jeden Text. Kleine Effekte, die zu ihrer Option passen; eine zeitlich begrenzte Idee nur, wenn das Ereignis eine verdient. Drei Regeln, an die dich der Redakteur hält:
   • Keine Behauptung durch die Verknüpfung zweier Tatsachen, es sei denn, ein Zitat stellt die verknüpfte Behauptung auf.
   • Titel und Rollen, wie sie zum Zeitpunkt des Ereignisses waren, nicht wie sie später wurden.
   • Der Text bleibt an jedem Tag des fire-Fensters wahr: Nichts, was es als aktuell oder bevorstehend bezeichnet, darf an einem anderen Tag des Fensters bereits vorbei oder noch nicht eingetreten sein.
   • Ein Ereignis über einen Krieg oder über die Vorbereitung darauf wird durch den Spielzustand in fire.trigger gesteuert (siehe AGENTS.md), nicht durch ein Datum; sein Text nennt kein historisches Datum für den Beginn des Krieges oder die Vorbereitungen. Ein Friedenszeitereignis wird blockiert, sobald das Land im Krieg ist. Bevor ein Trigger in den Plan aufgenommen wird, schlage seinen Gültigkeitsbereich mit Find-HoiDoc nach und schlage jedes Tag, jeden Staat und jede Flagge, die es nennt, zu Beginn des Fensters nach (Get-HoiState, Get-HoiCountryHistory, Find-HoiUsage): Ein Trigger, der gültiger Code ist, kann in einem normalen Spiel dennoch niemals wahr werden (ein Land, das zu Beginn nicht existiert, ein Staat, der einem anderen Land gehört). Eine Suche, die der Plan für später verspricht, wird durchgeführt, bevor der Plan READY ist.
3. Überprüfe die Trigger, bevor sie ein Redakteur sieht. Entsende den trigger-checker-Agenten (das Agents/trigger-checker.md des Modding Managers, auf Benutzerebene installiert; Antigravity übergibt diese Datei an invoke_subagent) mit dem Pfad des Plans, den Ereignisschlüsseln und dem Tag des Pakets. Er löst jeden fire.trigger gegen die Spieldateien zum Zeitpunkt von fire.after des Ereignisses auf und antwortet pro Ereignis, ob der Trigger im Fenster wahr sein kann, wie lange er gegen die wöchentliche Überprüfung anhält, ob der Text in einem Fall, den der Trigger zulässt, falsch ist und ob das Fenster zu den Daten des Textes passt. Wende jedes FIX wie angegeben an, führe die geänderten Ereignisse erneut durch ihn und halte das Urteil jedes Ereignisses in der "Trigger-Überprüfung" des Plans fest: OK, das FIX mit dem Trigger, der den alten ersetzt hat, oder OFFEN mit dem Test und seinem Ergebnis oder der Entscheidung des Besitzers. Ein Plan mit einem OFFEN-Ereignis, das weder ein Testergebnis noch eine Besitzerentscheidung hat, ist nicht READY. Die vom Redakteur vorgeschlagenen Bedingungen sind Hinweise für diesen Schritt, keine Trigger.
4. Entsende ep-editor mit dem Pfad des Plans (sein Block markdown fact-sheets ist das Faktenblatt) und den Ereignisschlüsseln. Wende jedes UMSCHREIBEN wie angegeben an; streiche oder ersetze eine ABLEHNUNG (zurück zu Phase 2 für einen Ersatz). Halte jede Runde im "Redakteursprotokoll" fest. Sende die geänderten Ereignisse zurück an den Redakteur, bis jedes Ereignis KEEP ist; höchstens drei Runden, dann frage den Besitzer.
5. Beurteile die Workshop-Einführung des Pakets, source/<key>/workshop-intro.bbcode: Entsende workshop-editor im Mod-Modus (das docs/workshop-text-style.md des Modding Managers (..\..\docs\workshop-text-style.md), Abschnitt "Auditing a page") mit dem Mod-Ordner (dem Repository-Stamm) und dieser Datei, nachdem Test-WorkshopText.ps1 -Mod "Event Packs" -Pack <key> bestanden hat. Die Einführung sagt nur, was die events.json und pictures.json des Pakets zeigen (die Anzahl der Ereignisse, welche Ereignisse ein Epochenbild enthalten, welche Effekte es gibt) und verwendet die Formulierung der Einführungen der anderen Pakete für dieselbe Tatsache. Wende jedes UMSCHREIBEN an, führe -Generate, Sync-WorkshopRegions.ps1 und die mechanische Überprüfung erneut aus, sende dann die Einführung zurück, bis sie KEEP ist; höchstens drei Runden, dann frage den Besitzer. Halte die Runden im "Redakteursprotokoll" fest.

Phase 5: Tor

1. Probiere den Plan durch, ohne das Repository zu berühren: robocopy . scratch\rehearsal /MIR /XD .git scratch artifacts sources-cache, führe dann in scratch\rehearsal die Schritte 1 bis 8 des Plans genau wie geschrieben aus (sie schreiben nur in die Kopie). Jeder Schritt muss ergeben, was er zu erwarten angibt; korrigiere den Plan, nicht die Kopie, und probiere erneut. Schritt 4 bearbeitet die assets\thumbnail.json der Kopie; öffne die Vorschau, die es nennt, mit dem Read-Tool und wähle ein anderes Bild oder einen anderen Beschnitt, wenn das Titelband oder die Flagge das Motiv bedeckt. Schritt 8 zeichnet jedes Ereignis als Fenster des Spiels (scratch\rehearsal\artifacts\workshop-images\<key>/): Öffne die Bilder mit dem Read-Tool und kürze einen Titel oder eine Option, für die der Renderer eine [WARN] ausgibt: Sie läuft über ihre Box in den darunter liegenden Text über [GUW-027].
2. Fülle "Ereignisse" aus, liste im "Bei Beurteilung beibehalten" alle [WARN] auf, die die Probe mit -Check -Pack <key> oder -RenderEvents -Pack <key> ausgegeben hat und die bestehen bleiben, und setze Status: READY.
3. Lösche die Kopie: Remove-Item -Recurse -Force scratch\rehearsal.
4. Markiere die Dossiers in jedem Abschnitt des Schlüssels des Kandidaten (sowohl Dossier als auch Ergänzung):
   • Jedes Ereignis des READY-Plans erhält eine Zeile Used: <Plan-Dateiname> direkt unter seiner ## <key>-Überschrift.
   • Jeder Kandidat, den Phase 3a überprüft hat, einschließlich der ersetzten, erhält dann eine Zeile darunter (unter seiner Überschrift, wenn es kein Used: hat, unter einer früheren Checked:-Zeile): Checked: <Plan-Dateiname>, <K> beibehalten, <F> korrigiert, <D> gestrichen. Die Fakten unten sind die Notizen des Forschers, nicht die überprüften: siehe <wo>. Die Anzahlen stammen aus der "Faktenprüfung". <wo> ist source/<key>/fact-sheets.md für ein Ereignis des Plans und "Faktenprüfung" des Plans für ein ersetztes.
   • Ändere nichts anderes in einem Dossier. Ein nie überprüfter Kandidat bleibt unmarkiert, wie der Forscher ihn geschrieben hat.

Phase 6: Übergabe

Melde dem Besitzer: den Pfad des Plans, die Dossier-Pfade mit der Anzahl der Kandidaten, die sie für später aufbewahren, die Ereignisse mit ihren Titeln, die Bildlizenzen (wie viele PD, CC0, CC BY), das Thumbnail-Bild und den Beschnitt, die Faktenprüfungs-Gesamtzahlen, die Redakteurs-Gesamtzahlen und dass event-pack-implement ihn ausführt. Dann stoppe.

Antigravity: Übergib den Pfad jedes Agenten-Auftrags an invoke_subagent; wenn kein Subagent entsandt werden kann, lies den Auftrag und erledige die Arbeit selbst, wobei die Arbeit des Redakteurs in einem separaten Durchlauf erfolgt, der nur den Entwurf, das Faktenblatt und das Styleguide liest.