code terraform debugging: Rover-Skripte Schritt für Schritt reparieren

code terraform debugging ist am effektivsten, wenn du jede Fehlfunktion als eng begrenztes technisches Problem behandelst. Statt mehrere Zeilen gleichzeitig zu ändern, legst du fest, was die Maschine tun sollte, beobachtest, was sie tatsächlich tut, und ermittelst den ersten Punkt, an dem diese Ergebnisse voneinander abweichen.

Ein Rover, der nicht abbauen kann, kann ein Bewegungsproblem, ein ungültiges Ziel, zu wenig Energie, einen vollen Lagerraum oder ein Skript haben, das den Abbaubefehl nie erreicht. Diese Probleme können im normalen Spiel ähnlich aussehen, benötigen aber jeweils eine andere Lösung.

Beginne in einem kurzen, wiederholbaren Testgebiet. Wähle ein nahegelegenes Rohstoffvorkommen, eine mit Strom versorgte Basisverbindung und einen zugänglichen Entladepunkt. Halte die Route einfach, bis das grundlegende Verhalten funktioniert.

Ein nützliches Debugging-Protokoll kann kurz sein:

• Startposition: Wo befand sich der Rover oder die Drone?
• Verfügbare Energie: War die Maschine mit einer funktionierenden Energiequelle verbunden?
• Zielstatus: War der Rohstoff, das Ziel oder der Produktionseingang verfügbar?
• Frachtstatus: War genügend Platz für den nächsten Gegenstand vorhanden?
• Letzte bestätigte Aktion: Welcher Befehl wurde definitiv abgeschlossen?

Dieser Ansatz verhindert einen häufigen Fehler: das sichtbare Symptom zu beheben, während die ursprüngliche Ursache bestehen bleibt. Wenn ein Rover einen Abbauort erreicht, aber ohne Rohstoffe zurückkehrt, funktioniert die Bewegung wahrscheinlich. Prüfe stattdessen das Scanergebnis, die Abbaubedingung, den Lagerstatus und den Auslöser für die Rückkehr.

Die Rover-Automatisierung wird leichter wartbar, wenn das Skript einer vorhersehbaren Abfolge folgt. Ein zuverlässiges Muster lautet Bedingungen prüfen, bewegen, scannen, handeln, überprüfen und zurückkehren. Du kannst dieses Muster an verschiedene Rohstoffrouten anpassen, ohne das gesamte Skript neu aufzubauen.

Verwende eine vorläufige Testroute, bevor du eine lange Abbauschleife erstellst. Die erste Version sollte eine einzige Fahrt durchführen und dann anhalten. Sobald der Rover diese Fahrt zuverlässig abschließt, kannst du wiederholte Schleifen, mehrere Rohstoffziele oder ein fortgeschritteneres Wiederherstellungsverhalten hinzufügen.

Wenn ein Rover unerwartet anhält, vergleiche die letzte erfolgreiche Phase mit der ersten fehlgeschlagenen Phase. Wenn er die Navigation abschließt, aber nie mit dem Abbau beginnt, konzentriere dich auf die Zielerkennung und die Aktionsbedingungen. Wenn er erfolgreich abbaut, aber nicht zurückkehrt, prüfe Frachtlimits, Energiereserven und den Auslöser für die Rückkehr.

Halte das Wiederherstellungsverhalten zunächst einfach. Ein Rover mit niedriger Energie kann zur Basis zurückkehren, pausieren, bis das Aufladen möglich ist, oder sicher anhalten. Ein Skript, das eine fehlgeschlagene Aktion wiederholt versucht, kann Energie verschwenden und es schwieriger machen, das ursprüngliche Problem zu finden.

Automatisierung kann fehlerhaft wirken, obwohl das eigentliche Problem im unterstützenden Netzwerk liegt. Rover- und Drone-Skripte hängen von den Bedingungen in ihrer Umgebung ab, darunter Energieverfügbarkeit, Verbindungsreichweite, Zugänglichkeit des Ziels und der Zeitpunkt von Produktionsaufgaben.

Prüfe das Solarnetz, bevor du ein funktionierendes Skript änderst. Wenn das Netzwerk zu wenig Energie liefert, können Maschinen an unterschiedlichen Punkten derselben Route pausieren. Dadurch entstehen uneinheitliche Ergebnisse: Ein Test gelingt während eines Zeitraums mit hoher Energieversorgung, während ein anderer scheitert, wenn mehrere Maschinen gleichzeitig arbeiten.

Timing-Probleme verdienen besondere Aufmerksamkeit. Ein Skript kann eine Aktion anfordern, bevor das Ziel bereit ist, bevor eine Drone den Eingang geliefert hat oder bevor am Ziel genügend Lagerkapazität vorhanden ist. Füge zwischen wichtigen Aktionen ausdrückliche Prüfungen ein, anstatt anzunehmen, dass jeder Vorgang sofort abgeschlossen wird.

Eine Produktionsroutine kann beispielsweise dieser Logik folgen:

1. Prüfe, ob der benötigte Rohstoff vorhanden ist.
2. Bestätige, dass die Maschine Energie hat.
3. Starte die Produktion.
4. Warte, bis sich der Produktionsstatus ändert.
5. Bestätige, dass der fertige Gegenstand vorhanden ist.
6. Fordere die nächste Lieferung erst an, nachdem das Ergebnis verfügbar ist.

Vermeide eine einzige weit gefasste Bedingung für mehrere voneinander unabhängige Aufgaben. Eine Bedingung wie „fortfahren, wenn Ressourcen vorhanden sind“ sagt möglicherweise nicht aus, ob sich das Material in der Rover-Fracht, im Drone-Lager, einem Fabrik-Eingangsplatz oder einem zentralen Lager befindet. Mache jede Inventarprüfung spezifisch für die betreffende Maschine und das jeweilige Ziel.

Verwende kontrollierte Timing-Tests:

• Führe das Skript nur mit dem Ziel-Rover aktiv aus.
• Wiederhole den Test bei normaler Grundlast des Solarnetzes.
• Füge eine Drone-Route hinzu.
• Füge eine Produktionsmaschine hinzu.
• Vergleiche den Punkt, an dem sich das Verhalten ändert.

Dieser schrittweise Ansatz hilft zu erkennen, ob das Skript fehlerhaft ist oder ob mehrere Maschinen um dieselbe Energie- und Logistikkapazität konkurrieren.

Drone-Automatisierung bringt mehr Abhängigkeiten mit sich als eine einzelne Rover-Route. Ein erfolgreicher Logistikzyklus benötigt eine gültige Quelle, einen verfügbaren Gegenstand, ein Ziel, das ihn aufnehmen kann, und genügend Netzwerkkapazität für den Transfer.

Wenn eine Fabrik anhält, debugge vom Ergebnis rückwärts. Beginne mit dem Gegenstand, den die Fabrik herstellen soll. Bestätige, dass die Maschine mit Energie versorgt und bereit ist, und prüfe anschließend ihr Eingangs-Inventar. Wenn ein Eingang fehlt, verfolge dieses Material zur vorherigen Verarbeitungsstufe und anschließend zur Drone-Route oder Versorgungslinie des Rovers zurück.

Führe einen Logistiktest mit einem einzigen Gegenstand durch, bevor du ein vollständiges Versorgungsnetz aktivierst. Wähle einen Rohstoff und ein Ziel. Wenn diese Lieferung erfolgreich ist, füge das nächste Material oder die nächste Verarbeitungsstufe hinzu. So entsteht eine verlässliche Grundlage für die Erweiterung.

Ein gutes Logistikskript sollte auch mit fehlenden Materialien umgehen, ohne in eine endlose Wiederholungsschleife zu geraten. Füge eine klare Ausweichoption hinzu, etwa Warten, eine andere Quelle anfordern, zur Basis zurückkehren oder die fehlgeschlagene Bedingung zur späteren Überprüfung protokollieren.

Benenne Routen in großen Automatisierungssystemen nach ihrer Funktion statt nach der Maschinennummer. Bezeichnungen wie „Erz-zur-Raffinerie“ und „Batterie-zur-Drone-Bucht“ machen das Debugging schneller als unbenannte Routeneinträge. Weise jeder Route nach Möglichkeit nur eine Aufgabe zu.

Die Erweiterung sollte einer stabilen Reihenfolge folgen:

• Beweise die Gewinnungsroute.
• Beweise die Übergabe an das Lager.
• Beweise die Drone-Lieferung.
• Beweise die Verarbeitungsmaschine.
• Füge Wiederholungen und Prioritätsregeln hinzu.
• Verbinde das fertige Produkt mit der nächsten Kette.

Diese Struktur begrenzt Kaskadenfehler und erleichtert es, einen Teil des Netzwerks auszutauschen, ohne jede aktive Maschine anzuhalten.

Sobald ein Skript in einem kleinen Test funktioniert, solltest du es anhand einer wiederholbaren Checkliste prüfen, bevor du es in einem großen Terraforming-Projekt einsetzt. Das Ziel besteht nicht nur darin, die Maschine einmal zum Laufen zu bringen, sondern auch zu bestätigen, dass sie normale Änderungen bei Energie, Entfernung, Fracht und Produktionsbedarf bewältigen kann.

Verwende die folgenden Reparaturprioritäten:

Wenn eine Lösung funktioniert, notiere, was geändert wurde und unter welchen Bedingungen sie funktioniert hat. Halte die Maschine, Route, das Ziel, den Energiezustand und den Frachtstatus fest. Dadurch entsteht eine praktische Referenz für spätere Automatisierungsaufbauten.

Vermeide mehrere Verbesserungen während eines einzigen Tests. Wenn du gleichzeitig die Route änderst, eine neue Bedingung hinzufügst, die Produktion erhöhst und eine weitere Drone aktivierst, lässt sich das Ergebnis nicht sinnvoll interpretieren. Nimm eine Änderung vor, wiederhole denselben Test und behalte das Ergebnis nur, wenn sich das Verhalten verbessert.

Ein stabiles Automatisierungsnetz entsteht durch kontrollierte Experimente. Beginne mit einer sichtbaren Route mit geringem Risiko, bestätige jede Übergabe und erweitere das System erst, wenn sich die vorherige Stufe vorhersehbar verhält. Mit diesem Vorgehen wird code terraform debugging zu einem wiederholbaren Bestandteil beim Entwurf von Rover-, Drone-, Energie- und Produktionssystemen und nicht zu einer Notfallmaßnahme für eine beschädigte Kolonie.