24.05.2015 um 00:25
Anonymer Benutzer
Anonymer Benutzer
Forenprofi
Laborratte
Eine ArmA-3 Modifikation für Gruppe W erstellt
Beiträge: 1694
Registriert am: 20.01.13
So liebe Leute,
als Erstes möchte ich bei denjenigen bedanken, die heute mitgetestet haben, denn durch den Test konnte ich das Problem der Mission ausfindig machen.
Da ich dieses Problem ausfindig machen konnte und es größtenteils auch behoben habe, werde ich die Mission in absehbarer Zeit erneut anbieten.
Gut für euch zu wissen ist: Eine Co58 scheitert (noch) nicht an unserem Modset, dem Server oder ArmA 3 allgemein. Es ist also noch alles drin!
Ich überlege noch, ob ich die Slots werde bestätigen lassen, oder nicht, das werdet ihr dann aber mitkriegen.
als Erstes möchte ich bei denjenigen bedanken, die heute mitgetestet haben, denn durch den Test konnte ich das Problem der Mission ausfindig machen.
Da ich dieses Problem ausfindig machen konnte und es größtenteils auch behoben habe, werde ich die Mission in absehbarer Zeit erneut anbieten.
Gut für euch zu wissen ist: Eine Co58 scheitert (noch) nicht an unserem Modset, dem Server oder ArmA 3 allgemein. Es ist also noch alles drin!
Ich überlege noch, ob ich die Slots werde bestätigen lassen, oder nicht, das werdet ihr dann aber mitkriegen.
Spoiler: Anzeigen: Wen die technische Seite interessiertAusblenden: Wen die technische Seite interessiert
Meine Mission verwendete eine missionFlow.fsm (finite state machine, endlicher Automat, aber nicht im streng theoretischen Sinn), der über den Ablauf der Mission wachen sollte.
Die missionFlow.fsm ist ein Event Script, das zu Beginn der Mission global aufgerufen wird. Ganz zu Beginn macht diese .fsm folgendes:
Unter der Bedingung, dass wir nicht der Server sind, geht der Automat in einen Endzustand, damit die .fsm nur auf dem Server ausgeführt wird.
Unter einer anderen Bedingung, die einfach wahr ist, wird die .fsm ausgeführt.
Die Prioritäten dieser beiden Bedingungen habe ich vertauscht, sodass nie überprüft wurde, ob die .fsm auf dem Server ausgeführt wurde. Dadurch wurde die .fsm auf dem Computer jedes Spielers ausgeführt.
Durch eine falsche Abfrage innerhalb der .fsm wurde zusätzlich direkt nach Aufruf der .fsm ein Gegenangriff ausgelöst und das auf jedem Computer, sodass direkt bei Mission ohne irgendwelche Pausen pro Spieler ~30 Soldaten gespawnt wurden.
Beim Test ist mir das aufgefallen, weil extrem viele Soldaten auf dem Feld waren. Und das innerhalb kürzester Zeit.
Um das Ganze sicherer zu gestalten, werde ich die Netzwerkarbeit noch ein wenig umbauen, sodass solche Fehler nicht mehr passieren können.
Dieser Fehler konnte dadurch entstehen, dass die ganze Sache ziemlich komplex war. Und wie wir wissen, ziehen komplexe System schwer zu findende Fehler nach sich. (Wie übrigens sogar schon bewiesen wurde.)
Beim Testen ist mir der Fehler nicht aufgefallen, weil er eben nur ins Gewicht fällt, wenn man sieht, dass wirklich sehr viel mehr KI als beabsichtigt sich auf dem Schlachtfeld tummelt.
Die missionFlow.fsm ist ein Event Script, das zu Beginn der Mission global aufgerufen wird. Ganz zu Beginn macht diese .fsm folgendes:
Unter der Bedingung, dass wir nicht der Server sind, geht der Automat in einen Endzustand, damit die .fsm nur auf dem Server ausgeführt wird.
Unter einer anderen Bedingung, die einfach wahr ist, wird die .fsm ausgeführt.
Die Prioritäten dieser beiden Bedingungen habe ich vertauscht, sodass nie überprüft wurde, ob die .fsm auf dem Server ausgeführt wurde. Dadurch wurde die .fsm auf dem Computer jedes Spielers ausgeführt.
Durch eine falsche Abfrage innerhalb der .fsm wurde zusätzlich direkt nach Aufruf der .fsm ein Gegenangriff ausgelöst und das auf jedem Computer, sodass direkt bei Mission ohne irgendwelche Pausen pro Spieler ~30 Soldaten gespawnt wurden.
Beim Test ist mir das aufgefallen, weil extrem viele Soldaten auf dem Feld waren. Und das innerhalb kürzester Zeit.
Um das Ganze sicherer zu gestalten, werde ich die Netzwerkarbeit noch ein wenig umbauen, sodass solche Fehler nicht mehr passieren können.
Dieser Fehler konnte dadurch entstehen, dass die ganze Sache ziemlich komplex war. Und wie wir wissen, ziehen komplexe System schwer zu findende Fehler nach sich. (Wie übrigens sogar schon bewiesen wurde.)
Beim Testen ist mir der Fehler nicht aufgefallen, weil er eben nur ins Gewicht fällt, wenn man sieht, dass wirklich sehr viel mehr KI als beabsichtigt sich auf dem Schlachtfeld tummelt.
