Bevor die Fehlersuche allerdings beginnen kann, braucht es noch etwas Methodisches. Nämlich braucht es Informationen zur Debug-Konsole und dazu, wie ihr Fehler überhaupt sehen könnt.
Um Skriptfehler angezeigt zu bekommen, müsst ihr einfach folgendes tun: Startet euer Spiel mit dem Parameter -showScriptErrors. Damit werden alle euch auftretenden Fehler kurz in einer schwarzen Box angezeigt.
Wollt ihr diese Fehler nochmal genauer nachlesen oder zusätzliche Informationen bekommen, dann geht in eure .rpt. Die .rpt ist eine Datei, die für jedes Mal, das ihr ArmA startet erstellt wird. Hier werden Log-Einträge vom Spiel abgelegt, so z.B. auch Skriptfehler. Aber auch Dinge wie das Laden des Spiels, etc. Ihr findet die .rpt immer im folgenden Ordner: C:\Users\EUER BENUTZERNAME\AppData\Local\Arma 3

[img]https://dl.dropboxusercontent.com/u/63428639/Bilder/Tutorials/Debuggen%20%26%20Co/scripterror.jpg[/img] is not a valid Image.
Ein Skripterror

Im oberen Bild seht ihr ein Beispiel für einen Skriptfehler. Der gelbe Pfeil zeigt auf den Bereich, in dem die Stelle des Fehlers angegeben wird. Der Fehler tritt das erste Mal bei as auf. Denn vor as steht das Zeichen |#|, das verdeutlichen soll, wo der Fehler aufgetreten ist. In der .rpt wird dies übrigens durch < symbolisiert.
Der blaue Pfeil zeigt auf den Fehler an sich. Hierbei handelt es darum, dass as eine nicht initialisierte Variable ist, d.h. ich habe nirgendwo geschrieben, dass as = ....
Und der grüne Pfeil zeigt auf den Ort, an dem der Fehler auftrat. In diesem Falle der Datei error.sqf mit komplettem Pfad und der Zeile, in der er auftrat.
Ähnlich sind auch die Fehlermeldungen in der .rpt aufgebaut. Nach kurzer Zeit, liest man sich auch dort schnell ein.

Achtung!
Am häufigsten wird wohl die Fehlermeldung "Error missing ;" falsch interpretiert, denn sie bedeutet nicht immer, dass tatsächlich ein Semikolon fehlt. Es kann auch sehr gut sein, dass ihr einen Skriptbefehl falsch geschrieben habt, oder er schlichtweg nirgendwo außer in eurer Imagination existisert.

Die Debug-Konsole ist nicht nur euer Freund und Helfer, nein, nein. Sie ist auch noch super.

[img]https://dl.dropboxusercontent.com/u/63428639/Bilder/Tutorials/Debuggen%20%26%20Co/debugkonsole.jpg[/img] is not a valid Image.
Die Debug-Konsole

Die Debug-Konsole wird von mir hauptsächlich für drei Zwecke verwendet: Entwicklung, Debuggen und Testen.
Aber erstmal eine Erklärung zur Konsole an sich. Auf dem Bild seht ihr drei Bereiche. Die eigentliche Konsole, die mit einem blauen Pfeil markiert ist. Dort könnt ihr Code einfügen und ausführen. Die drei Knöpfe darunter sind für den Multiplayer gedacht. Dort könnt ihr den Code lokal, also nur auf eurem Rechner, ausführen, ihr könnt ihn global, also auf allen Rechnern ausführen und ihr könnt den Code nur auf dem Server ausführen, indem ihr SERVER EXEC drückt. Das kleine Tempometer neben Serverexec sagt euch, wie viele Millisekunden euer Code im Mittel läuft, den ihr eingetippt habt. Damit kann man gut Performance von einzelnen Statements testen.
Der gelbe Pfeil zeigt auf den Watch Bereich. Dort seht ihr den Rückgabewert von irgendwelchem Code oder von Variablen. Hier habe ich z.B. die Variable HIER_VARIABLEN mit dem String "UND HIER STEHT IHR RÜCKGABEWERT" belegt und das Ergebnis zeigt, wie man einfach Testen kann, welchen Wert Variablen haben.

Letzte Worte: Die Debug-Konsole wird immer wichtiger, je besser ihr Skripten könnt! Traut euch wirklich, sie zu benutzen, denn vor allem durch die Benutzung sammelt ihr Erfahrung und bemerkt, was eigentlich alles möglich ist!

Ein paar Tipps zur Debugkonsole:

1. Ihr wollt die Änderung einer Variable die ganze Zeit beobachten? Dann Probiert man den unteren Code aus. Solange ihr in der Debug-Konsole nicht so etwas wie "debug = true" eintippt, wird alle 0.5 Sekunden der Wert von meineVariable im Chat angezeigt, denn solange gilt: isNil "debug":= true.
   [] spawn { while {isNil "debug"} do { systemChat str meineVariable; sleep 0.5; };};


2. Wenn ihr Code testet, benutzt so viele globale Variablen wie möglich! (Also die Variablen ohne _ davor) Dadurch könnt ihr leicht testen, was euer Code so alles berechnet hat und sehr viel leichter Fehler finden.

Die BIKI ist euer Freund und Helfer. Dort findet ihr Informationen rund um ArmA. Am meisten werden ihr aber wohl diese Seite benutzen: Die Skcriptcommands für ArmA 3. Dort ist (fast) jeder Befehl, der in ArmA 3 existiert. Kurz nach einem Patch kann es aber immer mal wieder vorkommen, dass die neusten Befehle noch nicht eingetragen sind.
Und so sieht er aus, ein Eintrag in der BIKI, dieses Mal für den Befehl move. Ich werde euch im folgenden näher bringen, wie ihr diesen Artikel richtig lest und versteht.

[img]https://dl.dropboxusercontent.com/u/63428639/Bilder/Tutorials/Debuggen%20%26%20Co/biki.jpg[/img] is not a valid Image.
Ein Eintrag in der BIKI

Dort seht ihr zuoberst den Titel der Seite, der - simpel - den Befehl anzeigt, um den es nachfolgend gehen wird.
Im grün markierten Bereich seht ihr drei Icons. Ganz links wird angezeigt in welchem Spiel und welcher Version davon dieser Befehls erstmals eingeführt wurde.
Links daneben seht ihr ein kleines A mit einem blauen L daneben. Dieses Symbol bedeutet, dass alle Argumente Lokal sein müssen, wenn dieser Befehl benutzt wird. Da man mit move einer Gruppe befiehlt, zu einer Position zu gehen, bedeutet das, dass die Gruppe lokal sein muss, wo move ausgeführt wird. Stünde dort anstelle des blauen Ls ein orangenes G, bedeutete dies, dass die Argumente nicht lokal sein müssten.
Ganz rechts seht ihr nun ein ähnliches Symbol, nämlich ein kleines E mit einem orangem G. Das bedeutet, dass die Execution Global synchronisiert wird, also dass dieser Skriptbefehl folgen auf allen Rechnern auslösen wird. Was irgendwie logisch ist, denn wie soll sich eine KI Gruppe nur auf einem Rechner bewegen?

Der rote Bereich beschreibt genauer, wann dieser Skriptbefehl eingeführt wurde.

Der gelbe Bereich beschreibt die Funktionalität dieses Befehls.

Der blaue Bereich ist wohl der wichtigste. Hier seht ihr die Syntax. Syntax kann in ArmA sehr, sehr eklig sein. Denn es gibt viele Datentypen. Es gibt Nummern, Strings, Text, Objekte, Gruppen, Seiten, Orte, Arrays, als unterklasse davon Positionen, und, und, und. Wenn dort nun also steht group move position, dann ist dies nicht die breits vollständige Syntaxerklärung dieses Befehls. Dort stehen quasi nur Variablen (group, position), die darunter erklärt werden. So in etwa, wie unter Syntax: muss euer Befehl am Ende aussehen.
Und Paramateres: seht ihr nun, welche Datentypen die Variablen also haben dürfen. group darf eine Gruppe (z.B. group sol) oder ein Objekt (z.B. sol) sein. Position muss ein Array sein ([...] das ist ein Array) , aber das Format einer Position haben! Also [X,Y] oder [X,Y,Z]. Manchmal wird auch Position 2D oder Position 3D explizit gefordert, in diesem Fall könnte man beides verwenden. Eine Position wird zum Beispiel von diesem Befehlen ausgegeben: markerPosition, getPos und position.

Im letzten markierten Bereich steht dann einfach Krams, der gut zu wissen ist. Ihr seht ein Beispiel bei der Verwendung dieses Befehls und erhaltet zusätzliche Informationen. Es lohnt sich auch immer einen Blick in die Notes zu werfen! Dort können Benutzer hilfreiche Kommentare hinterlassen haben. Z.B. gibt es auch einige Befehle, die schlcihtweg keine Funktionalität im fertigen Spiel besitzen. Leider sind das meist die richtig coolen.
Oder ihr findet Tipps zur Verwendung, Infos zu Bugs, etc.

Vorweg ein paar Informationen zu Fehlern. Denn von diesen gibt es zwei Arten:

1. Syntax- & Skriptfehler
2. Logikfehler

Syntax- und Skriptfehler lassen sich sehr leicht finden. Um sicherzustellen, dass eigene Skripte keine Fehler enthalten, reicht es, jede Zeile des Codes einmal ausgeführt zu haben. Erscheint kein Fehler, habt ihr alles richtig gemacht!

Die Logikfehler sind etwas kniffliger, zu finden. Denn diese heißen: Etwas tut nicht, wie es tun sollte, aber es erscheint keine Fehlermeldung. Um diese Fehler zu finden, müsst ihr stark testen. Für Otto-Normal-Missionsbauer, der hauptsächlich Trigger und Wegpunkte benutzt und kaum Skripte, ist dies noch leichter. Wenn ihr eine Mission baut, solltet ihr die Funktionalität aller Trigger überprüft haben.
Beliebte Beispiele für Logikfehler sind:

• > anstelle von < beim Überprüfen von numerischen Werten
• Unendliche while-Schleifen

Die folgende Checkliste sollte euch helfen, die gröbsten Fehler in einer Mission zu finden:

1. Sind alle Trigger auf die richtige Seite, richtige Aktivierung und richtige Bedingung eingestellt? (Ist isServer/isHC in ihnen - falls notwendig?)
2. Sind die Spieler richtig eingestellt? (Auf playable geschaltet? Funtkioniert das Loadout?)
3. Ist das Mission-Briefing (im Editor zu erreichen über Strg+W) richtig eingestellt? (Zeit, Wetter, sind die richtigen Seiten befeindet/befreundet?)
4. Stimmt der Datei und Missionsname?
5. Sind alle Skripte getestet worden?
6. Und zu guter Letzt: Habt ihr die Mission durchgestartet und es erscheint kein Fehler?

... dann sieht das bis jetzt recht gut aus. Ihr solltet die Mission auf den Server - vorzugsweise die Baugrube - laden, um sie da noch einmal abschließend zu testen!

Ohje. Ihr habt einen Fehler gefunden. Was jetzt?
Zuerst solltet ihr versuchen, die Quelle des Fehlers ungefähr ausfindig zu machen. War es ein Skriptfehler? Super! Dann hat euch BIS ja schon genug Mittel an die Hand gegeben, diesen Fehler zu finden und zu beheben. Guckt in die .rpt, guckt in die BIKI, fragt die Bauleitung, wenn alles nicht mehr weiter hilft. Aber viele Erklärungen sollte man darauf nicht mehr verschwenden.

Aber, was tun, wenn es ein Logikfehler ist? Nun, da wird die Sache schon haariger. Denn jetzt müsst ihr gucken, was euer Skript tut. Dazu ein paar Hilfsmittel:

• systemChat STRING; - Dieser Befehl schreibt euch beim Ausführen ganz simpel eine kleine Meldung in den Chat. Sollte das, was ihr in den Chat schreiben wollt kein String sein, setzt den Befehl str davor.
• diag_log X; - Dieser Befehl schreibt euch einfach den Rückgabewert von X in die .rpt. X kann dabei wirklich alles sein.
• X call BIS_fnc_log; - BIS_fnc_log funktioniert quasi wie diag_log, formatiert euer Ergebnis nur schöner und kann z.B. sagen, aus welcher Funktion es ausgeführt wurde.

Mit diesen Hilfsmitteln solltet ihr nun folgendermaßen vorgehen, um einen Fehler zu finden:
Schreibt in alle while-, if-, waitUntil-, etc. Schleifen Debug Befehle, um zu gucken, wo das Skript "landet". Vielleicht wird eine while-Schleife zu früh beendet? Bei einer if-Schleife wird anders entschieden, als ihr eigentlich wolltet?

Sollte der Fehler dann immer noch nicht gefunden sein, dann lasst euch eure Variablen ausgeben. Vielleicht wird ein Parameter nicht richtig übergeben? Vielleicht gibt ein Befehl etwas anderes zurück, als ihr wolltet?

Und zu guter letzt hilft es immer, globale Variablen zu verwenden, um eure Daten zu überprüfen. Dadurch wird oft vieles klarer.

Jetzt habt ihr hoffentlich euren Fehler gefunden, ihn zu beheben, kann man nicht erklären. Dazu gibt es einfach zu viel, was man beachten müsste, aber ich hoffe, dass ich euch helfen konnte, euch in der Missionsbauer-Welt etwas besser zurecht zu finden.

In diesem Abschnitt möchte ich euch noch näher bringen, wie man leicht bestimmte Features testen kann, die in quasi allen Missionen vorkommen. Wenn ihr Vorschläge oder Ergänzungen plant, nennt sie mir einfach!

Die Loadouts
Quasi jeder bei Gruppe W benutzt mittlerweile meine Methode, um Loadouts an den Spieler zu bringen. this setVariable ["loadout","RIFLEMAN"]; und fertig. Nähere Infos zu dem Verfahren an sich findet ihr im Template.
Das Problem dabei ist: Das klappt nur für Spieler. Und es ist sehr aufwändig, jeden Slot einzeln zu testen.
Aber, ich habe eine Methode eingebaut, mit der man im Singleplayer sehr leicht testen kann, ob alles funktioniert.

Schritt 1: Am besten platziert ihr alle Spieler von vorneherein als ganz normale NATO-Soldaten, die andere Uniformen tragen, als sie später tragen sollen.
Schritt 2: Tragt im Singleplayer folgendes in die init.sqf ein:


Achtung! Die Parameter für die Loadouts wurden geändert. Dies sind die neuen Parameter. Wenn bei euch Fehler auftreten sollten, updatet den Kopf der fn_?_loadout.sqf!

Natürlich müsst ihr das Fragezeichen durch den entsprechenden Kürzel ersetzen. Jetzt bekommt auch die KI das Loadout und ihr könnt ganz einfach sehen, ob ihr euch bei den Variablen verschrieben habt. Wenn eine KI immer noch die alte Uniform trägt, die falsche Waffe hat, etc. dann habt ihr euch wohl vertippt. Auch seht ihr, ob eure Loadouts irgendwelche Skriptfehler enthalten.
Was ihr natürlich nicht seht, ist ob eure Loadouts alles korrekt enthalten, das erfordert leider mehr Handarbeit.

Ist die KI auf dem HC?
Dies könnt ihr natürlich nur auf der Baugrube testen. Und, dass eure KI überhaupt spawnt, müsst ihr natürlich auch sicherstellen.
Aber wie findet man heraus, ob der HC auch tatsächlich funktioniert?
Gebt einfach den unten aufgeführten Code in die Debug-Konsole ein und lasst euch folgende Variable in dem Watch bereich ausgeben: countUnitsHC. Nachdem ihr in der Debug-Konsole auf Server Exec gedrückt habt, wird die Nummer, die unter countUnitsHC erscheint, der Anzahl der Einheiten, die auf dem HC lokal sind, sein.
Hier ist der Code:


Und hier seht ihr nochmal ein Bild, wie die Debug-Konsole aussehen könnte:

[img]https://dl.dropboxusercontent.com/u/63428639/Bilder/Tutorials/Debuggen%20%26%20Co/debugkonsole_1.jpg[/img] is not a valid Image.
So könnte ihre Debug-Konsole aussehen