Motivation:
Ich wollte, dass die KI einen bestimmten Bereich sehr dynamisch und pro-aktiv gegen den Spieler verteidigen kann, ohne, dass spezielle Routen festgelegt, oder andere sehr spezifische Hacks angewendet werden müssen.
Um das zu erreichen, habe ich mit guarded Points und Waypoint:Guard experimentiert.
Wunschlos glücklich wurde ich mit der Synergie aus den Beiden und einem knows about value == 1.5, der nun durch den Reveal-Trigger verwirklicht werden kann.

Verwendung:

Schritt 1:
Das Herstück des Frameworks ist es, sog. Reveal-Trigger (siehe On Activaton) zu definieren:
[img]https://i.imgur.com/M8TJRz0.jpg[/img] is not a valid Image.

Solch ein Trigger muss nur einmalig auf dem Server ausgeführt werden.
Da der Trigger im Bild auf BLUFOR steht, werden die Gruppen derjenigen BLUFOR Units, die den Bereich dieses Triggers betreten, an die KI mit einem knows about value == 1.5 revealt werden.
Dies geschieht alle 30 Sekunden. Jedes Mal wird geprüft, ob neue BLUFOR Units in den Bereich eingetreten sind, welche anschließend ebenfalls an die KI revealed werden.


Mit diesem Code in der On-Activation würde das Revealing automatisch nach 600 Sekunden beendet. Damit entfällt dann Schritt 3!

Schritt 2:
Dieser Schritt erzeugt die Reveal-Struktur im Hintergrund und ist wenigstens für eine Gruppe nötig, bevor der Reveal-Trigger funktionieren kann.
Und er spezifiziert, an welche KI Gruppen dieser Reveal-Trigger revealen soll (Dopplungen werden zugunsten der Performance verhindert).

Oder in der Init eine Gruppe im Editor:

Wichtig ist, zu beachten, dass als erstes Argument der Triggername verwendet wird, der das Revealing an diese Gruppen übernehmen soll.
Gruppen können immer noch hinzugefügt werden, auch, wenn der Trigger bereits aktiviert wurde und das Revealing schon läuft.

Schritt 3:
Will man das Revealing erst zu einem ganz bestimmten Zeitpunkt beenden, dann geht das so:

Mit diesem Code wird das Aufdecken gestoppt und die Variablen sowie Event-Handler, die für den Trigger mit dem gegebenen Namen benötigt wurden, werden gelöscht.

Aber natürlich NICHT die zugehörigen KI-Gruppen selbst. Diese erhalten einfach keine Informationen mehr.


ADDON: Remote-Reveal-Triger:

Motivation:
Nicht immer passt ein großer Reveal-Trigger zum Gelände. Gute Avenues of Approaches sollten belohnt und der Spieler dort entsprechend nicht der KI aufgeklärt werden.
Bspw. können so Flussdeltas vom Revealing ausgeschlossen, oder bestimmte Berge in der Ferne eingeschlossen werden.
Dazu kann nun einem Reveal-Trigger ein Remote-Reveal-Trigger zugewiesen werden, der dem Reveal-Trigger ein weiteres Gebiet zuweist.

Verwendung:
Schritt 1:
Erstelle einen Remote-Reveal-Trigger:

1. Variablennamen (bspw. my_spotter_1)
2. Activation: Seite des Spielers (bspw. BLUFOR)
3. Activation Type: Present
4. Server Only
5. On-Activation:
   [thisTrigger, "bramar_reveal_1"] call FL_fnc_remoteRevealTrigger;



Schritt 2:
Ergänze die Condition des Haupt-Reveal-Triggers mit "start_variableNameOfMyRevealTrigger", so dass:

So können der Remote-Reveal-Trigger aus Schritt 1, oder beliebig viele weitere mit dem Reveal-Trigger "bramar_reveal_1" verknüpft werden.

Motivation:
Nutzt man die MIL_fnc benötigt man für jeden Spawn sehr viele Parameter von denen sich aber nur wenige pro Spawn ändern. Die anderen sind eher als Konstante zu betrachten. Der Code schreibt sich leichter und liest sich besser, wenn man die 'Konstanten' von den Veränderlichen kapselt.
Außerdem kann für Reveal-Trigger der Name der Reveal-Struktur in den Spawnprozess eingebracht werden, wenn sich die Einheit nicht im Bereich des Reveal-Triggers befindet, aber trotzdem Informationen erhalten soll. Zu guter Letzt wollte ich stets alle gespawnten Units auch als Zeus steuer- und sichtbar haben (vor Allem auf dem Server).

Verwendung:

Schritt 1:
In der initServer.sqf muss eine Vorbereitung getroffen werden:

Das registriert die standard - beachte die nil-Argumente - Spawnparameter (MIL_fnc), die vom Spawn-Wrapper künftig verwendet werden. Man kann auch weitere Standard-Spawnparameter registrieren.

Schritt 2:
Spawnen:

Standardmäßig werden die zuerst registrierten Parameter verwendet.
Hat man bspw. zwei Spawnparameter registriert, dann verwendet man die Zweiten durch den Index 1 als letztes Argument:



Optional:
Hat man nun gespawnt, möchte man auf die Gruppen auch komfortabel zugreifen können.
Dazu einfach das Prefix vom Spawning dieser Funktion übergeben:

Hat man bspw. 5 Gruppen mit dem Prefix "cool_squad" gespawnt, erhält man nun alle 5.
Die Funktion sichert dabei auch Verzögerungen durch das Netzwerk ab, denn meist sind die Gruppen nicht sofort nach ihrem Spawn auf dem HC verfügbar.

Optional:
'mySquadConfig' (siehe Code) kann man sich ebenfalls einmal in der initServer.sqf definieren:



ADDON: Marker-Sets:

Motivation:
Diese Funktion wurde eingebaut, um das Balancing beim Bau der Mission zu erleichtern.
Es kann damit hier und da noch schnell ein Spawn hinzuzufügt oder reduziert werden, nur durch kopieren oder entfernen eines Markers und ohne zwischen den Versuchen das Skript anfassen zu müssen.

Verwendung:
Schritt 1:
initServer.sqf:

Schritt 2:
Irgendein Skript auf dem Server:

Angenommen im Editor sind die Marker platziert.
Dann wird mit diesen zwei Schritten dort jeweils ein Squad gespawnt (und erhält Infos vom Reveal-Trigger "bramar_reveal_1", usw.).

Motivation:
Es sollen möglichst einfach per Trigger KI-Gruppen, samt spezifischer Wegpunkte/ Tasks, nachgespawnt und entschieden werden können, ob der Spieler im Trigger an die KI revealt werden soll oder nicht.
Da die Parameter für die verschiedenen Aufgaben zum größten Teil gleich sind, wurden frühere Trigger, wie Guard-, Patrol- und Ambush-Trigger unter diesem Neuen zusammengefasst.
Bspw. kann so hervorragend die aktive oder passive Verteidigung eines Compounds erzielt werden.
Außerdem könnte so auch simuliert werden, dass die KI während laufender Gefechte "die Stellung hält" und "abwartet", bis der Spieler die mit dem Trigger versehenen Bereiche betritt.

Beschreibung:
Jeder der folgenden Tasks erhält standardisierte Parameter, sodass er ohne weiter konfiguration erst Mal verwendet werden kann.
Bei besonderen Wünschen kann wahlweise das vollständige Parameter-Array für den spezifischen Task mit übergeben werden.
Bspw. für den Fall, dass man einen CBA- oder LAMBS-Befehl exakt konfigurieren möchte.

"GUARD", "SAD", "MOVE_GUARD":

1. Beliebig viele gruppen werden an gegebenen Positionen mit Hilfe der MIL_fnc gespawnt
2. Auf Wunsch wird der Trigger zum Reveal-Trigger
3. Die KI erhält einmalig entsprechende Wegpunkte

"AMBUSH":

1. Beliebig viele gruppen werden an gegebenen Positionen mit Hilfe der MIL_fnc gespawnt
2. Die Spieler werden zwangsweise aufgeklärt.
3. Search and destroy-Wegpunkte werden alle 15 Sekunden auf den nächst gelegenen Spieler gesetzt
4. Wird die KI vernichtet, wird das Rvealing automatisch beendet

"LAMBS_RUSH", "LAMBS_CAMP", "PATROL_CBA", "DEFEND_CBA", "SEARCH_CBA":

1. Beliebig viele gruppen werden an gegebenen Positionen mit Hilfe der MIL_fnc gespawnt
2. Die KI führt entsprechende Aufgabe aus

"NO_TASK":

1. Beliebig viele gruppen werden an gegebenen Positionen mit Hilfe der MIL_fnc gespawnt
2. Die KI hat erhält keine konkrete Aufgabe

Verwendung:

Schritt 1:
Siehe Spawn-Wrapper 1. Schritt.

Schritt 2:
Das Herstück ist wieder einen Trigger wie folgt zu definieren ('Variable Name' nicht vergessen!):
[img]https://i.imgur.com/4HdeKIX.jpg[/img] is not a valid Image.

Statt "MY_TASK_CHOICE" muss natürlich aus "GUARD", "SAD", "NO_TASK", "AMBUSH" oder "LAMBS_RUSH" gewählt werden.
Falls sich der Trigger nicht schon innerhalb eines großen, aktiven Reveal Triggers befindet, kann das Revealing für diesen Triggerbereich durch ein simples 'true' zugeschaltet werden:

Übergibt man statt dem 'true' den Variablennamen eines Reveal-Triggers ("bramar_reveal_1"), wird dieser Mulittask-Trigger statt zu einem eigenständigen Reveal-Trigger zu einem Remote-Reveal-Trigger.
So könnten bspw. Wachposten an bestimmten Punkten simuliert werden, die sozusagen die Wachen am Schutzobjekt alamieren und die Position an diese durchgeben.

Wichtig ist an dieser Stelle die Ausführung auf dem HC, bzw. dort wo die KI Gruppen Lokal sind!
Sämtliche Gruppen sind dann im Weiteren via 'super_task_trigger_1_1, super_task_trigger_1_2, ..., super_task_trigger_1_n' verfügbar, je nachdem wie viele gespawnt wurden.

Beschreibung:
Spawn Einheiten und ein Fahrzeug.
Lässt die Einheiten einsteigen und führt auf Wunsch zusätzlich einen Task aus.

Verwendung:

Schritt 1:
Siehe Spawn-Wrapper 1. Schritt.

Schritt 2:
Platziere Marker im Eden-Editor:
"altis_airport_technical_1","altis_airport_technical_2",...,"altis_airport_technical_n"

In der initServer.sqf:

Schritt 3:
Beispielsweise in einem Trigger, oder in sonstigem Skript:

Motivation:
Trigger verwalten den Zugang zur Funktionalität in einer Mission.
Leider werden es oft viele und man kann sich nicht immer sicher sein, dass die Spieler nur jene Trigger aktivieren, die für den aktuellen Zeitpunkt im Missionsverlauf vorgesehen sind. Unverhofft werden andere Trigger ausgelöst und plötzlich stimmt bspw. das Kräfteverhältnis von KI und Spieler nicht mehr. Außerdem benötigt die kontinuierliche auswertung jedes Triggers Leistung auf dem Server.

Mit der Phasenverwaltung kann man nun Kompilationen an Triggern einem einzelnen, wenn man so möchte, Objective-Trigger zuordnen.
Erst wenn dieser Objective-Trigger ausgelöst hat, werden die Trigger der nachfolgenden Triggerkompilation freigeschaltet und vom Server ausgewertet.

Verwendung:
Schritt 1:
Registrierung der Kompilation und dem zugehörigen Objective-Trigger in der initServer.sqf:


Man kann beliebig viele dieser Phasen registrieren. Die Reihenfolge der Registrierung legt dabei auch die Reihenfolge der zu erfüllenden Ziele fest.
Man kann auch einzelne Registrierungen auskommentieren, was die Trigger wieder unabhängig von den Objectives verfügbar macht.

Schritt 2:
Danach ruft man ganz kurz und knapp diese Zeile auf, welche die Phasenverwaltung initialisiert.

Kommentiert man diese Zeile aus, sind alle Trigger gewohnt in beliebiger Reihenfolge verfügbar.
Optional:

Dadurch werden Trigger grundsätzlich nur alle 5 Sekunden ausgewertet.
Einzelnen kann natürlich nachträglich noch ein anderes Intervall zugewiesen werden.

Schritt 3:
Und mal wieder die entsprechende Zeile im Objective-Trigger
[img]https://i.imgur.com/PHn9MnS.jpg[/img] is not a valid Image.

Motivation:
Es gibt viele Szenarien in denen man KI ganz präzise im Editor vorplatzieren will und sich wünscht, dass sie dort die Stellung inklusive ihrer Körperhaltung hält und so auch den Kampf aufnimmt. Bspw. im Häuserkampf, bei Straßensperren, Hinterhlaten, usw..
Mit folgenden Einstellungen, die vollständig im Editor (mit W_Missionsbau, unabh. von FL Functions) vorgenommen werden können, lässt sich das problemlos und leistungsschonend umsetzen.
Damit die KI auch wirklich so schön und rechtzeitig (wie im Bild) auf den Spieler feuert, kann ich nur empfehlen, zusätzlich den Reveal-Trigger zu verwenden. Damit dreht sich die KI dann auch automatisch in Richtung des nächst gelegenen Spielers/Feindes.

[img]https://i.imgur.com/ScCHotc.jpg[/img] is not a valid Image.

Verwendung:
Im Editor die betreffende Gruppe auswählen und folgendes in ihre init kopieren:

Die vorplatzierte KI darf leider im Nachhinein nicht mehr auf den HC transferiert werden, da sonst ihre Konfiguration verloren geht.