DCS Mission Authoring Gateway

dcs-me-gateway ist ein lokaler MCP-Server zwischen einem KI-Missionsdesigner und der DCS-SMS Mission-Editor-Brücke. Er wandelt viele fragile Editor-Befehle in ein kleines, versioniertes Authoring-Protokoll um.

Das Gateway klickt nicht in der UI und fokussiert DCS nie. Anfragen werden in den vorhandenen DCS-SMS-Postkasten geschrieben. Wenn DCS nicht fokussiert ist und die Update-Schleife des Mission Editors gedrosselt wird, bleibt eine Anfrage in der Warteschlange, bis die Ticks wieder aufgenommen werden oder die vom Aufrufer gewählte Frist abläuft.

Implementiert in 0.9

• Fünfunddreißig MCP-Tools: Update-Erkennung, Missions-Authoring/-Validierung, persistente semantische Karte und Hydrologie-Vorverarbeitung, Offline-Abfragen, Live-Karteninspektion, Live-Zuweisung von Luftwaffenstützpunkten und Trägerpaketen, natives Transport-Routing, von DCS erstellte Ladungsermittlung, Live-KI-Aufgabenermittlung, Flugprofil-/Timing-Planung, Paketvorlagen, Zeichnungen, deterministische Missionsdokumente, optionale Skynet-IADS-Einrichtung und begrenztes Offline-Management externer Inhalte.

• Einundvierzig deklarative Patch-Operationen für die Missionsumgebung, Gruppen, Einheiten, Ladungen, Routen, typisierte Wegpunktoptionen/-verhalten, benannte Gruppen-Triggered Actions, Trigger, kreisförmige Zonen, Gruppenfrequenzen und Einheiten-Rufzeichen.

• Stabile logische Referenzen, einschließlich der Übernahme vorhandener benannter Missionsentitäten und von DCS zugewiesener Einheitennamen.

• Die Missionsdesign-Anleitung wird als MCP-Server-Initialisierungsanweisungen beworben, nicht nur als optionale Ressource/Prompt, sodass kompatible Clients die Planungs-, Timing-, Ladungs- und KI-Policy-Standardwerte automatisch erhalten.

• Kompakte semantische Snapshots, deterministische Revisionen, optimistische Nebenläufigkeit und Postcondition-Prüfungen pro Operation.

• Pro-Mission-Bindungen und Idempotenzdatensätze, geschützt durch atomare Schreibvorgänge und Interprozess-Sperren.

• Absolute Anfrage-Ablaufzeiten und explizite OUTCOME_UNKNOWN-Behandlung verhindern späte Ausführung und unsicheres Wiederholen nach einer verlorenen Antwort.

• Ein validierter Patch wird in einem einzigen Mission-Editor-Callback versendet; teilweise übernommene Präfixe werden aufgezeichnet, wenn ein späteres Verb fehlschlägt.

• Vorgefertigte Missionsfragmente verwenden einen dedizierten DCS-SMS-Transaktionsendpunkt mit nativer ID-/Namenszuweisung, Cross-Reference-Remapping, Rollback und Wiedergabeschutz auf Editor-Seite.

• Speichern/Erneut-Öffnen-Verifizierung wartet auf eine stabile semantische Revision und migriert Bindungen über Identitätsänderungen von „Speichern unter" hinweg.

• Feste Kompatibilitätswächter für von DCS-SMS erstellte Fahrzeugrouten und veraltete Routenpanel-Besitzverhältnisse des Mission Editors.

• Kein MCP-Tool für beliebiges Lua.

• Revisionsverfolgte F10-Kartenanmerkungen unterstützen verifizierte Stapel von Kreisen, Linien, Polygonen, Textbeschriftungen und Entfernungen, ohne ein Tool pro Form bereitzustellen.

• Ein datengetriebener Missionsvorlagenkatalog gibt abstimmbare S-300PS/Buk-Standort layouts und gestaffelte AWACS/Tanker-Racetracks zurück. Die beiden SAM-Pakete werden live gegen die installierte DCS-Einheitendatenbank geprüft; sie sind funktionale, repräsentative Ausgangspunkte und keine exakten realen Gefechtsordnungen.

• Trägerpaket-Authoring ermittelt live die Supercarrier-Berechtigung, verfügbare freie/bezahlte Rümpfe und trägerfähige Flugzeuge aus DCS-eigenen Startbahnkategorie-Metadaten. Eine Transaktion kann einen Träger allein oder in einer repräsentativen Blau/Rot-Eskortformation platzieren, Wind über Deck berechnen, unterstützte TACAN/ICLS/Link 4/ACLS-Aktionen verfassen, Flugzeugstarts und optionale Rückkehr-Wegpunkte an das Deck binden und benannte Ladungen plus Kampfverbrauchsmaterial anwenden.

• Grundlegendes Kommunikations-Authoring schreibt Gruppenfrequenzen und normalisierte Einheiten-Rufzeichen. Die Offline-Validierung warnt, wenn AWACS/Tanker-Gruppen eine Frequenz teilen.

• Zwischengespeichertes Gelände kann Koordinaten-/Höhenprofile und Sichtlinien über gerades Gelände mit expliziten Freiraum- und Hindernispunkten beantworten. Gebäude und Vegetation bleiben außerhalb dieses Modells.

• Authoring im Mischmodus umfasst eine deterministische 1024×1440-Militärlicht-Spielerakte und einen Copy-on-Write-.miz-Overlay für externe Inhalte. Die Akte liest Rufzeichen, Flugzeug, Route, Timing, Funkgeräte, Trägerhilfen, Vorräte, Treibstoff, Kanone und Gegenmaßnahmen aus einer festgepinnten gespeicherten Mission; optionale taktische Prosa bleibt explizite Agenteneingabe. Routenseiten verwenden sauberes zwischengespeichertes DCS-Gelände mit deaktivierten semantischen und F10-Overlays. Das Overlay verwaltet Flugzeug-/allgemeine Kniebretter, Briefing-Text und -Bilder sowie begrenzte Bild-/Ton-/Lua-Ressourcen, ohne die Quellmission direkt zu bearbeiten.

• Ein fortsetzbarer Kachel-Cache extrahiert maßgebliche DCS-Höhen- und Oberflächentypen, leitet Steigung, Ausrichtung, Rauheit und Kandidatenmerkmale für Bergrücken/Täler/Pässe ab und rendert sowohl ein sauberes Gelände-PNG als auch ein kommentiertes Kontext-PNG, ohne DCS für spätere Abfragen zu benötigen.

• Eine unabhängig fortsetzbare Hydrologie-Ebene tastet den DCS-Oberflächentyp standardmäßig bei 50 m ab, ohne Höhen, Steigungen oder semantische Regionen neu aufzubauen. Sie packt jede Abtastung in zwei Bits, überspringt hochsichere gleichförmige Land- und offene Meeres-Basiskacheln, leitet begrenzte achtverbundene Fluss-/Seekomponenten mit separat gemeldetem konservativem Kurzlücken-Stitching ab und kann von einem validierten Ausschnitt auf vollständige Datensatzabdeckung mit stabilen Kachel-IDs erweitert werden.

• Jeder Cache speichert von DCS erstellte benannte Orte und Festflugplatz-Metadaten, einschließlich Startbahnschwellen/-längen, Parkhüllen, Shelter-Flags und abgeleiteter Vorfeld-Cluster. Ortsbeschriftungen bleiben explizit ungerankt, weil die DCS-Städtequelle Namen und Koordinaten liefert, nicht Wichtigkeit.

• Ein begrenzter Ankergraph speichert DCS-native Straßen- und Eisenbahnkorridore zwischen nahegelegenen Flugplätzen und benannten Orten, einschließlich Umweg-, Höhen-/Steigungs-, Endpunkt-Snap- und Wasserquerungs-Nachweisen. Live-Routing bleibt für präzise Endpunkte verfügbar, weil der Cache kein vollständiger Straßennetz-Export ist.

• Grobe Siedlungsregionen sind gepufferte benannte Ortscluster mit expliziter Herkunft und empfohlenen Bildansichts-Grenzen. Sie sind keine Gebäudegrundrisse; einzelne Strukturen bleiben eine visuelle Karteninspektionsaufgabe.

• Der semantische Cache speichert auch abfragbare Flugplatz-, Siedlungs- und benannte Ort-Entitäten sowie zusammenhängende Geländeregionen, die aus Oberflächen-, Höhen-, Steigungs-, Rauheits- und Low-Detail-Nachweisen klassifiziert wurden. Regionen verwenden kompakte Zeilenläufe und zeichnen Nachbarschaften auf, statt vorzutäuschen, dass eine Rasterzelle eine reale Verwaltungsgrenze ist.

• Ein fortsetzbarer Makro-Transportgraph verwendet Flugplatz- und Siedlungsknoten. Seine Kanten sind DCS-native Straßen-/Bahnpfade mit gesnappten Endpunkt-Gateways, sodass eine Offline-Abfrage eine mehrkantige regionale Route auswählen kann, während Live-DCS-Routing die Autorität für die exakte erste/letzte-Meile-Konvoigeometrie bleibt.

• Karteninspektion auf Abruf passt die Live-ME-Karte an angeforderte Grenzen an, erfasst nur ihr Karten-Widget, schreibt ein georeferenziertes PNG und stellt die vorherige Kamera wieder her. Eine Kamerabewegungs-Frame-Prüfung lehnt Aufnahmen des versteckten Editors ab (z. B. wenn die F10-Ansicht einer laufenden Mission tatsächlich auf dem Bildschirm ist).

• Die Vorverarbeitung prüft automatisch die Cache-Form, exakte gemeinsame Kachelkanten und 16 deterministische Punkte gegen Live-DCS. Derselbe Bericht kann mit validate_map_dataset erneut ausgeführt werden oder mit deaktivierter Live-Parität für reine Offline-QA.

• Konservative Low-Detail-Erkennung zeichnet ihre Nachweise auf und speichert nur dann eine grobe Kachel, wenn nahezu gleichförmiges Land jeden Schwellenwert besteht; sie setzt gewöhnliches flaches Gelände nicht stillschweigend mit Kaukasus-Randplatzhaltern gleich.

• Von DCS gespeicherte Goldene-Fixtures, Offline-Archiv-/Lua-/Referenztests und eine isolierte Live-Authoring-Harness, die ein Klon bearbeitet, das Original wiederherstellt und seinen Datei-Hash verifiziert.

• Live-Flugplatzplanung verwendet den DCS-Flugzeughüllen-/Kategoriefilter und die reservierten Stände der offenen Mission, den Missions-Oberflächenwind, Startbahnbeschriftungen und einen Stand-zu-wahrscheinlicher-Schwelle-Taxiproxys. Verifizierte Erstellung unterstützt Kalt-, Heiß- und Startbahnstarts für ein bis vier Flugzeuge und entfernt eine teilweise aufgebaute Gruppe, wenn ein Konstruktionsschritt fehlschlägt. Die Strategie für aktive Startbahnen kann die native kompakte Parkplatzwahl auf den verifizierten bevorzugten Standsatz umstellen.

• Preset-first-Ladungs-Authoring fragt die installierte DCS-Build nach benannten Flugzeug-Presets, deren deklarierter Aufgabenkompatibilität, Vorräten und Gewicht ab. Patches können ein Preset anwenden oder eine begrenzte Anpassung pro Pylon vornehmen; das Gateway bittet das Modell nie, CLSIDs oder eine gesamte Ladung zu erfinden. Kampf-Authoring prüft auch explizit Kanonenmunition; ein Kampfflugzeug ohne Kanone wird gewarnt, sofern die Auslassung nicht beabsichtigt ist.

• Live-Aufgabenermittlung listet nur die Wegpunkt- und Enroute-Aktionen auf, die DCS für eine vorhandene Gruppe bereitstellt, und Aufgabenbeschreibungen liefern Standardwerte, zulässige Werte und fehlende Zielauswahl-Hinweise, bevor ein Patch verfasst wird.

• Missionsdatum/-uhrzeit und nützliche Wetterfelder sind in jedem semantischen Snapshot lesbar und als eine revisionsgeprüfte Umgebungsoperation schreibbar. Typisierte Wegpunktoptionen umfassen Reaktion auf Bedrohung, ROE, Radar-/ECM-Nutzung, Bingo-RTB, Funkstille und Nachbrenner-/Abwurfverbote.

• Rollenbasierte Festflügel-Profile und transparente Start-/Roll-/Steig-/Transit-Schätzungen helfen, die Paketankunft zu synchronisieren. Offline-Lint warnt, wenn ein KI-Abfangjäger seinen Transit niedrig oder langsam beginnt.

• Offline-Verhaltens-Lint warnt vor unbewaffneten KI-Kampfflugzeugen, Kampfgruppen ohne Gefechtsauftrag, Zielaufgaben ohne Ziel-IDs, semantischen Wegpunktnamen ohne entsprechendes Verhalten und Luftrouten ohne terminale Landung/Orbit/Schleife. Ziel-Lint warnt auch vor gegensätzlichen Ergebnissen, die beide ausgelöst werden können, Eroberungsbedingungen, die von einem einzelnen überlebenden Gruppenmitglied erfüllt werden, im Briefing benannten Gruppen, die in keiner erkannten Ergebniskondition vorkommen, und Abfangwegpunkten, die Nicht-Luftgruppen zugewiesen sind. Dies sind heuristische Authoring-Warnungen, keine Aussagen über die Laufzeit-KI-Korrektheit von DCS.

Das Gateway beansprucht kein Rollback für deklarative Patches. DCS-SMS-Patch- Verben werden sequenziell in einem ME-Callback ausgeführt; wenn Verb N fehlschlägt, können die Verben 1 bis N-1 bereits übernommen sein. Das Ergebnis zeichnet das übernommene Präfix und den Idempotenzschlüssel auf und verhindert so einen blinden doppelten Wiederholungsversuch. Der separate apply_mission_fragment-Endpunkt verfügt über natives DCS-SMS-Rollback und meldet ein unvollständiges Rollback explizit. Wenn sein bestätigtes Ergebnis oder der Snapshot nach der Anwendung das angeforderte Ergebnis nicht belegen kann, gibt das Gateway OUTCOME_UNKNOWN zurück und verlangt eine Missionsinspektion vor der Wiederherstellung; es tut nie so, als hätte eine fehlgeschlagene Verifizierung die Mutation rückgängig gemacht. Ein zukünftiges transaktionales Patch-Verb wird in docs/dcs-sms-extension.md beschrieben. Da die Live-Semantikrevision keine Lagerinhalte umfasst, blockiert das Gateway konservativ das zwischengespeicherte Wiederholen von Fragmenten, die Lagerwirkungen enthalten; inspizieren Sie die Mission, bevor Sie einen neuen Schlüssel wählen. Zeichnungen sind in semantischen Revisionen und der Speichern/Erneut-Öffnen-Verifizierung enthalten.

Revisionen und Speichern/Erneut-Öffnen-Verifizierung decken die Authoring-Oberfläche des Protokolls 0.1 ab: semantische Umgebungs-, Gruppen-, Einheiten-, Routen-, Trigger-, Zonen- und Zeichnungsdatensätze sowie Missionspfad und Schauplatz. Briefings, Lager und globale Missionsoptionen liegen außerhalb der aktuellen Revisionsgrenze.

DCS persistiert Fahrzeugkurse auf Gruppenebene. Der semantische Snapshot verwendet daher den Kurs des Führungsfahrzeugs für jede Einheit in dieser Fahrzeuggruppe. Ein Versuch, nur einem Nicht-Führungsfahrzeug einen anderen persistenten Kurs zu geben, schlägt bei der Postcondition-Verifizierung fehl, statt nach dem erneuten Öffnen still zu driften.

Anforderungen

• Der Windows-Release enthält seine eigene Node.js-Laufzeit. Die Quellentwicklung erfordert Node.js 20.17 oder neuer.

• Windows, DCS World und die DCS-SMS-ME-Mod nur für Live-Editor-Tools.

• Mission Editor geöffnet mit aktiviertem DCS-SMS -> External execution für Mutationen.

• inspect_map_view erfordert zusätzlich, dass die Mission-Editor-Karte in einem nicht minimierten Fenster geöffnet ist. DCS darf unfokussiert oder abgedeckt bleiben; das Gateway erfasst sein Anwendungsfenster direkt, bringt es nie in den Vordergrund und fällt nicht stillschweigend auf eine okklusionsempfindliche Monitoraufnahme zurück.

Die Kartenextraktion erfordert die typisierten Verben terrain info, terrain sample-grid, terrain list-places, terrain nearest-transport, terrain transport-path, airbase plan-start und airbase create-start im zugehörigen DCS-SMS ME-mod 0.32.4-Worktree.

Windows-Release installieren

Das Release ist eine ZIP-Datei. Es enthält das Gateway, festgeschriebene Produktionsabhängigkeiten, eine portable Node-Laufzeit und den kompatiblen DCS-SMS Mission Editor-Bridge-Quellcode. Es erfordert keine separate DCS-SMS-Installation und installiert weder den DCS-SMS-Missions-Hook noch optionale LuaSec/OpenSSL-Dateien.

Entpacken Sie die ZIP-Datei, schließen Sie DCS und führen Sie aus:

powershell -NoProfile -ExecutionPolicy Bypass -File .\install.ps1 -Clients codex

Unterstützte -Clients-Werte sind codex, claude-code, claude-desktop und generic; es können mehrere übergeben werden. generic schreibt eine portable mcp-config.json. Codex und ChatGPT-Desktop teilen sich die lokale MCP-Konfiguration von Codex. Claude Code und Claude Desktop werden unabhängig registriert. Andere Clients können denselben stdio-Befehl und dieselbe Umgebung aus der generischen Datei verwenden. ChatGPT im Web kann keinen lokalen stdio-Server direkt starten; dieses Paket zielt auf ChatGPT-Desktop/Codex auf dem Rechner ab, auf dem DCS läuft. Siehe die aktuelle OpenAI-MCP-Dokumentation und Claude-Code-MCP-Dokumentation für deren native Konfigurationsoberflächen.

Der Installer:

• erkennt DCS und Saved Games oder akzeptiert -DcsPath und -SavedGames;

• überprüft, dass DCS Full Screen deaktiviert hat, ändert diese Einstellung jedoch nie;

• weigert sich, den Mission Editor zu patchen, während DCS läuft;

• sichert die MissionEditor.lua des Benutzers und jede frühere Bridge;

• installiert den gebündelten GPLv3-Bridge-Quellcode und fügt nur seinen abgegrenzten require-Block zur eigenen Editor-Datei des Benutzers hinzu; und

• registriert nur den vom Benutzer angeforderten dcs-me-MCP-Eintrag und pinnt diesen Eintrag an die ausgewählte Saved Games-Instanz.

Beim MCP-Start prüft das Gateway den neuesten stabilen Release-Endpunkt von GitHub mit einem Timeout von 2,5 Sekunden und einem lokalen Cache von sechs Stunden. Wenn eine neuere semantische Version verfügbar ist, weisen die MCP-Anweisungen den Agenten an, den Benutzer zu fragen, ob er aktualisieren möchte. Die Prüfung installiert nie etwas. Nach ausdrücklicher Genehmigung schließen Sie DCS und jeden MCP-Client, der das Gateway verwendet, und führen Sie dann aus:

powershell -NoProfile -ExecutionPolicy Bypass -File `
  "$env:LOCALAPPDATA\DcsMeGateway\update.ps1"

Der Updater fragt vor der Änderung erneut nach, lädt nur das versionierte Windows-Release herunter, verifiziert dessen separat veröffentlichte SHA-256 und ruft den normalen, sicherungserhaltenden Installer auf. Setzen Sie DCS_ME_GATEWAY_UPDATE_CHECK=0, um die automatische Prüfung zu deaktivieren. check_gateway_update führt eine bedarfsgesteuerte oder erzwungene Prüfung durch. Prerelease-Tags sind absichtlich von diesem Update-Kanal ausgeschlossen.

Für eine agentengeführte Installation übergeben Sie den extrahierten Ordner an einen Agenten und bitten Sie ihn, VIBEINSTALL.md zu befolgen. Nach der Installation starten Sie den MCP-Client neu, öffnen Sie eine Mission im DCS Mission Editor und aktivieren Sie DCS-SMS -> External execution. Dieser Schalter gilt nur für die Sitzung.

Das Gateway ist MIT-lizenziert. Die gebündelte DCS-SMS-Bridge bleibt GPLv3 und wird mit ihrem vollständigen Quellcode und ihrer Lizenz unter payload/bridge geliefert; siehe THIRD_PARTY_NOTICES.md.

Aus dem Quellcode installieren und verifizieren

cd C:\path\to\dcs-me-gateway
npm install
npm test
npm run build
npm run test:golden
npm run test:live

Alles bis einschließlich test:golden ist vollständig offline; DCS kann geschlossen bleiben. Validieren Sie jede gespeicherte Mission unabhängig mit:

npm run validate:miz -- D:\Missions\mission.miz

Der Validator prüft ZIP-Integrität und Entpackungsgrenzen, erforderliche Einträge, wörtliche Lua-Syntax, Missionsstruktur, IDs/Namen, Routen, Koordinaten, Entitätsreferenzen, Wörterbuchschlüssel und gepackte Ressourcen. Er parst Lua in Daten, ohne Missionscode zu laden oder auszuführen.

Gegeben den deklarativen Patch und die unmittelbar davor und danach gespeicherten Dateien, erstellen Sie einen fokussierten Abnahmebericht mit:

npm run report:patch -- patch.json before.miz after.miz [bindings-before.json] [bindings-after.json]
npm run docs:render -- --mission <saved.miz> --dataset <dataset-id> --output <new-directory>

Der Bericht enthält direkte Patch-Ziele, Ein-Hop-Abhängigkeitskontext, Operations-Nachbedingungen, eingeführte/behobene Validierungsbefunde und alle geänderten Entitäten außerhalb dieses Bereichs. Er beendet sich mit einem Nicht-Null-Exitcode, wenn die Nachdatei ungültig ist, eine Nachbedingung fehlschlägt, eine Abhängigkeit unerwartet geändert wurde, nicht zusammenhängende Missionsmetadaten/-optionen/-lager geändert wurden oder eine Entität außerhalb des Bereichs geändert wurde. Patches, die sich auf zuvor erstellte logische IDs beziehen, müssen das entsprechende {"entities": ...}-Bindungsobjekt bereitstellen (vorher und, falls sich Zuweisungen geändert haben, nachher); unaufgelöste IDs werden explizit gemeldet und führen zum Scheitern der Abnahme.

test:live liest nur die Editor-Sitzung. Fügen Sie -- --snapshot für einen Live-, schreibgeschützten Missions-Snapshot hinzu.

npm run test:live-authoring ist absichtlich mutierend. Es erfordert eine gespeicherte Mission, die bereits im Mission Editor geöffnet ist. Der Testrahmen klont diese Mission zunächst per Save-As unter .artifacts/live, bearbeitet nur den Klon, prüft Idempotenz, Revisionskonflikte, Routenbearbeitung, Zonen und Speichern/Neuöffnen-Stabilität, öffnet dann das Original erneut und verifiziert, dass sich dessen SHA-256 nicht geändert hat. Es startet oder fliegt die Mission nicht.

Starten Sie den MCP-Server über stdio:

node C:\path\to\dcs-me-gateway\build\index.js

Ein MCP-Host sollte diesen Befehl und Pfad als stdio-Server namens dcs-me konfigurieren. Diagnosen gehen an stderr; stdout ist für MCP-Frames reserviert.

Konfiguration

Ohne eine Überschreibung liest das Gateway den saved_games-Konfigurationswert von DCS-SMS und wählt dann die Instanz DCS, DCS.openbeta oder DCS.server mit dem neuesten ME-Heartbeat. Setzen Sie DCS_SMS_SAVED_GAMES, wenn Windows Saved Games verschoben wurde und DCS-SMS diesen Pfad nicht in seiner Konfiguration aufgezeichnet hat.

MCP-Werkzeuge

Lebenszyklus des Kartenpakets

Vor der kartenspezifischen Missionsplanung wird der Missionsagent angewiesen, ensure_map_dataset für den Schauplatz aufzurufen. Das Tool verwendet zunächst einen vollständigen lokalen Datensatz, prüft dann die gepackte Registrierung und ihre optionale, auf GitHub gehostete Remote-Registrierung. Ein Download wird gestreamt, durch seine registrierte Byteanzahl begrenzt, gegen seine registrierte SHA-256 geprüft, sicher extrahiert, auf Datensatz-/Schauplatz-Identität und Vollständigkeit validiert und atomar veröffentlicht. Die gepackte Registrierung unter maps/registry.json ist auch die kanonische Remote-Registrierung. Große Datensätze sind unveränderliche, SHA-256-gepinnte GitHub-Release-Assets; Roh-Caches und generierte Archive werden nie in Git eingecheckt.

Wenn kein Paket registriert ist, gibt das Tool permission_required zurück, anstatt DCS zu öffnen oder selbst stundenlange Extraktionen zu starten. Nur nach Zustimmung des Benutzers darf der Agent den Aufruf mit allow_local_build=true wiederholen. Der angeforderte Schauplatz muss installiert und im Mission Editor mit aktivierter externer Ausführung geöffnet sein. Der Build ist fortsetzbar und kann wiederholte Aufrufe erfordern.

Entwickler können einen nicht gehosteten Schauplatz explizit bauen und paketieren:

npm run maps:settlements
npm run maps:build -- --theatre Caucasus
npm run maps:package -- --dataset caucasus-full-v01-250m `
  --base-url https://github.com/ALasek/DCS-ME-gateway/releases/download/maps-v0.9.0

maps:settlements ist ein schneller, unabhängiger Prüfdurchlauf für den aktuell im Mission Editor geöffneten Schauplatz. Es löst den passenden kuratierten Katalog über DCS' autoritative Koordinatenkonvertierung auf, führt DCS-native Ortsbeschriftungen zusammen und schreibt JSON plus ein beschriftetes PNG unter .artifacts/settlements. Es tastet keine Gelände-, Höhen-, Landbedeckungs-, Hydrologie-, Transport- oder Flugplatzdaten ab und baut sie auch nicht neu auf. Verwenden Sie --output <directory>, um einen stabilen Ausgabeort zu wählen.

Der Paketierungsbefehl gibt den genauen Registrierungseintrag aus, einschließlich Archivgröße und SHA-256. Fügen Sie diesen Eintrag zu maps/registry.json hinzu und laden Sie die .tgz in das passende Release hoch. Lokales Bauen ist der Fallback für Karten, die der Projektautor nicht besitzt; es ist niemals implizite Zustimmung.

preprocess_map_region validiert das angeforderte Rechteck gegen DCS' autoritative Schauplatzgrenzen. DCS' 4.096-Grenze gilt für Abtastwerte in jeder Geländegitter-Anfrage, nicht für Datensatzkacheln. max_tiles ist nur eine bewusste Datensatzgrößen-Sicherung (standardmäßig 50.000); tile_batch_limit begrenzt jeden MCP-Aufruf standardmäßig auf 200 fehlende Kacheln. Wenn das Ergebnis complete=false hat, wiederholen Sie den Aufruf mit identischer Datensatzgeometrie und Abtasteinstellungen. Jede Kachel- und Manifestaktualisierung ist bereits dauerhaft, unvollständige Datensätze lehnen normale Abfragen ab, und die endgültige Validierung kann unlesbare, fehlerhafte oder nahtungültige Kacheln für die automatische Reparatur im nächsten Batch entfernen. Änderungen an Batchgröße und Sicherheitsvorkehrungen ändern keine automatisch generierte Datensatz-ID. Seine north/east-Koordinaten sind dieselben schauplatzlokalen Meter, die von Missionsobjekten verwendet werden. Der standardmäßige konservative Vorlauf kann hochkonfidentes gleichmäßiges Meer oder platzhalterartiges gleichmäßiges Land in grober Auflösung beibehalten; jede solche Entscheidung ist im Manifest und im Abfrageergebnis sichtbar. Küstenlinien, gemischte Oberflächen und flaches Gelände, die nicht alle Schwellenwerte erfüllen, bleiben in voller Auflösung. Flugplätze und von DCS erstellte Ortsbeschriftungen werden neben den Geländekacheln gecacht und auf Vorschauen annotiert. Ortsdatensätze werden nicht als Stadt/Ort/Dorf klassifiziert, da die DCS-Quelle diese Unterscheidung nicht offenlegt. Die semantische Herkunft zeichnet den DCS-Build, das Gebietsschema und die Schauplatz-Ortsquelle auf; Orts-IDs werden aus Koordinaten abgeleitet, da doppelte Lua-Schlüssel überschrieben werden, wenn DCS einige Schauplatzdatensätze lädt. Ein geänderter DCS-Geländebuild erfordert einen expliziten force=true-Neubau, anstatt veraltete Kacheln stillschweigend wiederzuverwenden. query_map_context, query_airbase_context und query_transport_context lesen nur den Cache, sodass DCS geschlossen sein kann. Die 200-m-Vorfeld-Clusterung und die kompakten/standard/großen Hüllenbänder sind Navigationsheuristiken, keine DCS-Kompatibilitätsansprüche. plan_airbase_start prüft vor der Mutation immer das angeforderte Flugzeug und die aktuelle Belegung über DCS erneut.

render_mission_documents ist deterministisch für dieselbe gespeicherte Mission, denselben Gelände-Cache, dieselbe Stilversion, dieselben ausgewählten Gruppen und denselben gelieferten Prosa-Text. Standardmäßig wählt es Player/Client-Flüge aus. Es erzeugt ein Manifest und bereite kneeboard_images-Einträge, modifiziert aber nicht die Mission. DCS-Kneeboard-Ordner können auf alle Flugzeuge oder einen Flugzeugtyp zielen; sie können nicht zwei Flüge mit demselben Typ unterscheiden, daher kombiniere diese Anweisungen oder verwende Briefing-Seiten, wenn eine flugspezifische Trennung erforderlich ist. Die Missionskarte identifiziert den Flugzeugtyp, ohne eine Menge pro Flug zu implizieren. Die Comms/Loadout-Seite verwendet kanonische, menschenlesbare Store-Namen, Treibstoff in Pfund und Kanonenmunition als Prozentsatz; sie zeigt niemals interne CLSIDs an. Wenn die gespeicherte Mission Stores, aber keinen lesbaren Preset-Namen hat, rufe get_aircraft_loadouts mit include_stations=true auf und übergib deren von DCS erstellte Anzeigenamen in flight_notes.loadout_summary. Das Rendering gibt dann eine explizite Warnung aus, bis diese Namen geliefert werden. Wegpunkttabellen verwenden verifizierte ETA-Werte der gespeicherten Route, wenn die Route tatsächlich geplant ist; zustandsgesteuerte oder spielergetaktete Ereignisse können stattdessen flight_notes.waypoint_notes[].time_label für Hinweise und Zeitfenster verwenden, ohne eine feste Uhrzeit zu erfinden. Das Rendering warnt, wenn eine Multi-Wegpunkt-Player-Route weder brauchbare ETA-Werte noch Zeitbeschriftungen hat. Routenkarten fügen nur spärliche Beschriftungen für Luftwaffenstützpunkte und größere Siedlungen hinzu, wobei Routen- und Wegpunktbeschriftungen Kollisions- und visuelle Priorität behalten. Vorschau jeder Seite, bevor du sie einbettest.

apply_miz_overlay ist bewusst kein allgemeiner Missions-Editor. Speichere die Live-ME-Mission, schließe oder öffne eine andere Datei, prüfe vorhandene externe Inhalte, pinne den gemeldeten SHA-256 der Quelldatei und schreibe in einen neuen Ausgabepfad. Das Tool validiert echte Bild-/Ton-/Skript-Signaturen, lehnt das Löschen referenzierter Ressourcen ab und bereinigt ersetzte Briefing-Bilder nur dann per Garbage Collection, wenn keine Missionsreferenz mehr besteht. Nachdem der Overlay erfolgreich war, öffne die Ausgabe in ME und führe save_and_verify aus. Kerngruppen, Routen, Trigger und Ziele bleiben ME-verfasst; dies verhindert, dass zwei Autoren stillschweigend bei derselben .miz voneinander abweichen.

Optionales Skynet-IADS

Für ein aussagekräftiges Multi-Site/EWR-Netzwerk, ein SEAD/DEAD-Szenario oder eine Mission, deren Balance von Radar-Emissions-Taktiken abhängt, kann der Agent Skynet einmal empfehlen und fragen, ob der Benutzer laufzeit-skriptabhängiges Verhalten akzeptiert. Es sollte nicht bei jedem isolierten SAM-Design mit dieser Frage unterbrechen. Native DCS-Alarmzustände und deterministische Emissions-Trigger bleiben der Standard für isolierte, vorhersehbare oder Trainings-Bedrohungen.

Nach der Annahme gib verwalteten SAM-Gruppennamen ein gemeinsames Präfix und verwalteten EWR-Einheitennamen ein eigenes Präfix, speichere die Mission und rufe setup_iads mit dem SHA-256 der gespeicherten Datei und einem neuen Ausgabepfad auf. Das Tool verifiziert und bettet Skynet-IADS 3.3.0 mit seinem upstream-getesteten MIST 4.5.107 ein und fügt dann einen Mission-Start-Trigger hinzu, der MIST, Skynet und die generierte Konfiguration in dieser Reihenfolge lädt. Die resultierende .miz ist in sich geschlossen; Spieler müssen nichts installieren. Öffne die Ausgabe im Mission Editor und führe save_and_verify aus, bevor du fortfährst.

Das Setup validiert Skript-Hashes, Ladereihenfolge, Koalitionszugehörigkeit, Präfixe und benannte Kommandozentralen. Es kann das IADS-Laufzeitverhalten nicht beweisen, ohne die Mission auszuführen. Behalte einen SAM-Systemtyp pro verwalteter SAM-Gruppe, ein EWR-Radar pro verwalteter EWR-Gruppe und füge keine nativen Emissions-Aktionen hinzu, die mit Skynet um dieselben Radargeräte konkurrieren. Herkunft, exakte Hashes und Lizenzen sind unter vendor/skynet-iads/3.3.0 und THIRD_PARTY_NOTICES.md dokumentiert.

analyze_terrain_line interpoliert bilinear das feinste gecachte Raster, das jede Stichprobe abdeckt, und meldet clear, blocked oder indeterminate. Der Klassifikator verwendet eine explizite Höhenauflösungs-Hüllkurve: clear und blocked erfordern, dass die gesamte Hüllkurve auf einer Seite der Sichtlinie bleibt. Der Nur-Cache-Modus meldet den unsicheren Korridor und den empfohlenen Abstand, ohne DCS zu kontaktieren. refinement_mode=auto-live beprobt diesen begrenzten Korridor aus einem passenden geöffneten Mission-Editor-Theater, teilt ihn auf das Pro-Aufruf-Stichprobenlimit der Erweiterung auf, persistiert die feineren Kacheln unter dem Datensatz und führt die LOS sofort erneut aus. Spätere Abfragen verwenden diese Kacheln bei geschlossenem DCS wieder. Ein feiner erneuter Lauf kann berechtigterweise unbestimmt bleiben; die Antwort meldet ein Auflösungslimit und, wo möglich, einen kleineren nächsten Abstand, anstatt eine clear/blocked-Antwort zu erfinden. Dies ist für Radar/SAM-Platzierung und Routen-Screening geeignet, aber nicht für endgültige Sichtbarkeitsaussagen, bei denen Gebäude oder Bäume eine Rolle spielen.

Nachdem die Geländekacheln fertig sind, leitet die semantische Vorverarbeitung ein 2-km-Klassifikationsraster ab, glättet isolierte Nicht-Wasser-Zellen und wandelt jede vierfach zusammenhängende Komponente in eine kompakte Geländeregion mit Statistiken, Adjazenz und Zeilenlauf-Geometrie um. Luftwaffenstützpunkte und Siedlungscluster werden zu Graph-Hubs. Straßenkandidaten umfassen bis zu vier Nachbarn innerhalb von 80 km plus begrenzte Konnektivitätsreparatur; Eisenbahnkandidaten umfassen bis zu zwei Nachbarn innerhalb von 120 km. Die DCS-Eisenbahnroutenplanung wird als Kandidatenhinweis behandelt, da ihr Geländenetzwerk-Selektor nicht zusammenhängende lineare Merkmale zurückgeben kann. Ein gecachter Schienenkorridor muss innerhalb von 1,5 km an beiden Ankern einrasten und seine geroutete Länge muss mindestens die Hälfte ihrer direkten Trennung abdecken; schwächere Ergebnisse bleiben fehlgeschlagene Kandidaten zur Inspektion, anstatt dem Agenten als Schiene ausgesetzt zu werden. transport_batch_limit begrenzt die Live-DCS-Pfadextraktion pro Aufruf, und der Status ausstehender/abgeschlossener/fehlgeschlagener Kanten ist dauerhaft und fortsetzbar. Abgeschlossene Polylinien behalten Hub-IDs und eingerastete Gateway-Punkte. query_transport_context verwendet Dijkstra über abgeschlossene gecachte Kanten für eine Offline-Route zwischen benannten Hubs; route_ground_transport wendet dieselben konservativen Schienenprüfungen auf exakte aktuelle DCS-Pfade an, die für die Missionserstellung verwendet werden. Wasserflächen-Läufe werden als water-crossing-candidate gekennzeichnet, nicht als zerstörbare Brückenobjekte behauptet. Siedlungs-Clustering vermeidet bewusst einen Pro-Gebäude-Katalog, der geländeversionsempfindlich und unnötig groß wäre.

Der Persian-Gulf-Prozessor ergänzt die eigenen Ortsbeschriftungen von DCS um den spärlichen, bearbeitbaren Katalog unter maps/settlements/persian-gulf.json. Er enthält Großstädte, Häfen und Insel-Siedlungen, die für ein ungefähres Szenario-Vokabular von 1980–1990 ausgewählt wurden; er ist kein historischer städtischer Fußabdruck. Während der Vorverarbeitung wandelt DCS jeden WGS84-Punkt in die lokalen Koordinaten des geladenen Theaters um. Passende nahegelegene DCS-Beschriftungen behalten ihre DCS-Position, während sie den kuratierten Namen, Aliase, Typ und Bedeutung erhalten. Ein eigenständiger kuratierter Punkt bleibt nur regionale semantische Evidenz. Katalog-SHA-256 und Quellen-/Epochen-Herkunft werden in semantics.json gespeichert, sodass die Bearbeitung des Katalogs gecachte Siedlungs- und Transport-Semantik ungültig macht und neu aufbaut, ohne Höhenkacheln neu zu erstellen. Siehe maps/settlements/README.md für das absichtlich einfache Bereinigungsformat.

query_map_context kann mit Grenzen, einer semantic_search oder beidem aufgerufen werden. Die semantische Suche kann Geländeklassen, minimale Regionsfläche, Nähe zu einer Entität, Entitätsart/-name und ungefähren Straßenzugang filtern, ohne Geländekacheln zu laden oder DCS zu erfordern. inspect_map_view ist der komplementäre Detailpfad: Es cached nicht jedes Gebäude oder jede Straßenmarkierung, sondern gibt die aktuelle ME-Darstellung im angeforderten Maßstab mit einer affinen Pixel-zu-Theater-Transformation zurück. Es schreibt vorübergehend die ME-Kartenkamera, serialisiert gegen andere Gateway-Mutationen und stellt die vorherige Kamera wieder her, selbst wenn die Erfassung oder Sichtbarkeitsvalidierung fehlschlägt. Es löst das exakte DCS-Fensterhandle auf und schlägt mit Fenstergeometrie und Wiederherstellungsdetails fehl, wenn DCS minimiert ist oder ein exklusiver Vollbild-Alt-Tab seine erfassbare Oberfläche entfernt hat. Randloses/Fenstermodus-DCS kann während der Inspektion hinter dem MCP-Client bleiben. Wenn ein Luftwaffenstützpunkt, ein Siedlungscluster und ein roher DCS-Ort denselben Namen teilen, verwende die zurückgegebene Entitäts-ID oder einen kind:name-Selektor wie settlement:Batumi oder airbase:Batumi; mehrdeutige bloße Namen schlagen fehl, anstatt stillschweigend einen auszuwählen.

Führe den lokalen geschichteten Cache-Viewer mit npm run viewer während der Entwicklung oder npm run viewer:start nach npm run build aus und öffne dann http://127.0.0.1:4317. Er visualisiert die saubere gecachte Topografie, zusammenhängende Geländeregionen, brauchbare und fehlgeschlagene Transportkanten, Siedlungshüllen, semantische Entitäten und Beschriftungen, ohne DCS zu kontaktieren.

validate_map_dataset streamt Kachel-Lesbarkeits- und Array-Prüfungen, vergleicht nur benachbarte gemeinsame Kanten und materialisiert die vollständige Karte nicht im Speicher. Sein Standard-direct_samples=16 vergleicht gleichmäßig verteilte gecachte Punkte mit dem aktuell geladenen DCS-Theater; verwende direct_samples=0 für die Nur-Offline-Prüfungen. Der Bericht wird auch als validation.json unter dem Datensatzverzeichnis gespeichert. Die Übersicht des abgeschlossenen Datensatzes wird ebenfalls Kachel für Kachel in sein begrenztes Ausgaberaster gemalt.

Die begrenzte Kaukasus-Entwicklungsumgebung beprobt bewusst den detaillierten Batumi-Kobuleti-Küste-zu-Berg-Streifen statt des flachen äußeren Bereichs der Karte:

npm run test:live-map

Sie beprobt north=-370000..-330000, east=610000..670000 bei 250 m, persistiert den Fortschritt nach jeder Kachel und kann sicher erneut ausgeführt werden. Füge -- --force nur hinzu, um bereits gecachte Kacheln absichtlich zu aktualisieren. Sie verarbeitet nicht die gesamte Karte.

Hydrologie-Verfeinerung

Der 250-m-Geländecache wird absichtlich nicht als maßgebliche Flussgeometrie behandelt: Ein schmaler Fluss kann zwischen Rasterpunkte fallen und als spärliche blaue Punkte erscheinen. preprocess_hydrology_layer fügt einen separaten hydrology/-Cache zu einem vorhandenen abgeschlossenen Datensatz hinzu. Sein Standard-50-m-Raster speichert nur einen kompakten Zwei-Bit-Oberflächencode pro Stichprobe; Höhe und Geländeableitungen bleiben in ihrer Basisauflösung. Basiskacheln, die bereits als gleichförmiger Platzhalter-Land oder offenes Meer nachgewiesen wurden, werden von der Planung ausgeschlossen, während detaillierte und gemischte Küstenkacheln beprobt werden.

Beginne mit repräsentativen Grenzen und wiederhole identische Aufrufe, bis completeForBounds=true. Lasse später bounds weg, um dieselbe Schicht über alle detaillierten Basiskacheln zu erweitern. tile_batch_limit begrenzt jeden Aufruf und max_tiles ist nur eine bewusste Sicherheitsobergrenze. Ein geänderter Abstand, eine geänderte Kachelgröße, ein geändertes Theater oder eine geänderte DCS-Geländesignatur schlägt geschlossen fehl; force=true beginnt bewusst eine neue Hydrologie-Aktualisierung und nachfolgende fortsetzbare Aufrufe verwenden force=false. query_map_context gibt Abdeckung, exakte begrenzte Oberflächenzählungen, deterministische Stitch-Metriken und beprobte achtfach zusammenhängende Fluss-/Seekomponenten zurück, wenn die Schicht existiert. Seine Vorschau- und sauberen Dokumentationskarten integrieren die feinere Wassermaske.

Die ursprünglichen DCS-Codes und Oberflächenzählungen bleiben unveränderlicher Nachweis. Ein Offline-Richtungs-Stitcher darf höchstens zwei fehlende Zellen auffüllen, wenn Quellproben an beiden Enden entlang derselben Linie weiterlaufen; abgeleitete Zellen werden separat gemeldet und dienen nur der Komponentenkontinuität und Darstellung. Dies ist bewusst konservativer als ein uneingeschränktes morphologisches Schließen, das nahe beieinanderliegende, nicht zusammenhängende Wasserläufe verschmelzen kann. Die Komponentengeometrie ist weder ein Bankpolygon noch eine Navigationsgarantie. Flüsse, die schmaler als der gewählte Abstand sind, können weiterhin fragmentiert sein; verwenden Sie daher einen engeren begrenzten Durchlauf oder eine Live-Kartenprüfung, wenn es auf die exakte Uferplatzierung ankommt. Grobe Platzhalter-Land- und einheitliche Meeres-Basiskacheln mit hoher Konfidenz liegen bewusst außerhalb der Hydrologie-Abdeckung; diese Optimierung setzt voraus, dass die grobe Basis-Kalibrierung das Nicht-Missionsgelände der Karte bereits von echten detaillierten Ebenen getrennt hat. Der Viewer legt die erzeugte Ebene als separat umschaltbares Overlay Rivers / lakes offen. Die Darstellung ist abgeleitet und nicht beweiskräftig: Seen behalten eine geglättete Stichproben-Flächenrasterung, während Flussbänder deterministisch ausgedünnt, konservativ lückenverbunden, vereinfacht und als anti-aliased SVG-Mittellinien mit fester Bildschirmbreite gezeichnet werden. Abfragen und Validierung verwenden weiterhin die ursprünglichen gepackten Zellen und separat identifizierten Stichpunkte.

Das vollständige Patch-Schema wird auch als MCP-Ressource dcs-me://schema/mission-patch/0.1 bereitgestellt. Siehe examples/f16-rwr-patch.json und das zugehörige examples/f16-rwr-route-patch.json.

Die Erstellung ganzer Missionen sollte mit dem MCP-Prompt design_dcs_mission beginnen. Er führt ein Gespräch, anstatt eine Ein-Schuss-Spezifikation zu verlangen: Der Agent kann wirkungsvolle Fragen stellen, Standardwerte empfehlen, Alternativen vorschlagen und eine laufende Aufzeichnung über Spielerrolle, Ergebnis, Phase, Zweck pro Gruppe, kausale Interaktion, Fähigkeiten/Beladung und Balance führen. Die kanonische menschenlesbare Anweisung ist docs/design-dcs-mission.md; der Server lädt dieselbe Datei für Initialisierungsanweisungen, den MCP-Prompt und die Leitfaden-Ressource. Ein kohärentes Rückgrat und ein erster Ausschnitt gehen der Mutation voraus, aber spätere Details können offen bleiben, während genehmigte Ausschnitte erstellt und getestet werden. Dieselbe Anweisung ist als schreibgeschützte Ressource dcs-me://guidance/mission-design/0.1 verfügbar. Missionskonzepte werden mit dem Benutzer entwickelt und inkrementell umgesetzt, um die Bindungsbarrieren des Mission Editors zu respektieren.

Das Schema für vollständige Fragmente wird unter dcs-me://schema/mission-fragment/0.1 bereitgestellt. Es akzeptiert das Datenmodell, das von einem DCS-SMS-Prefab verwendet wird (meta, groups, statics, zones, drawings und triggers), plus eine explizite Platzierungsrichtlinie. Der Endpunkt führt seine Vorabprüfung und Mutation innerhalb des Mission Editors aus, sodass für den Aufruf DCS erforderlich ist; das Entwickeln und Ausführen der Repository-Testsuiten erfordert dies nicht.

Das Schema für hochrangige Trägeranfragen wird unter dcs-me://schema/carrier-package/0.1 bereitgestellt. Fragen Sie zuerst get_catalog mit kind=carrier_capabilities ab, um die Rümpfe, Berechtigungen, trägerkompatiblen Flugzeuge und Geleitschutztypen der offenen DCS-Installation zu prüfen. dry_run=true gibt das kompilierte Fragment und den aufgelösten Wind-über-Deck-Plan zurück, ohne die Mission zu ändern. Die automatische Modulauswahl bevorzugt Supercarrier, wenn DCS es als installiert und autorisiert meldet, und wählt andernfalls den kostenlosen Träger der Koalition.

Das Schema für hochrangige Flugplatzanfragen wird unter dcs-me://schema/airbase-start/0.1 bereitgestellt. create_airbase_start erfordert einen geöffneten Mission Editor, prüft die angeforderte semantische Revision und den Idempotenzschlüssel, führt eine Vorabprüfung freier kompatibler Stellplätze durch, ruft das native DCS-SMS-Konstruktionsverb auf und verifiziert dann Gruppengröße, Flugzeugtyp, Flugplatzverknüpfung von Wegpunkt null, Startmodus und explizite Parkplatz-IDs in einer frischen Momentaufnahme. Die Standard-Parkstrategie active_runway verwendet Oberflächenwind und Startbahnbezeichnungen, um freie kompatible Stellplätze nach geradlinigem Schwellenabstand zu ordnen, und verifiziert dann die Neuzuweisung; compact bewahrt die ursprüngliche DCS-SMS-Auswahl nahegelegener Gruppen. Dieser Abstand ist ein Roll-Proxy, keine garantierte Routenzeit. Feste Landflugplätze verwenden diesen Endpunkt; Deckslots von Trägern verwenden setup_carrier_package. FARPs bleiben eine separate zukünftige Oberfläche.

Triggerfeldwerte können mit "$ref:<logical_id>" auf eine frühere logische Entität verweisen; der Compiler setzt deren stabilen DCS-Namen ein. Ein Verweis auf eine benannte Triggered Action wird unmittelbar vor dem Hinzufügen der Triggeraktion in das aktuelle {groupId, taskNumber}-Tupel von DCS aufgelöst. index-Werte von Routenpunkten in Momentaufnahmen und jedes waypoint_index in Patches sind nullbasiert. Triggerregelindizes und Triggered-Action-Slots bleiben einsbasiert.

Unterstützte Operationen sind:

• Vorhandene Entitäten: adopt_entity für exakte Gruppen-, Einheiten-, Trigger- oder Zonennamen.

• Gruppen: create_group, set_group_task, set_group_late_activation, remove_group. Setzen Sie lead_logical_id bei create_group, wenn spätere Patches deren erste Einheit adressieren müssen; das Gateway bindet den von DCS zurückgegebenen Namen.

• Einheiten: add_unit, set_unit_skill, set_unit_heading, set_unit_loadout, set_unit_payload, clear_unit_payload, remove_unit. Verbrauchsmaterialien der Nutzlast: set_unit_fuel, set_unit_chaff, set_unit_flare und set_unit_gun.

• Routen: add_waypoint, insert_waypoint, remove_waypoint, link_waypoint_airbase.

• Wegpunktverhalten: add_waypoint_task, add_waypoint_enroute_task, remove_waypoint_task, remove_waypoint_enroute_task, clear_waypoint_tasks, clear_waypoint_enroute_tasks und die typisierte Operation set_waypoint_option. Aufgaben-fields akzeptieren verschachtelte JSON-ähnliche Arrays und Datensätze, einschließlich Selektoren wie targetTypes: ["Air"].

• Gruppen-Triggered Actions: add_triggered_task, replace_triggered_task und remove_triggered_task. Diese erstellen Aufgaben-/En-Route-Aufgabeneinträge mit stabilen Namen; verwenden Sie die logische Aufgaben-ID in einem a_ai_task- oder a_set_ai_task-Triggeraktionsfeld. Entfernen Sie die referenzierende Triggeraktion, bevor Sie die Aufgabe entfernen.

• Umgebung: set_mission_environment für Datum/Uhrzeit, Temperatur, QNH, Sichtweite, Turbulenz, Wind auf drei Ebenen, Wolken und Staub.

• Trigger: create_trigger, add_trigger_condition, add_trigger_action, remove_trigger_condition, remove_trigger_action und remove_trigger.

• Zonen: create_zone_circle, remove_zone.

Die Routenbearbeitung für eine Gruppe, die im selben Patch erstellt wurde, erfordert einen nachfolgenden Patch, damit der Mission Editor den Aufbau ihres Routenzustands abschließen kann. Das Bearbeiten oder Entfernen einer durch add_unit erstellten Einheit oder eines durch create_group.lead_logical_id deklarierten Leitelements erfordert ebenfalls einen nachfolgenden Patch, da DCS den endgültigen Einheitennamen im Operationsergebnis vergibt. Die Validierung meldet diese als explizite Barrierenfehler, bevor eine Mutation ausgelöst wird.

Preset-first-Workflow für Flugzeuge

Rufen Sie für ein bewaffnetes Flugzeug get_aircraft_loadouts mit aircraft_type und intended_task auf. Bevorzugen Sie ein von DCS erstelltes Preset, das Kompatibilität mit dieser Aufgabe deklariert; wenn mehrere übereinstimmen, wählen Sie das moderate, klar benannte Preset, dessen Außenlasten zur Mission und erwarteten Reichweite passen. Fordern Sie include_stations=true für das ausgewählte Preset an, bevor Sie Anpassungen vornehmen. Wenden Sie es mit set_unit_loadout an und verwenden Sie set_unit_payload oder clear_unit_payload nur für eine explizite Anforderung, die das Preset nicht erfüllt. Ein benanntes DCS-Preset ändert nur Pylonen: Vergleichen Sie die geerbten Treibstoff-/Chaff-/Flare-/Geschützwerte der Einheit mit den zurückgegebenen Flugzeugmaxima und Standard-Gegenmaßnahmenwerten und setzen Sie ungeeignete Werte explizit. Zündereinstellungen/Programmeinstellungen pro Außenlast sind noch nicht Teil des eingeschränkten Patch-Schemas des Gateways.

Die Auflistung der Außenlasten ist ein gateway-eigener schreibgeschützter Adapter über DCS Mission Editor me_loadoututils, kein formales DCS-SMS-Verb. Sie ist daher versionsempfindlich, schlägt fehl, wenn sich die Mission-Editor-API ändert, und wurde gegen den lokal installierten DCS-Build verifiziert, anstatt als stabile Eagle-Dynamics-Schnittstelle beansprucht zu werden.

Für KI-Verhalten rufen Sie zuerst get_ai_task_catalog für die tatsächliche Gruppe und Aufgabenart auf, dann describe_ai_task. EngageGroup/AttackGroup erfordern eine numerische groupId; Einheitenvarianten erfordern unitId; EngageTargetsInZone erfordert schauplatzlokale x (Norden) und y (Osten). Verwenden Sie IDs aus der aktuellen semantischen Momentaufnahme. Ein Aufgabenname allein ergibt keine gültige Zielzuweisung.

Sicherheitsgrenze

Die zugrunde liegende DCS-SMS-Brücke führt Lua in der vollständigen Mission-Editor-Umgebung aus. Dieser Server beschränkt generierten Code auf einen festen Batch-Dispatcher und JSON/base64-serialisierte DCS-SMS-Verbaufrufe. Halten Sie ihn lokal, setzen Sie seine stdio nicht über einen unauthentifizierten Netzwerkdienst aus und lassen Sie die External-Ausführung deaktiviert, wenn sie nicht benötigt wird.

Der Offline-Validator und der Patch-Bericht verwenden nicht die DCS-SMS-Mailbox und erfordern weder eine installierte noch laufende DCS-Instanz. Sie stellen nur strukturelle und referenzielle Integrität her. Sie können nicht beweisen, dass DCS das Archiv lädt, es beim Speichern identisch normalisiert oder dass Laufzeit-KI, Sensoren, Trigger und Waffen wie beabsichtigt funktionieren; diese bleiben explizite spätere Akzeptanzschichten.

Lizenz

MIT. DCS-SMS ist ein separates Projekt; sein tools/-Baum ist GPLv3.

Erstellen eines Windows-Releases

Der Release-Builder kompiliert das Gateway, installiert nur gesperrte Produktions-npm-Abhängigkeiten in das Staging, lädt eine offizielle Node-Windows-Distribution herunter und verifiziert deren veröffentlichten SHA-256, kopiert die exakt kompatible DCS-SMS-Brückenquelle und den GPL-Text, inventarisiert npm-Lizenzen, schreibt ein Manifest pro Datei und erzeugt eine ZIP-Datei plus Prüfsumme:

npm run release:windows -- -DcsSmsSource C:\path\to\dcs-sms

Bis die angepasste Brückenquelle 0.32.4 committet und veröffentlicht ist, müssen Releases aus dem verifizierten lokalen DCS-SMS-Arbeitsbaum erstellt werden. Die generierte Datei payload/bridge/SOURCE.md dokumentiert ihre Basisrevision und ob der Arbeitsbaum verschmutzt war; die vollständige entsprechende Brückenquelle befindet sich im selben Paket.