Operation Midgardflamme

Kein Seitenwechsel mehr: Das Vic spiegelte sich auf dem Rückschenkel des Racetracks. Eine gemeinsame Gruppe scheidet aus (nur der Führer wäre voller Tanker mit Funk/TACAN; dazu das Kurvenproblem). Lösung: Kolonne — Korb (MPRS) vorn, Boom 1-1 1 km dahinter, Boom 1-2 2 km dahinter, alle auf derselben Linie. Gleiche Strecke + gleiche Geschwindigkeit → die Reihenfolge bleibt durch jede Kurve konstant.

Höhenstaffel entfällt zwingend: Verschiedene Höhen bei gleicher CAS = verschiedener TAS → die Kette (und vorher das Vic) wäre auseinandergedriftet. Alle drei wieder 7010,4 m / 213,16 m/s (kalibrierte ~300 kt CAS). Kollisionsrisiko: keins, Tanker sind unverwundbar. Kennung der Zweit-Booms weiterhin über die Bemalung (blau: TurAF-Flash, rot: USAF-grau) + Reihenfolge in der Kette. Geometrie im Bau verifiziert (1000/1000/2000 m, beide Seiten).

CAS-Nachkalibrierung: Die Vic-Höhenstaffel (7210/7410 m) senkte bei unverändertem TAS die Anzeige auf ~296 kt. ISA-Dichteskalierung der kalibrierten 213,16 m/s@7010 m: Boom L (7210 m) → 215,63 m/s, Boom R (7410 m) → 218,12 m/s; Korb unverändert. Alle wieder ~300 kt CAS.

Visuelle Unterscheidung der beiden Booms (Rufnamen bleiben, wie vom Nutzer gewünscht): Der Zweit-Boom (-3) trägt je Seite die JEWEILS ANDERE Bemalung — blau: „TurAF Standard" (roter Leitwerks-Flash), rot: „Standard USAF". Dazu als Merkregel die Höhenstaffel: 1-1 unten (FL236), 1-2 oben (FL243).

Funkmenü-Reihenfolge: Arrayposition + groupId von Korb (-2) und Zweit-Boom (-3) getauscht → das DCS-Menü listet jetzt „Texaco 1-1, Texaco 1-2, Arco 1-1" (bzw. Arco/Arco/Texaco bei Rot). Unit-IDs unverändert (TACAN-Beacons referenzieren unitId).

Tanker-Vic-Formation (Nutzerwunsch): je Seite fliegen alle drei Tanker jetzt als umgekehrtes V auf dem bewährten Orbit der -1er — Korb vorn (KC-135 MPRS, FL230), die beiden Booms je 1000 m schräg dahinter (600 m seitlich, 800 m zurück; Boom-Boom-Abstand 1200 m), höhengestaffelt +200 m / +400 m. Geometrie im Bau verifiziert (1000/1000/1200 m, 7010/7210/7410 m, beide Seiten). Weiterhin getrennte Gruppen (DCS-Kurvenproblem); gleiche Tracklänge und Geschwindigkeit halten die Formation in Phase. Auf dem Rückschenkel des Racetracks spiegelt sich das V systembedingt.

Tanker-Rotte statt Front-Orbit: Tacview zeigte Bugsy-BLUE-3 bei Minute 60 über Gudauta (Frontbereich) — der 30-km-Versatz der achten Fassung zeigte zur Front. Die -3er fliegen jetzt als versetzte Rotte neben den -1ern: gleicher Orbit + 2,5 km seitlich (frontabgewandt) + 300 m höher (FL240). Bewusst eigene Gruppen (in einer Gruppe treibt DCS den Außenmann in Kurven unfliegbar hoch — Nutzer-Report).

Auto-Restart verpasste das Missionsende: Log 15:42–15:45: Sieg erkannt, Lied geplant, Flag 9003 gesetzt, Mission endete planmäßig — aber zwischen Flag und Simulationsstopp lagen ~2 s, der Hook pollte nur alle 10 s → kein Neustart („Mission endet nicht"-Eindruck). Fix doppelt: a_end_mission mit 12 s Verzögerung (trig + trigrules) und Hook-Poll auf 2 s.

Siegeslied nicht mehr abwürgbar: Der SA-11-Kauf um 15:43 ersetzte das laufende Lied durch den Deploy-Jingle (outSound ersetzt den aktiven Sound). Ab Sieg gilt MIDGARD.missionDecided: keine weiteren Skript-Sounds und keine SAM-Käufe mehr („Die Mission ist entschieden").

SA-2+SA-3-Stellung Sukhumi (rot + Spiegel) aus dem Wald geholt — Bäume blockierten die Radare, kein Lock möglich. Ebenso SA-11 Senaki (Ground-31) aus einem Waldstück.

KI-Spawnpunkte erneut justiert (näher heran — solo war zu wenig Feindkontakt). Geländecheck aller 16 Punkte danach: alle sicher (knappster: RED_AI_4 mit ~2360 m Bodenabstand, mehrere über Meer).

Der Fix der zwölften Fassung (SA-2 aktiv ab Start) reichte nicht — der Host sah den Sochi-Ring auch nach Re-Slot nicht. Recherche (ED-Forum): (1) Der HOST baut seine F-16-HSD-Threat-Liste aus allen in der mission PLATZIERTEN AD-Gruppen, auch nie spawnenden Late-Activation-Vorlagen; Clients nur aus gesyncten, existierenden Einheiten (ED-bestätigt, „reported" seit 2022). (2) Seit DCS-Update 12.05.2026 gilt ein 16-Threat-Limit. Unsere Spiegel-Vorlagen (SA2_KRASNODAR_RED an einem blauen Platz usw.) und die 48 DEF-Spiegel verstopften also die Host-Liste mit Phantomen, bis echte Ringe rausfielen — Clients ohne Phantome waren nicht betroffen. Fix: alle 56 Late-Activation-Fahrzeuggruppen bekommen hiddenOnMFD + hiddenOnPlanner (reine Spawn-Vorlagen, sollen nirgends auftauchen). Aktive Stellungen sind unberührt.

Falls der Ring danach immer noch fehlt, ist das verbleibende Limit (16 Threats inkl. der vielen AAA) die Ursache — dann wäre der nächste Schritt ein eigener DTC (Threats-Tab im Briefing-Fenster) oder F10-Reichweitenkreise auch für bekannte Feind-Startstellungen.

Host sah den SA-2-Threat-Ring von Sochi nicht im HSD (F-16, Nutzer-Report 12.08.). Ursache: Die F-16 baut ihre HSD-Ringe als DTC-Schnappschuss beim Slot-Einstieg. Die SA-2 des Ausgangsbesitzers an Sochi/Maykop wurde aber erst bei t+3 s vom Einnahme-Skript gestellt — der Host (sofort im Slot) hatte sie nie im Schnappschuss, später joinende Clients schon. Fix wie an Krasnodar/Sukhumi: SA2_SOCHI_RED und SA2_MAYKOP_BLUE stehen jetzt aktiv ab Missionsstart in der mission (lateActivation entfernt), und initDefenders respawnt die SAM-Listen beim Start nicht mehr (respawnListIf entfernt — ein Respawn hätte die Einheiten neu erzeugt und den Schnappschuss erneut entwertet). Bekannte Grenze bleibt: per F10 nachgekaufte Stellungen erscheinen bei bereits sitzenden Piloten nicht im HSD (DCS-DTC-Eigenheit) — dafür gibt es die F10-Reichweitenkreise.

Zufällige Slot-Auswahl: tryRespawn nahm immer den ersten toten Slot der Poolliste — die Anflugachse war vorhersagbar, und die hinteren Slots kamen bei niedrigem Limit praktisch nie zum Zug. Jetzt werden alle freien Kandidaten gesammelt und zufällig gewählt.

Spawn-Staffelung: Mindestabstand 90 s zwischen zwei Spawns derselben Seite. In den Testflügen wurden zwei Slots oft binnen Sekunden geplant und kamen als Doppelwelle an, danach Flaute. Fällt ein geplanter Spawn in die Sperrzeit, schiebt ihn der neue spawnCallback um die Restzeit + 5–20 s Jitter nach hinten (Log: „Spawn-Staffelung: … verschoben um …s").

Vorgemerkt für v0.9.5 (erst wenn die 0.9.4 solide steht): frontabhängige Spawn-Positionen mit Laufzeit-Geländeprüfung (land.getHeight), gelegentliche 2-Schiff-Rotten, Höhen-/ Profilvarianz, feinere Spielerzahl-Skalierung. Ereignisgekoppelte Wellen wurden bewusst verworfen (zu viel Komplexität).

SA-2 + SA-3 an Krasnodar (WP3) und Sukhumi (WP7) statt der einzelnen SA-6 (Nutzerentscheid nach dem SAM Threat Guide; niemals IR-Systeme). Symmetrisch für beide Seiten, Muster wie Maykop/Sochi: je Basis und Seite eigene Vorlagen — SA-2 (Fan Song + P-19 + 6 Werfer + Munitions-LKW, 9 Einheiten, Kopie der Sochi-Vorlage) plus neu gebaute SA-3 (Low Blow + P-19 + 4× 5P73 + Munitions-LKW, 7 Einheiten) 400 m daneben; alles Skill Average. Der Ausgangsbesitzer (Krasnodar: Blau, Sukhumi: Rot) steht ab Missionsstart, die Spiegelseite ist Late-Activation-Vorlage fürs F10-Menü. Die alten SA-6-Gruppen KRASNODAR_BLUE_AA und Ground-28 sind gelöscht. SEAD-Effekt: Low Blow + 2× P-19 + Fan Song = vier Radare pro Platz statt bisher einem Straight Flush. F10-Reichweitenkreise: SA-2 35 km, SA-3 18 km. Briefing („[ Verteidigung ]") nennt die neuen Pakete.

Zweiter Boom-Tanker je Seite (Nutzerwunsch): Bugsy-BLUE-3 (Texaco 1-2, TACAN 15X, 252 AM) und Bugsy-RED-3 (Arco 1-2, TACAN 77X, 252 AM) als Deep-Copy der bestehenden KC-135, Orbit um 30 km senkrecht zur Tracklinie versetzt (eigener Track). Vollständig eingebunden: F10-Support-Liste (direkt unter dem jeweiligen ersten Boom-Tanker), Respawn-Wächter, Funk-Erlaubnisliste (Funkdisziplin), Front-Nachführung der Orbits; SetImmortal/ UnlimitedFuel/Tanker-Task kommen aus der Kopie mit. Die 299,5-kt- Anzeige der Tanker ist übrigens korrekt: Die zweistufige Kalibrierung (213,2 m/s TAS auf FL230) zielt bewusst knapp unter 300 kt CAS.

Räum-Sperre ersetzt durch Überrennen (Nutzerentscheid nach dem Testflug 11.08.). Die v7.11-Sperre („Erst raeumen, dann aufbauen") war unspielbar: An Sochi stehen zu viele Rest-Einheiten (SA-2-Stellung mit 9 Einheiten + Tor + Munitions-LKW), um sie alle einzeln rauszuschießen — im Test fiel der letzte P-19 erst bei 77 min, der Kauf ging erst bei 79 min durch. Neu (adClearHostiles): Wer den Flugplatz besitzt, darf sofort kaufen; beim Aufbau werden lebende feindliche Bodeneinheiten im Stellungsraum (600 m um jede Paketteil-Position) entfernt („überrannt", erst sammeln, dann unit:destroy()), Meldung „Stellungsraum geraeumt: n feindliche Rest-Einheit(en) ueberrannt." + Log. Das Übereinander-Spawnen aus dem 09.08.-Test bleibt damit weiterhin ausgeschlossen.

SA-2 Erstschuss diesmal 47,7 km (frontal anfliegendes Ziel); weiter keine Treffer gegen ausweichende Spieler (erwartet/akzeptiert). Fan Song fiel bei 21 min (HARM), P-19 überlebte bis 77 min.

RED_AI_1 spawnt nicht mehr im Berg. Im Testflug 09.08. spawnte die Su-27 dreimal und crashte jeweils <0,5 s später ohne Fremdeinwirkung. Tacview: Spawn bei 40.59N/41.46E (Kaçkar-Gebirge, NO-Türkei) auf 2208 m BARO — das SRTM-Gelände liegt dort auf 2359 m, der Jet spawnte also 150 m unter dem Boden. Geländecheck (opentopodata srtm90m, Raster ±15 km) über alle 16 KI-Spawnpunkte der vierten Fassung fand zwei weitere Fälle: RED_AI_8 (2168 m über bis zu 2723 m Gelände nahe Aragats) wäre genauso sofort gecrasht, RED_AI_4 hatte nur 65 m Bodenabstand (3116 m über 3051 m, Dagestan-Kamm). Fix: Spawnhöhen (unit + WP1) von RED_AI_1/4/8 auf 4500 m BARO, zusätzlich WP2 von RED_AI_1 (2000 m, Kaçkar-Querung direkt nach dem Spawn) und RED_AI_4 (2447 m, Dombai-Region, Kamm bis ~3150 m) auf 4000 m. RED_AI_2/3/5/6/7 und alle BLUE-Spawns geprüft: ≥1300 m Bodenabstand bzw. über Meer/Steppe — unverändert.

F10-Flugabwehr spawnt nicht mehr in feindliche Reststellungen (dynspawn.lua v7.11). Beide Seiten nutzen an jedem Platz dieselbe Stellungsposition (anchor bzw. deckungsgleiche Spiegelvorlagen). Stand dort noch die lebende SAM des alten Besitzers (SAMs sind keine Einnahme-Bedingung), spawnte das neue Paket mitten hinein — Einheiten deckungsgleich übereinander, jeder Treffer auf die alten traf auch die neuen. Beobachtet im Testflug 09.08. (~17:17, Gudauta/Sukhumi): Gepard beschoss rote Kub-Reste und zerstörte dabei die frisch gekauften blauen Kub (−10-Eigenbeschuss-Wertungen im Log). Fix: requestAirDefence prüft vor dem Aufbau per adHostilesNear (Radius 600 m um jede Paketteil-Position), ob lebende Feind-Bodeneinheiten dort stehen, und blockiert dann mit Meldung „… feindliche Einheit(en) im Stellungsraum. Erst raeumen, dann aufbauen." Punkte werden dabei nicht abgezogen, die Technik-Sperre startet nicht. Bewusst KEIN Auto-Löschen der Feindreste: die stehenden Feind-SAMs sind gewollte Spielmechanik und sollen nicht für 2 Punkte „wegkaufbar" sein.

~~RED_AI_1 crashte 3× sofort nach dem Spawn~~ — in der fünften Fassung behoben (Spawn im Gelände, Höhen angehoben; siehe oben). Beim nächsten Testflug mitprüfen, dass RED_AI_1/4/8 jetzt überleben.

Auto-Restart-Hook weiter ungetestet (Testende 09.08. war ein manueller Stop, Hook hat korrekt nicht ausgelöst).

Das Siegeslied spielt jetzt wirklich. Der Endtrigger spielte Lied und a_end_mission im selben Zug — das Ende würgte das Lied ab (im Multiplayer wirkt es praktisch sofort). Die Dateien selbst waren einwandfreie PCM-WAVs (2:23 / 3:40). Jetzt: Fanfare → nach 9 s startet das Lied (Flags 9001/9002, Trigger ohne a_end_mission) → erst nach der Liedlänge setzt dynspawn die neuen Flags 9003/9004, auf die zwei neue Trigger „ENDE FINAL BLAU/ROT" mit dem eigentlichen Missionsende reagieren. Trigger in trigrules und trig konsistent, damit auch ein Editor-Speichern den Umbau übersteht.

Flugabwehr-Punkte: Einnahme +2, Paket kostet 2, Start 2; Technik-Sperre von 15 auf 5 min gesenkt — der Begrenzer ist jetzt das Konto. Stand im F10-Status und in den Meldungen. Werte sind bewusst Erstabstimmung.

AWACS-/Tanker-Orbits folgen der Front: nach jedem Flip werden die Routen beider Seiten um den Versatz des eigenen Basen-Schwerpunkts verschoben (Originalroute samt AWACS-/Tanker-Task und TACAN neu gesetzt); auch ein AWACS-Ersatz übernimmt den aktuellen Versatz.

Kneeboard-Seite 10_Spielregeln.png (neuer 51. Eintrag) und neues Briefing — das alte nannte HAWK, 15-min-Cooldown und einen „5-Minuten-Respawn", den es nie gab.

Werkzeuge: check_refs.lua (statischer Selbsttest: alle von den Skripten referenzierten Gruppennamen müssen existieren — 88 Referenzen, 0 fehlend) und release.ps1 (Endkontrolle + Website + Deploy in einem Befehl). Server-Hook MidgardAutoRestart.lua (außerhalb der .miz, Saved Games\DCS\Scripts\Hooks): lädt die Mission nach regulärem Missionsende automatisch neu; manuelle Stopps lösen keinen Neustart aus.

SA-2 ersetzt die HAWK an Sochi und Maykop — zum Testen. Hintergrund: Wunsch nach HAWK-ähnlicher Reichweite, aber früherem Schuss, ohne Über-Bedrohung. Die Trackmessung vom 08./09.08. hatte die SA-6 als frühesten Schützen ausgewiesen (Erstschüsse 28–37 km gegen 24–25 km bei der HAWK); auf Nutzerentscheidung wird zunächst die SA-2 erprobt (kurze Feuerkette wie die Kub, aber Einzelziel und ausweichbare Rakete — Einschätzung, nicht gemessen). Umsetzung: - Vier neu gebaute Late-Activation-Stellungen SA2_SOCHI_BLUE/RED und - Startverteidigung (Airbase_EinnahmeEND.lua v1.7) und F10-Paket - Die vier HAWK-Gruppen bleiben als inaktive Editor-Vorlagen in der

AWACS sind abschießbar (SetImmortal = false, alle sechs). Sie bleiben für die KI unsichtbar (SetInvisible) — angreifen tun sie also nur Spieler — und weichen weiterhin nicht aus. Ersatz kommt 30 Minuten nach dem Abschuss automatisch (neuer Respawn-Wächter in dynspawn.lua, prüft minütlich; Meldung an beide Seiten beim Verlust). Die Tanker bleiben unsterblich.

Die vier HAWK-Batterien zurück auf Skill High (44 Einheiten), alle übrigen SAM-Gruppen bleiben Average. Grund aus dem Testflug vom 2026-08-09: eine frisch per F10 gestellte Average-HAWK an Sochi ließ eine anfliegende Su-27 (11.100 m, bis auf 23,6 km heran, rund eine Minute im Schussfenster) ungenutzt passieren — Spawn, Radar und Scharfstellung waren laut Log und Track einwandfrei, es war die Average-typische Trägheit. Die F10-Spawn-Kopien erben den Skill aus der Vorlage und schießen damit ebenfalls schärfer.

Geistermeldung „zurückerobert" nach einer Einnahme. Befund aus dem Testflug vom 2026-08-08 (Sochi 21:29:57, Gudauta 21:57:04 → BLUE, kein Rück-Flip im Log): Die Skript-Einnahme prüft nur die DEF-Gruppen — überlebende Nicht-DEF-Einheiten des alten Besitzers (HAWK, SA-15, näher gerückte SAMs) stehen aber weiter in der Einnahmezone. DCS' eigene Bodenkontrolle sah im Flip-Moment nur diese und setzte den Flugplatz zurück auf die alte Seite; nach Sperr- und Bestätigungszeit meldete der Poller in dynspawn das als erneute Einnahme, obwohl die Skript-Logik korrekt beim neuen Besitzer blieb. Zwei Änderungen in Airbase_EinnahmeEND.lua v1.6: - Beim Flip werden die neuen DEF-Gruppen vor dem Koalitionswechsel - Die Flugplatz-Koalition wird im 10-s-Takt gegen den Skript-Besitz

AWACS ignorieren Bedrohungen (REACTION_ON_THREAT = NO_REACTION, alle sechs) und fliegen stur ihre Runden — wie die Tanker seit v0.9.3. Unsterblich waren sie schon seit v0.9.1.

Tanker fliegen 300 kt CAS (213,2 m/s ≈ 414 kt TAS auf 7010 m; alle vier Bugsy-*, alle Wegpunkte) und reagieren nicht mehr auf Bedrohungen (REACTION_ON_THREAT = NO_REACTION). Der Tacview vom 2026-08-07 zeigt alle vier Tanker in Ausweich-Sturzflügen von 7000 m bis auf ~250 m herab — ausgelöst durch die SM-2 des jeweils feindlichen Trägers auf der Route. Sie sind unsterblich; das Ausweichen war nur Störung. Die Zielgröße 300 kt CAS ist in zwei Schritten aus den Testflügen kalibriert (205,78 m/s → 278 kt CAS am 08.08.; 221 m/s → 311 kt CAS am 09.08.; linear interpoliert 213,2 m/s). Der Zwischenschritt „400 kt TAS" beruhte auf einer TAS/CAS-Verwechslung.

Abfangreichweite 100 % (Option 24) auf allen 14 SAM-Gruppen — die zwölf bisherigen plus die zwei neuen Tor. Die Options-ID wurde empirisch aus DCS-eigenen Missionen bestimmt (dort z. B. Wert 80 neben ALARM_STATE auf Bodengruppen).

HAWK + SA-15 als Paket anforderbar im F10-Menü an Maykop und Sochi — ein Menüeintrag stellt beides zusammen, wie Gudautas „SA-6 Kub + Tor". Die HAWK baut an der HAWK-Stellung auf, der Tor an seiner eigenen Editor-Position; Sperre (15 min) und Bestand gelten für das Paket. Steht nur noch ein Teil (z. B. der Tor), zählt die Stellung als angeschlagen und bleibt anforderbar. Vorlagen der SA-15 sind die vier *_AA-Tor-Gruppen.

SOCHI_BLUE_AA und MAYKOP_RED_AA auf Late Activation gesetzt. Die vom Nutzer ergänzten Spiegel-Tor standen sonst ab Sekunde 0 aktiv am Platz des jeweils anderen Teams (Sochi startet ROT, Maykop BLAU) und hätten dort sofort das Feuer eröffnet. Als Late-Activation-Gruppen existieren sie nur noch als Vorlage für das Spawnmenü.

Einheiten spawnen nicht mehr ineinander. Die SA-6-Vorlagen (KRASNODAR_BLUE_AA, Ground-28) und die SA-11-Vorlagen enthielten Versorger mit 3,6 bis 11,8 m Abstand (2× ATZ-10, APA-80/PBU, 2× Ural). In der mission entzerrt (Mindestabstand 14 m); zusätzlich erzwingt adSpawn den Mindestabstand bei jedem Menü-Spawn.

Gespawnte Stellungen werden nach dem Aufbau explizit scharfgestellt: 2 s nach dem Spawn setzt adSpawn ALARM STATE = RED, ROE = OPEN FIRE und Abfangreichweite 100 % direkt auf den Controller — als Absicherung gegen das gemeldete „lockt nicht nach manuellem Spawn" (v. a. SA-6), zusätzlich zum Birth-Handler.

Skill aller zwölf SAM-Gruppen von Excellent auf Average (106 Einheiten). Die 48 DEF-Gruppen (Rohrflak) bleiben wie sie sind. Average senkt Reaktionszeit-, Treffsicherheits- und Wiederaufschalt-Verhalten auf die niedrigste feste Stufe.

KI-Flüge funkten nach ihrem ersten Respawn wieder („Jury11 engaging") trotz Funkstille-Logik. Ursache: silenceGroup in dynspawn.lua brach bei bereits bekanntem Gruppennamen ab (silenced[name]-Cache). mist.respawnGroup spawnt aber unter gleichem Namen mit frischem Controller und Standard-Optionen — die respawnte Gruppe bekam die SILENCE-Option deshalb nie wieder. Der Cache-Abbruch ist entfernt; die Option wird bei jedem Birth-Ereignis neu gesetzt (idempotent).

Gleicher latenter Fehler in setAlarmRed (alarmSet[name]-Cache): eine respawnte SAM-Gruppe hätte ihr ALARM STATE = RED über den Skript-Weg verloren. Ebenfalls entfernt. Seit v0.9.1 steht die Option zusätzlich in den Gruppendaten der mission, doppelt hält besser.

ALARM STATE = RED auf allen zwölf SAM-Gruppen. HAWK_SOCHI_BLUE/RED, HAWK_MAYKOP_BLUE/RED, MAYKOP_BLUE_AA, SOCHI_RED_AA (Tor), KRASNODAR_BLUE_AA, Ground-28 (Kub), Ground-31, Ground-32 (Buk), Ground-34, Ground-35 (Kub + Tor). Die 48 DEF-Gruppen bleiben unangetastet — es ist reine Rohrflak (Vulcan, ZSU-23-4 Shilka, Gepard), und dynspawn.lua schließt sie ausdrücklich aus. Einordnung: dynspawn.lua setzt ALARM STATE = RED bereits zur Laufzeit (alarmExistingGround fünf Sekunden nach Missionsstart, dazu der Birth-Handler für später gespawnte Gruppen). Der Eintrag in der mission ist daher überwiegend Redundanz: er wirkt in den ersten fünf Sekunden, macht die Einstellung im Mission Editor sichtbar und trägt, falls das Skript einmal nicht lädt.

AWACS und Tanker bleiben dauerhaft in der Luft. Auf allen zehn Gruppen (AWACS1–AWACS6, Bugsy-BLUE-1/2, Bugsy-RED-1/2): Die Unsterblichkeit war der eigentliche Fehler: die zehn hatten SetInvisible und unbegrenzten Treibstoff, aber keinen SetImmortal-Task. Beschädigte KI fliegt heim und landet — genau das Verhalten, das abgestellt werden sollte. Landewegpunkte gab es keine; die Routen sind Dreieckskreise über SwitchWaypoint. Das ist geprüft und im Skript als Kontrolle verankert.

Die acht DEF-Kneeboardseiten zeigen jetzt die DCS-eigene Flugplatzkarte statt der abstrakten Ringkarten aus v0.8.10. Gleiche Dateinamen (02_DEF_*.png … 09_DEF_*.png), gleiches Format 1536 × 2048. Grundlage sind die GND-Karten aus Mods/terrains/Caucasus/Kneeboard: Bahn und Rollwege werden freigeschnitten und neu aufgebaut, der Blattwinkel wird nach bester Ausnutzung gewählt, die DEF-Stellungen kommen als Marker mit Beschriftung dazu. Damit steht die Stellung im echten Platzbild — neben Rollweg, Vorfeld und Shelterreihe — statt auf einem leeren Ring. 01_Wegpunkte.png bleibt unverändert.

Sochi-Adler — Die Bahnen 06/24 (3100 m) und 02/20 (2200 m) kreuzen sich und bilden im Schwarzbild eine Fläche von 12768 px und 254 px Breite. Deren Hauptachse ist eine Mischrichtung aus beiden Bahnen, die Verankerung lag am Rand des Mischklecks. Drehung 8,44° → 3,21°, Schwelle 06 um 284 m versetzt.

Krasnodar-Center — Die größte schwarze Fläche der Karte ist nicht die Bahn, sondern der gefüllte Hinweiskasten „Attention: Non-Standard Approach Lights" (7445 px gegen 3120 px Bahn). Die Bahn selbst zerfällt in zwei Hälften, weil das gedruckte ARP-Symbol sie unterbricht. Drehung 1,98° → 4,46°, Schwelle 08 um 325 m versetzt.

Acht Kneeboard-Seiten mit den DEF-Standardpositionen, eine je Flugplatz, unter KNEEBOARD/IMAGES/02_DEF_*.png … 09_DEF_*.png. Format 1536 × 2048 wie die vorhandene Seite 01_Wegpunkte.png. Jede Seite zeigt maßstabsgetreu die Platzmitte, Entfernungsringe (250 m oder 500 m je nach Ausdehnung), Nordpfeil, Maßstabsbalken und die drei DEF-Stellungen. Der Kartenausschnitt wird pro Platz so gewählt, dass Platzmitte und alle Stellungen hineinpassen. Ein Marker je Stellung, zweigeteilt — linke Hälfte BLUFOR, rechte REDFOR. Grund: die Positionen beider Seiten liegen nur 20 bis 145 m auseinander. Zwei getrennte Marker mit eigener Beschriftung überlagerten sich unleserlich; geteilt ist es eindeutig und ehrlicher, weil beide Seiten tatsächlich dieselbe Stellung nutzen. Die Bestückung ist an allen acht Plätzen und auf beiden Seiten gleich: Alle Positionen stammen direkt aus der mission, sind also nicht geschätzt. Kneeboard-Bilder brauchen keinen mapResource-Eintrag, sie werden über den Pfad gefunden.

Gudauta und Krymsk auf SA-6 Kub aufgewertet. Beide standen bisher nur unter einem SA-15 Tor (~12 km) und waren damit gegen alles, was aus mittlerer Höhe mit Abstandswaffen arbeitet, faktisch ungeschützt. Gewählt wurde die SA-6 Kub (~25 km): sie liegt genau zwischen dem Tor und der SA-11 Buk (~35 km), ist russisches Gerät, und die Mission hat mit Ground-28 und KRASNODAR_BLUE_AA bereits zwei erprobte Kub-Stellungen als Muster. Der vorhandene Tor bleibt in derselben Gruppe stehen, es entsteht also eine gestaffelte Abwehr: Kub für die Distanz, Tor für den Nahbereich und gegen anfliegende Waffen. Je Stellung ergänzt: 1 × Kub 1S91 str, 4 × Kub 2P25 ln, 1 × Ural-375 PBU — sechs Einheiten, die Abstände von Ground-28 übernommen. Bewusst schlanker als die 11 Einheiten dort: die zusätzlichen Tank- und Transportfahrzeuge sind rein kosmetisch, und zwölf neue Einheiten schlagen weniger auf die Bildrate. Der Tor steht weiterhin im Gruppenursprung, die Batterie ist um +60/+60 m herum aufgebaut, damit sich nichts überlagert. Weil AD_SITES diese beiden Gruppen als Vorlage für beide Seiten an Krymsk und Gudauta nutzt (über anchor), gilt die Aufwertung auch für die per F10 gestellten Kopien. Die Menübeschriftung heißt jetzt „SA-6 Kub + Tor".

Alarmbereitschaft der SAM-Stellungen auf ROT. Das war der eigentliche Grund für spätes Feuern: keine einzige SAM-Gruppe hatte eine Alarmbereitschaft gesetzt, alle liefen auf dem DCS-Standard AUTO. Dabei hält die Stellung ihr Radar zurück und braucht nach dem Erfassen erst eine Anlaufzeit. RED heißt Radar an und feuerbereit ab Sekunde 0. Gesetzt zur Laufzeit über AI.Option.Ground.id.ALARM_STATE (9) = 2, für alle Bodengruppen außer *_DEF_*. Über den S_EVENT_BIRTH-Handler gilt es auch für die per F10 gestellten Stellungen und für Respawns. Preis: die Radare strahlen dauerhaft. Sie stehen damit früher auf dem RWR und sind leichter mit Anti-Radar-Waffen zu bekämpfen.

Fertigkeitsstufe der SAM-Einheiten von High auf Excellent. Betrifft 95 Einheiten in 13 Gruppen — alle HAWK, SA-6 Kub, SA-11 Buk, SA-8 Osa und SA-15 Tor samt Versorgungsfahrzeugen. Die 48 DEF-Einheiten bleiben auf Average. Die Stufe verkürzt die Reaktionszeit und verbessert die Lenkung; sie ändert weder Radar- noch Raketenreichweite. Weil die per F10 gestellten Kopien ihre Werte aus der Vorlage übernehmen, gilt die höhere Stufe auch dort.

Die Stärke ist sehr ungleich. Novorossiysk und Senaki stehen unter einer SA-11 Buk (~35 km), Gudauta nur unter SA-8 Osa (~10 km) und SA-15 Tor (~12 km). Gudauta ist damit faktisch ungeschützt, sobald jemand aus mittlerer Höhe mit Abstandswaffen arbeitet.

Missionsende hängt jetzt an den Flags 9001 / 9002 statt an der Flugplatzabfrage. Im Editor-Modell trigrules haben „ENDE BLAU" und „ENDE ROT" nur noch eine Bedingung: c_flag_is_true(9001) bzw. (9002). Die acht c_coalition_has_airdrome-Bedingungen je Trigger sind entfallen. Hintergrund: Zum Starten muss die Mission im Editor gespeichert werden, und dabei regeneriert der Editor trig.conditions aus trigrules. Die in 0.7.9 direkt in die generierten Strings geschriebene Flag-Logik überlebte das nicht — sie war nach dem Test am 2026-08-05 verschwunden. Als trigrules-Bedingung ist sie dauerhaft. Das Skript setzt die Flags ohnehin selbst (checkMissionEnd), samt eigener endFired-Sperre; zusammen mit triggerOnce im Editor ist ein doppeltes Auslösen ausgeschlossen. Der frühere MIDGARD_END_FIRED-Behelf wird damit nicht mehr gebraucht.

Tanker sinken beim Start nicht mehr ab. Startsprit von 90 700 kg (voll) auf 50 000 kg (~55 %). Zusammen mit SetUnlimitedFuel = true blieben die Tanker dauerhaft auf Maximalgewicht und hielten die befohlenen 430 kt auf 23 000 ft nicht — sie tauschten Höhe gegen Fahrt. Bugsy-BLUE-1 fiel dabei auf 2 600 ft und brauchte rund acht Minuten zurück; in beiden Aufzeichnungen sekundengleich, also systematisch und kein Ausweichmanöver. Abgeben können sie trotzdem unbegrenzt — SetUnlimitedFuel hängt nicht am Startwert. Nicht behoben, weil kein Fehler: die roten Tanker sanken spät im Lauf auf 820 ft. Zu diesem Zeitpunkt (t≈658–749 s) waren AGM-88 und eine HAWK-Rakete in ihrem Gebiet in der Luft — normales Ausweichen. Ihre Kreise liegen nah an der Front.

KRITISCH: dynamisch gestellte Gruppen waren NEUTRAL. Die per F10 angeforderte Flugabwehr griff niemanden an und wurde selbst nicht angegriffen; in Tacview erschien sie grün statt blau oder rot. Ursache: in DCS bestimmt das Land die Koalition, nicht das Feld coalition im Gruppendatensatz. Gespawnt wurde unter country.id.USA bzw. country.id.RUSSIA — diese Mission kennt aber nur CJTF Blue (80) und CJTF Red (81). USA und Russland gehören hier keiner Koalition an, die Gruppen landeten also als neutral. Der Spawn meldet dabei keinen Fehler, im Log steht nichts. Belegt in beiden Tacview-Aufzeichnungen: ` v0.8.4: Group=MG_AD_MAYKOP_RED_1, Color=Green, Coalition=Neutral, Country=ru v0.8.5: Group=MG_AD_SOCHI_BLUE_1, Color=Green, Coalition=Neutral, Country=us ` Jetzt zentral über countryFor(side). Betraf auch die per dynSpawn nachgespawnten KI-Jets — die waren ab dem ersten Respawn ebenfalls neutral. Zusätzlich prüft checkCountries() beim Start die Zuordnung und meldet eine Abweichung im Log und auf dem Bildschirm.

Funkdisziplin. Alle KI-Luftfahrzeuge bekommen AI.Option.Air.id.SILENCE (7, laut DCS „Deny AI flights report events"). Ausgenommen sind ein AWACS pro Seite (AWACS1 blau, AWACS4 rot) und die vier Tanker. Damit entfallen die Angriffsmeldungen der Jäger. Die doppelten und dreifachen AWACS-Rufe kamen daher, dass drei AWACS je Seite denselben Kontakt melden — jetzt spricht einer, die anderen beiden liefern weiter Radarabdeckung. Die Tanker bleiben unstumm, weil ihr Funkverkehr die Antwort auf eine Pilotenanfrage ist und kein Ereignisbericht. Umgesetzt über einen S_EVENT_BIRTH-Handler plus einen Durchlauf über die Startgruppen, damit auch Respawns und dynamische Jets erfasst werden. Spieler sind ausgenommen.

Callout-Wiederholung folgt jetzt der echten Cliplänge. Bisher lag das „Repeating" fest 6,0 s nach Beginn — bei einem 2,3-s-Clip also 3,7 s Stille, bei einem 5,4-s-Clip nur 0,6 s. Jetzt steht die Länge jedes Clips in CALLOUT_LEN, und die Pause zählt ab Clip-Ende: konstant CFG.calloutGap = 0,8 s, unabhängig vom Flugplatz. Die Letzte-Basis-Warnung hängt jetzt am tatsächlichen Ende der Wiederholung (CFG.lastBaseWarnPad = 0,7 s danach) statt an einer festen Wartezeit.

F10-Tankermenü nennt Muster und Betankungsart. Der Menüpunkt heißt jetzt z. B. Texaco 1-1 - KC-135 (Boom), im Detail steht eine Zeile Muster. Einen KC-130 gibt es in dieser Mission nicht — die „zweite Sorte" ist die MPRS-Version der KC-135 mit Schlauchkorb:

Der Einnahme-Callout wird zweimal abgespielt, dazwischen „Repeating". Der erste Durchlauf ging im Gefecht unter. Ablauf je Seite (Sieger hört mg_cap_*, Verlierer mg_lost_*): Die Werte stehen in CFG (calloutRepeatGap, calloutRepeatPause) und haben Reserve: der längste der 24 Einnahme-Callouts dauert 5,43 s, der kürzeste 2,34 s.

Die Letzte-Basis-Warnung kommt später. Sie lag bei +4 s und wäre jetzt mitten in die Wiederholung gefallen. Sie hängt weiterhin an der Frontlage-Einblendung bei +4 s, der *Ton* wird aber um CFG.lastBaseWarnDelay (10 s) verzögert, also auf rund +14 s — nach dem Ende der Wiederholung (spätestens 13,2 s). Ausgerechnet diese Warnung soll nicht übersprochen werden.

l10n/DEFAULT/mg_repeating.wav — englisch gesprochen, passend zu den übrigen Callouts. Erzeugt mit der Windows-Stimme *Microsoft Zira Desktop* und auf das Format der vorhandenen Dateien gebracht (PCM, mono, 16 bit, 22050 Hz, fmt-Chunk 16). Die vorhandenen Callouts tragen dieselbe SAPI-Signatur, stammen also sehr wahrscheinlich aus derselben Quelle.

Bugsy-BLUE-1 und Bugsy-RED-1 kreisten am ersten Wegpunkt. Beiden fehlte an Wegpunkt 1 die Tanker-Task. Stattdessen stand dort eine manuell gesetzte Refueling-Task (auto = false) — das ist die Task „flieg zum nächsten Tanker und betanke dich", nicht die Tanker-Rolle. Die KC-135 sucht also einen Tanker, findet keinen, bleibt in der Task hängen und arbeitet die Route nicht ab. Die Route selbst war in Ordnung: alle vier Tanker haben SwitchWaypoint 1→2, 2→3, 3→2, also eine saubere Endlosschleife zwischen WP2 und WP3. Bugsy-BLUE-2 und Bugsy-RED-2 hatten zusätzlich Tanker (auto) und flogen deshalb normal; bei ihnen war die Refueling-Task nur Ballast.

Refueling-Task bei allen vier Tankern entfernt. Bei den -1-Gruppen wurde sie an Ort und Stelle durch Tanker (auto) ersetzt (Slot 3 bleibt belegt, keine Umnummerierung nötig). Bei den -2-Gruppen wurde der Block gelöscht und die Folgeeinträge von [7] [8] [9] auf [6] [7] [8] neu nummeriert — inklusive der ["number"]-Felder. Ohne diese Neunummerierung entstünde eine Lücke im Task-Array, und DCS würde beim Durchlaufen alle Tasks nach der Lücke überspringen.

Seitenbezeichnungen von „NATO" / „RUSSLAND" auf „BLUFOR" / „REDFOR". Betrifft alle Stellen in dynspawn.lua, an denen ein Seitenname für Spieler sichtbar wird: die Frontlage-Übersicht (Spalte je Flugplatz und die Zählzeile darunter) und die Einnahme-Meldung (Kopfzeile [ … ] und der Satz „… hat <Platz> unter Kontrolle gebracht"). Die Mission soll keine realen Bündnisse oder Staaten benennen. Nicht geändert, weil es keine Beschriftung ist: - country.id.USA / country.id.RUSSIA in dynspawn.lua (Zeilen 429, - ["livery_id"] = "nato" im mission (3 Flugzeuge) — der Name eines Airbase_EinnahmeEND.lua und die dictionary enthielten keine solchen Bezeichnungen.

v0.8.1 fehlten 28 Dateien — alle mg_*.wav. Beim Bau von 0.8.1 wurde das Archiv im ZipArchiveMode::Update von .NET geöffnet und nur der dictionary-Eintrag ersetzt. Beim Zurückschreiben hat .NET 28 der 41 Einträge verworfen; übrig blieben 13. Aufgefallen ist es an der Dateigröße (18,69 MB statt 21,22 MB) — die Differenz sind exakt die WAVs. Deshalb kam bei der Einnahme kein Ton: die Dateien waren nicht mehr im Archiv. Die betroffenen Einträge sind die, die im Original mit „extended local header" (Data Descriptor) geschrieben wurden; die 13 überlebenden sind die ohne. unzip -t meldet für so ein Archiv trotzdem „No errors detected" — die Integritätsprüfung sagt nichts über Vollständigkeit. v0.8.2 wird deshalb vollständig neu gepackt statt aktualisiert, und die Eintragsliste wird gegen v0.8.0 verglichen.

Sounddateien waren nie in l10n/DEFAULT/mapResource registriert. Die 28 mg_*.wav kamen in 0.7.9 ins Archiv, aber ohne Eintrag in mapResource. Registriert waren nur die sechs im Editor angelegten Ressourcen. DCS führt mapResource als maßgebliche Ressourcenliste — dictionary.lua löscht beim Speichern sogar Dateien aus dem Missions-Temp-Verzeichnis, die dort nicht stehen (isFileInMapResource → os.remove). trigger.action.outSound* meldet für eine unbekannte Datei keinen Fehler, es bleibt still; im dcs.log steht nichts. Jetzt sind alle 28 als ResKey_Action_126 … ResKey_Action_153 eingetragen. maxDictId im mission wurde von 125 auf 153 gezogen, damit der Mission-Editor diese IDs später nicht erneut vergibt.

WAV-Header normalisiert. Alle 28 mg_*.wav hatten einen fmt-Chunk der Größe 18 (PCM mit angehängtem cbSize = 0); der Standard für PCM ist 16, und genau so sehen die beiden funktionierenden Dateien victory_march_blue.wav / victory_anthem_red.wav aus. Die zwei überzähligen Bytes sind entfernt und die RIFF-Größe angepasst. Audiodaten unverändert (mono, 16 bit, 22050 Hz).

Mission blieb beim Laden hängen (Ladebalken ~97 %, „caucasus.ng5"). Ursache war ein Lua-Syntaxfehler in l10n/DEFAULT/dictionary: der in 0.7.9 eingefügte Briefing-Text (DictKey_descriptionText_1) enthielt echte Zeilenumbrüche innerhalb des String-Literals. In Lua 5.1 ist das unfinished string. Die Folge steht in Scripts/dictionary.lua: loadDict() gibt bei einem loadstring-Fehler einfach false zurück, und loadDictionary() weist das ungeprüft zu — dictionary, curDict, mapResource = loadDict(...). Danach ist dictionary == false, und der nächste Zugriff getLangs() → pairs(false) wirft. Weil das innerhalb des Fortschritts-Callbacks des Ladedialogs passiert, bleibt der Balken stehen, statt eine Fehlermeldung zu zeigen. Der angezeigte Text „Terrain Graphics init / caucasus.ng5" war nur der zuletzt gesetzte Status, nicht die Fehlerstelle. Im dcs.log steht: ` ALERT LUACOMMON: Error: GUI Error: [string "./Scripts/dictionary.lua"]:758: bad argument #1 to 'pairs' (table expected, got boolean) ` Der Briefing-Text ist jetzt in DCS' eigener Schreibweise abgelegt: Zeilenfortsetzung mit \ am Zeilenende (Lua-Escape für einen Zeilenumbruch), so wie der Mission-Editor selbst serialisiert.

Briefing beschrieb noch das entfernte Menü aus 0.7.9. Der Text nannte „zusaetzliche AAA-/SHORAD-Stellungen … Cooldown 10 min, max. 2 pro Platz". Das gibt es seit 0.8.0 nicht mehr. Jetzt steht dort das tatsächliche Verhalten (Stellung neu aufstellen, 15 min je Flugplatz und Seite). Ergänzt wurde außerdem, dass die HAWK beim Besitzerwechsel nicht mehr mitspawnt.

Die HAWK spawnt beim Flip nicht mehr automatisch mit. Bis 0.7.9 stellte Airbase_EinnahmeEND.lua an Maykop und Sochi die HAWK der neuen Seite sofort mit. Wer eine Basis nahm, bekam die Flugabwehr geschenkt. Jetzt ist eine frisch eroberte Basis zunächst ungeschützt — sie zu halten kostet eine bewusste Entscheidung. Beim Missionsstart wird die HAWK des Ausgangsbesitzers weiterhin gestellt; sonst wären ausgerechnet Maykop und Sochi als einzige Plätze ab Sekunde 0 blank, während alle anderen Basen ihre im Editor aktiven SAM-Stellungen haben.

Das F10-Menü „[ Verteidigung ] Flugabwehr“ wurde ersetzt. Statt generischer AAA-/SHORAD-Pakete an einer zufälligen Position wird jetzt die originale, im Editor geplante Stellung des Flugplatzes angefordert — als Kopie unter neuem Namen, an genau der geplanten Position. Damit steht die Batterie dort, wo Sichtlinien und Abstände stimmen, statt in einem zufällig ausgewürfelten Feld. - Sperre 15 Minuten, getrennt pro Flugplatz und Seite. - Verfügbar an allen Flugplätzen in eigener Hand. - Abgelehnt wird nur, wenn die eigene Stellung vollständig intakt - Das alte Paketsystem (SAM_PACKAGES, findSpot, 10 min, max. 2

Die 48 <BASE>_<SEITE>_DEF_{1,2,3}-Gruppen enthalten je genau eine Einheit: _DEF_1 = Vulcan, _DEF_2 = ZSU-23-4 Shilka, _DEF_3 = Gepard. Ausnahmslos, an allen acht Basen, beide Seiten. Das sind reine AAA und weiterhin allein die Einnahme-Bedingung — vom F10-Menü völlig unberührt. Ein Team kann seine Basis also nicht per Knopfdruck uneinnehmbar machen.

Frühere Verdachtsmomente aus der Vorabanalyse sind damit widerlegt: weder steckt eine SA-6 in MAYKOP_BLUE_DEF_1, noch enthält SENAKI_BLUE_DEF_1 einen einzelnen Hawk pcp. Beides waren Artefakte des zeilenweisen Scans, weil der Gruppenname in .miz-Dateien mal vor und mal nach der units-Liste steht.

Die echten Flugabwehren liegen alle außerhalb der DEF-Gruppen: Die Mission hat pro Flugplatz nur eine Stellung für den Ausgangs- besitzer. Erobert Blau z. B. Gudauta, gäbe es dort gar keine blaue Stellung zum Neuspawnen. Deshalb wird für die jeweils andere Seite die spiegelbildliche Vorlage derselben Klasse benutzt und an der Position der Originalstellung aufgebaut (anchor). So bekommt jede Seite an jedem Platz eine passende Stellung — ohne Eingriff in den Mission Editor, die mission ist gegenüber 0.7.9 byte-identisch.

Sprach-Callouts bei jeder Einnahme (Englisch), seitengetrennt. Die erobernde Seite hört z. B. *„Blue team captured Sochi“*, die verlierende Seite gleichzeitig *„We lost Sochi. Fall back to our remaining bases.“* Umgesetzt über outSoundForCoalition, dadurch bekommt keine Seite Informationen über den Gegner geliefert. 28 neue Sprachdateien (mg_*.wav) für alle acht Flugplätze.

Warnung bei der letzten eigenen Basis: *„Warning. We are down to our last airbase. Hold the line.“* (einmalig, wird zurückgesetzt, sobald die Seite wieder mehr als eine Basis hält).

F10-Menü „[ Verteidigung ] Flugabwehr“ pro Koalition: an jedem Flugplatz in eigener Hand lässt sich zusätzliche Flugabwehr anfordern. - Zwei Pakete: *AAA/Flak* (BLAU: 2× Gepard + Vulcan · ROT: 2× Shilka - Grenzen: 10 min Cooldown pro Flugplatz, max. 2 gleichzeitig aktive - Platzierung 900–1600 m vom Flugplatzzentrum auf zufälliger Peilung; - Wichtig für die Balance: diese Gruppen sind *zusätzlich* und - Menüpunkt „Status / Cooldowns“ zeigt Stellungen und Sperrzeiten.

KRITISCH — „Jet-Leak“, Hauptursache der FPS-Einbrüche. dynSpawn() legt KI-Gruppen unter *neuen* Namen an (BLUE_AI_1_R7), countActive() und enforceLimit() prüften aber weiterhin nur die Originalnamen aus BLUE_POOL/RED_POOL. Nach dem ersten Respawn galt damit jeder Slot dauerhaft als „tot“ — das Aktiv-Limit (2 bzw. 4 Jets pro Seite) griff nie wieder und es wurden endlos neue KI-Jets nachgespawnt, ohne dass alte je abgeräumt wurden. Je länger die Mission lief, desto schlimmer. Fix: pro Pool-Slot wird der tatsächlich lebende Gruppenname mitgeführt (SLOT_LIVE), inklusive des Namens, den mist.dynAdd bei einer Namenskollision tatsächlich vergibt.

Missionsende löste nie aus. Die beiden ENDE-Trigger hingen am Event base captured. Dieses Event feuert nicht, wenn ein Flugplatz per Skript (Airbase:setCoalition) umgestellt wird — und genau das macht das Einnahme-System. Die Bedingung selbst (alle acht Airdrome- IDs 13/14/15/16/18/20/21/23) war korrekt und ist unverändert. Fix: die Trigger werden jetzt laufend ausgewertet statt eventgesteuert; zusätzlich wertet das Skript die Siegbedingung selbst aus und meldet sie über die User-Flags 9001 (BLAU gewinnt) bzw. 9002 (ROT gewinnt). Beide Wege führen zum selben Trigger, ein Einmal-Schutz (MIDGARD_END_FIRED) verhindert Doppelauslösung.

„Gudauta-Flackern“ — Geistermeldungen über Einnahmen. Gemeldetes Symptom: Gudauta wurde eingenommen, unmittelbar danach kam die Meldung, es sei zurückerobert worden (war es nicht), dann wieder die Einnahme-Meldung. Zwei sich verstärkende Ursachen: 1. *Einnahme-Skript:* Nach einem Flip wurden die Verteidiger der 2. *Melde-System:* Der Poller meldete jeden beobachteten

Einnahmen wurden nur passiv erkannt. dynspawn.lua hat auf Airbase:getCoalition() gepollt und den Flip damit nur zufällig mitbekommen. Jetzt meldet Airbase_EinnahmeEND.lua den Flip aktiv über MIDGARD.notifyCapture(); das Polling bleibt als Absicherung bestehen. Doppelmeldungen sind ausgeschlossen.

Sound-Dateinamen mit Sonderzeichen. Die blaue Siegeshymne hieß „Alte Kameraden“ • Marschlied [+Liedtext].wav. Typografische Anführungszeichen und Aufzählungspunkt überleben das Neupacken eines .miz nicht zeichengetreu — die Datei wäre im Spiel nicht mehr auffindbar gewesen. Beide Hymnen heißen jetzt victory_march_blue.wav und victory_anthem_red.wav; mapResource wurde entsprechend angepasst.

Ergebnistext für Rot war leer (DictKey_ActionText_28) — beim roten Sieg erschien ein leerer Ergebnisbildschirm. Jetzt „ROT GEWINNT!“.

Frontlage zeigte Flugplätze mit noch unbekanntem Besitzer pauschal als russisch an. Jetzt wird auf den Startbesitzer zurückgegriffen.

Anstößige Missionstexte entfernt. In l10n/DEFAULT/dictionary stand in 14 Einträgen eine rassistische Beleidigung („… ist weg ihr N****“). Die Einträge stammten aus gelöschten Triggern und wurden im Spiel nicht mehr angezeigt, waren aber in der Missionsdatei enthalten und damit für jeden lesbar, der die .miz öffnet. Ersetzt durch „<Flugplatz> verloren!“.

Achtung beim Öffnen im Mission Editor: die 28 mg_*.wav sind per Skript eingebunden, nicht über eine Trigger-Aktion. Der DCS Mission Editor kennt nur Dateien, die in mapResource referenziert sind, und kann beim Speichern nicht referenzierte Dateien aus der .miz entfernen. Wenn die Mission im Editor bearbeitet und gespeichert wird, danach bitte prüfen, ob die Sprachdateien noch im Archiv liegen.

HAWK-Integration an Maykop und Sochi (HAWK_MAYKOP_*, HAWK_SOCHI_*): Die Batterien werden beim Start und bei jeder Einnahme mit der neuen Besitzerseite mitgespawnt (Option B). Sie zählen bewusst nicht zur Einnahme-Bedingung — der Flugplatz flippt bereits, wenn die regulären DEF-Gruppen zerstört sind.

Airbase-Flip meldete dauerhaft „NICHT verfügbar“: die Prüfung suchte coalition.captureAirbase, das es in der DCS-API nicht gibt. Korrekt ist Airbase:setCoalition.

F10-Menü „[ Support ]“ pro Koalition mit Live-Status (ONLINE/ OFFLINE), MGRS-Position, Höhe/Kurs/Speed sowie Funk-, TACAN- und ICLS-Daten für AWACS, Tanker und Flugzeugträger. Jede Seite sieht nur die eigenen Einheiten.

HAWK ist keine Einnahme-Bedingung — Absicht, nicht Versehen. Es gab einen früheren Entwurf („Option A"), in dem die HAWK-Batterien in den Gate-Listen standen und Maykop/Sochi damit befestigte Plätze waren. Bewusst verworfen zugunsten von „Option B": ein Platz flippt, sobald die drei DEF-Gruppen tot sind; die HAWK muss dafür nicht zerstört werden. Diese Festlegung gilt weiterhin. (Der *Respawn* der HAWK beim Flip wurde davon unabhängig in 0.8.0 abgeschafft.)

Das F10-Support-Menü ist absichtlich koalitionsweise gebaut (addSubMenuForCoalition / addCommandForCoalition / outTextForCoalition), damit keine Aufklärung an die Gegenseite durchsickert. Jede Seite sieht nur die eigenen Assets.

coalition.captureAirbase existiert in der DCS-API nicht. Eine frühere Fassung prüfte darauf und meldete deshalb dauerhaft „Airbase-Flip: NICHT verfügbar", obwohl die Einnahme lief. Korrekt ist Airbase:setCoalition(side). Steht so in Airbase_EinnahmeEND.lua (Zeilen 41–44, 119–120).

Lua-5.1-Vorsicht. DCS läuft auf Lua 5.1. dynspawn.lua Zeile 1033 hält deshalb local mAtan2 = math.atan2 or math.atan vor. Nicht entfernen, und bei neuem Code entsprechend zurückhaltend bleiben (kein goto, unpack statt table.unpack).

Der Mission-Editor überschreibt handgeschriebene Trigger. Zum Starten muss die Mission im Editor gespeichert werden; dabei erzeugt der Editor trig.func / trig.conditions / trig.actions neu aus seinem strukturierten Modell mission.trigrules. Alles, was direkt in die generierten Strings geschrieben wurde, ist danach weg. Konkret passiert am 2026-08-05 um 14:28: die in 0.7.9 von Hand eingetragene Missionsende-Logik (MIDGARD_END_FIRED-Sperre und der Pfad über die User-Flags 9001 / 9002) ist aus v0.8.5 verschwunden. Übrig blieb die Editor-Bedingung „Koalition besitzt alle acht Flugplätze". Sonst hat der Editor-Speichervorgang nichts verändert: 105 Gruppen vorher wie nachher, keine Gruppe verloren, Startzeit gleich. v0.8.6 erbt diesen Stand. Konsequenz: Änderungen an Triggern müssen in trigrules erfolgen, nicht in den generierten Strings — sonst überleben sie keinen Testlauf. Das Skript setzt die Flags 9001 / 9002 weiterhin selbst (checkMissionEnd, mit eigener endFired-Sperre); eine Editor-Bedingung „Flag 9001 ist wahr" wäre damit dauerhaft und zugleich zuverlässiger als die Flugplatzabfrage. Noch nicht umgesetzt.

Drei *_AA-Gruppen stehen außerhalb des Einnahme-Systems: MAYKOP_BLUE_AA, KRASNODAR_BLUE_AA, SOCHI_RED_AA. Immer aktiv, keine Einnahme-Bedingung.

SpielerKillMelder.lua ist nicht in der .miz. Hintergrund: die Abschussmeldungen für reine KI-Duelle stammen nicht aus den Missionsskripten, sondern aus dem DCS-Netzcode; abschaltbar nur serverseitig über Config/network.cfg → ["disable_events"] = true.