Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- scripting:tutorials:level1:common_errors [2024/05/16 11:03] – fritz_98
+++ scripting:tutorials:level1:common_errors [2024/05/16 14:30] (aktuell) – [Fehler im Mapdesign] fritz_98
@@ Zeile 5: / Zeile 5: @@
 ====Syntaxfehler====
-Syntaxfehler sind Fehler, bei denen dein Skript gegen die "Grammatik" der Skriptsprache verstößt. Beispielsweise ist das Schreiben einen öffnenden Klammer und Auslassen einer schließenden Klammer ein Syntaxfehler. Die Fehlermeldungen im Debugger geben dir an, gegen welche Grammatikregel nicht eingehalten wurde und in welcher Zeile der Fehler passiert ist. Auch werden Syntaxfehler in Visual Studio Code **rot** markiert, sodass sie leicht zu finden sind.
+Syntaxfehler sind Fehler, bei denen dein Skript gegen die "Grammatik" der Skriptsprache verstößt. Beispielsweise ist das Schreiben einen öffnenden Klammer und Auslassen einer schließenden Klammer ein Syntaxfehler. Die Fehlermeldungen im Debugger geben dir an, welche Grammatikregel nicht eingehalten wurde und in welcher Zeile der Fehler passiert ist. Auch werden Syntaxfehler in Visual Studio Code **rot** markiert, sodass sie leicht zu finden sind.
 Einige Beispiele:
@@ Zeile 137: / Zeile 137: @@
 ====Variablennamen und Strings====
+Es kann zu Beginn schwer fallen, Variablennamen und Strings zu unterscheiden, weil beide als Zeichenkette geschrieben werden. Die Unterscheidung ist aber wichtig, um Fehler zu vermeiden und Code von Anfang an korrekt zu strukturieren.
+Beispielsweise kannst du für jeden einzelnen KI-Spieler eine Funktion definieren, in der die Parameter für diesen KI-Spieler definiert werden:
+<code lua>
+function CreatePlayer2()
+    -- ...
+end
+function CreatePlayer3()
+    -- ...
+end
+function CreatePlayer4()
+    -- ...
+end
+</code>
+So aufgebaut ist es können die Funktionen **nicht** in einer Schleife aufgerufen werden, also z.B:
+<code lua>
+for i = 2, 4 do
+    CreatePlayer .. i()
+end
+</code>
+Die ''CreatePlayer''-Funktionsnamen sind **Variablennamen** und keine Strings, weshalb auch keine String-Operationen auf ihnen durchgeführt werden können. Der Beispielcode oben resultiert in einem Syntaxfehler.
 \\
@@ Zeile 156: / Zeile 178: @@
 <code lua>
 -- Variante 1
-function BriefingMentor()
+function CreateBriefingMentor()
     local Briefing = {
         {
@@ Zeile 172: / Zeile 194: @@
 <code lua>
 -- Variante 2
-function BriefingMentor()
+function CreateBriefingMentor()
     local Briefing = {
         {
@@ Zeile 192: / Zeile 214: @@
 ====Funktion nicht aufgerufen====
-**Hinweis**: Unbenutzte //lokale// Variablen werden in VSC blasser dargestellt und sind daher leicht zu finden.
+Achte darauf, dass du definierte Funktionen auch an der korrekten Stelle aufrufst. Andernfalls kann der Questablauf unterbrochen werden, weil dafür notwendige Aufrufe nicht stattgefunden haben. Unbenutzte Funktionen werden in VSC nicht angezeigt.
+**Tipp**: Unbenutzte //lokale// Variablen werden in VSC blasser dargestellt und sind daher leicht zu finden.
+\\
 ====SimpleJob nicht beendet====
+SimpleJobs werden ab ihrem Start so lange jede Sekunde ausgeführt, bis sie beendet werden. Meistens bewerkstelligt das man mit ''return true'' in der SimpleJob-Funktion, sobald eine Bedingung erfüllt ist. Lässt man das Beenden des Jobs aus, kann das zu unerwünschtem Verhalten führen.
+Ein Beispiel: Sobald Dario sich seiner Burg nähert, soll ein Briefing abgespielt werden:
+<code lua>
+function FirstMapAction()
+    StartSimpleJob("IsDarioNearHQ")
+end
+-- Das Setup hier ist das gleiche wie beim Beispiel oben zu Funktionsnamen und Funktionsaufrufen
+function IsDarioNearHQ()
+    -- Die Funktion IsNear prüft, ob die beiden Entities höchstens die angegebene Distanz zueinander haben
+    -- Der SimpleJob fragt also jede Sekunde, ob "Dario" höchstens einen Abstand von 800 Scm zu "Player1" hat
+    if IsNear("Dario", "Player1", 800) then
+        -- Ist das der Fall, soll ein Briefing gestartet werden
+        CreateBriefingDario()
+    end
+end
+</code>
+In diesem Beispiel wird das Briefing gestartet, sobald sich Dario der Burg nähert. Dadurch, dass der Job nie mit ''return true'' beendet wird, wird das Briefing **jede Sekunde** gestartet, in der Dario in der Nähe der Burg ist. Da man während Briefings keine Einheiten steuern kann, wird das dazu führen, dass das Spiel an dieser Stelle feststeckt.
+\\
 ====Parameter verwechselt====
+Jedes mal, wenn du Argumente an eine Funktion übergibst, solltest du dir klar machen, in welcher Reihenfolge diese zu übergeben sind. Wenn du [[ scripting:tutorials:visual_studio |Visual Studio mit der S5-Doku]] korrekt aufgesetzt hast, wird für die meisten Funktionen ein Hilfetext angezeigt.
+Leider sind die Parameter in Siedler 5 - Funktionen nicht konsistent definiert. So gibt es zum Beispiel die Funktionen
+<code lua>
+-- Gib Spieler _PlayerId _Amount Gold-Einheiten
+AddGold(_PlayerId, _Amount)
+-- Verbiete Spieler _PlayerId die Technologie _Technology
+ForbidTechnology(_Technology, _PlayerId)
+</code>
+Bei der einen Funktion steht die ''_PlayerId'' vorne, bei der anderen hinten. Das kann leicht zu Verwechslungen führen. So ist ein fehlerhafter Aufruf wie dieser hier denkbar:
+<code lua>
+AddGold(500, 2)
+</code>
+Das drückt aus, dass du Spieler mit der Id 500 (existiert nicht im Spiel) 2 Gold geben möchtest. Da das nicht möglich ist, wird der Funktionsaufruf wirkungslos bleiben.
+Leicht falsch zu bedienen sind Funktionen, die viele Parameter anbieten, wie ''MapEditor_SetupAI'':
+<code lua>
+-- Geplant ist, eine KI der Stärke 2 mit Technologiestufe 0 zu erstellen
+MapEditor_SetupAI(2, 0, 32000, 2, "Player2", 2, 0)
+</code>
+Hier wurden die Argumente für ''_Strength'' und ''_Techlevel'' vertauscht, sodass die KI inaktiv bleibt, da ''_Strength = 0'' bedeutet, dass die KI ausgeschaltet ist.
+\\
 ====Logikfehler====
-====KI ist inaktiv====
+Logikfehler bedeuten, dass du zwar aus programmiertechnischer Sicht alles richtig gemacht hast, im Spiel aber nicht das passiert, was du möchtest. Diese Fehler sind schwieriger zu beheben, da man sich zuvor einen Überblick über das gesamte Skript und den dazugehörigen [[ scripting:tutorials:drafting |Plan]] für die Karte verschaffen muss.
+Beim Ausmerzen von Logikfehlern zahlt es sich aus, im Voraus einen möglichst konkreten Plan ausgearbeitet und [[ scripting:tutorials:level1:readable_code |gut lesbaren Code]] geschrieben zu haben. Der Code lässt sich so schneller mit dem Plan abgleichen, um festzustellen, wo die beiden voneinander abweichen.
+\\
+====Fehler im Mapdesign====
+Fehler können auch im Mapdesign geschehen. Vor allem Blocking an der falschen Stelle kann den Mapablauf empfindlich stören, beispielsweise:
+  * Eine KI rekrutiert Truppen, greift aber trotz feindlicher Gesinnung den Spieler nie an. Häufig ist die Ursache, dass das Gelände auf dem Weg zum Spieler blockiert ist, die KI also gar nicht zu ihm gelangen kann
+  * Rohstoffschächte sind durch Texturen, Terrainhöhe oder Felsen blockiert, sodass Leibeigene nicht daran arbeiten oder Minengebäude nicht errichtet werden können
+  * Große Teile des für den Spieler vorbereiteten Bauplatzes können ebenfalls durch Blocking von seiner Startposition getrennt sein und die Map so ungleich schwieriger oder gar unmöglich zu schaffen machen
+Für solche Fehler, die nur im Editor behoben werden können, ist das Grid (Shortcut Ctrl + G) das wichtigste Werkzeug. Mit aktiviertem Grid wird blockiertes Terrain rot dargestellt. Halte Ausschau nach Terrainhöhen, Texturen, Objekten oder unsauberen Wasserflächen, die unerwünschtes Blocking verursachen.
+----
+Zu guter Letzt beschäftigen wir uns im nächsten Kapitel mit dem Balancing einer Karte.
+[[ scripting:tutorials:level1:debugging | Voriges Kapitel: Fehler finden und beheben ]] \\
+[[ scripting:tutorials:level1:balancing | Nächstes Kapitel: Balancing ]] \\
+[[ scripting:tutorials:level1:common_errors | Zurück nach oben ]]