Headless Client

Aus Nitradopedia
Wechseln zu: Navigation, Suche

Ein Headless Client (HC) ist ein zusätzlicher ArmA 3 Server Prozess, der die Berechnung der KI übernimmt und dadurch den Server entlastet.

Sowohl auf unseren Test- als auch auf dem Eventserver läuft jeweils ein Headless Client (HC). Theoretisch kann auch mehr als ein Headless Client genutzt werden.

Theorie

ArmA 3 hat keine gute Unterstützung von Mehrkernprozessoren. Zwar kann ArmA 3 bis zu 7 zusätzliche Threads starten, sodass 8 aktiv sind, jedoch ist die Auslastung dieser nicht gleichmäßig. Der Großteil der Berechnung für Trigger, Skripte und der KI läuft auf einem Thread. Dies kann den Server überlasten (geringere FPS oder KI wird dümmer).

Der Headless Client ist eine weiterer ArmA 3 Prozess, der sich mit auf dem eigentlichen Server verbindet und die Berechnung der KI übernimmt. Dessen Berechnung ist - vor allem mit KI-Mods wie VCOM AI - sehr aufwändig.

Nur ein Admin sieht den Headless Client.

Praxis

Der Missionsbauer muss eine spielbare Einheit des Headless Client setzen. Das alleine reicht aber nicht aus, da dann nur ein weiterer Spieler auf dem Server ist. Der Headless Client muss noch KI erhalten, die berechnet werden soll.

Auch wenn der Missionsbauer nicht den Headless Client nutzen möchte, muss er das Modul (bei uns) setzen. Denn der Headless Client zählt als Spieler, nimmt einen Platz weg und eine Person weniger kann an der Mission teilnehmen. Wie oben angedeutet, passiert dadurch aber nichts Böses bzw. Tolles (je nach Interpretation).

ACEX

Mit Hilfe von ACEX ist ein komfortables Modul im Repository. Wenn man dieses korrekt setzt, wird in regelmäßigen Abständen die komplette KI auf den HC (bzw. auf mehreren) verteilt. Dies könnte man auch selbst mit setGroupOwner machen.

Einstellungen

  • Enabled: Enabled
  • Delay: 15 (in Sekunden)
  • End Mission: Delayed (60s)
  • Log: Disabled

Lokalitätsprobleme

Ein beliebter Fallstrick beim Skripten ist die Lokalität. Es macht einen Unterschied, ob eine KI auf dem Server ist oder einem Client. Im Editor platzierte Einheiten sowie Objekte "gehören" dem Server, wenn etwas im Zeus platziert wird "gehört" das Objekt dem Zeus.

Ein weiteres Problem ist die Synchronisation von Objekten. Wenn ein Wegpunkt mit einem Trigger verbunden ist, reicht es in der Regel, dass nur auf dem Server der Trigger aktiv ist. Wird die KI aber auf einem Headless Client berechnet, kriegt dieser zum einem nichts von der Aktivierung des Trigger mit und zum anderen geht die Synchronisierung verloren, selbst wenn der Trigger auf allen Clients aktiv ist.

Deswegen werden bei ACEX keine Gruppen auf den Headless Client transferiert, die mit einem Trigger synchronisiert sind.

Wegpunkte

Im Folgenden wird eine beispielhafte Lösung für den einfachen Fall der Wegpunkt-Aktivierung skizziert.

Ein Feindnachschub soll nach Erobern eines Gebietes los gehen. Deswegen befindet sich ein Trigger im Gebiet (Server Only), der aktiv wird, wenn die Spieler (bzw. BlueFor-Kräfte) in einem Gebiet sind.

ohne HC

Am Kontextmenü des Move-Wegpunktes am Spawnpunkt des Feindnachschubes wird Connect → Set Waypoint Activation ausgewählt und auf dem Trigger links geklickt. Dadurch wird der Wegpunkt bzw. dessen Aktivierung mit dem Trigger verbunden (blaue Linie).

mit HC

In der Bedingung (Condition) des Move-Wegpunktes am Spawnukt steht statt true:

missionNamespace getVariable ["ambushA", false];

Bei Aktivierung (On Activation) des Triggers wird folgender Code ausgeführt.

missionNamespace setVariable ["ambushA", true, true];