Roblox Studio Output: Ursache finden und Korrektur prüfen

Mit einem wiederholbaren Fall beginnen #

Notiere bei einem Problem deine Handlung, das erwartete Ergebnis und das tatsächliche Ergebnis. Ein Beispiel: „Test gestartet, einmal geklickt, Kaufmeldung erwartet, keine Meldung gesehen.“ Damit kannst du denselben Fall nach einer Änderung erneut prüfen.

Verwende ein eigenes Übungsprojekt. Die Beispiele zeigen Meldungen und vergleichen lokale Werte; sie greifen weder auf Spielergeld noch auf gespeicherte Daten zu. Ziel ist, eine Programmmeldung mit einer Handlung zu verbinden. Übertrage den Ablauf später auf einen kleinen Bereich deines Projekts.

1. Output öffnen und vorbereiten #

Laut aktueller Roblox-Dokumentation findest du Output im Menü Window oder in der Werkzeugleiste des Script-Tabs. Ordne das Fenster so an, dass neue Zeilen beim Test sichtbar bleiben. Bei anderem Layout hilft der Fenstername.

Prüfe Typ-, Kontext- und Textfilter. Entferne für die erste Übung einen Textfilter und zeige Servermeldungen, normale Ausgaben und Warnungen. Aktiviere Show Source für Skriptname und Zeile, soweit vorhanden. Sichere wichtige Meldungen vor dem Leeren. Das Leeren entfernt die Anzeige; den verursachenden Code musst du gesondert korrigieren.

2. Ein Server-Script erstellen #

Füge im Explorer unter ServerScriptService ein normales Script namens OutputPractice ein. Der voreingestellte RunContext Legacy passt zu dieser Serverübung; auch Server ist eine ausdrückliche Möglichkeit. Füge das erste Beispiel ein und prüfe, dass das Script aktiviert ist.

Starte einen Studio-Test. Erwartet werden coins mit 8 und danach die Warnung Unexpected coin count. Prüfe den Server-Kontext. Bei mehreren identischen Paaren suche nach Kopien des Übungsskripts. Jede Kopie erzeugt eigene Zeilen und kann eine einzige Ausführung wie wiederholte Fehler aussehen lassen.

local expectedCoins = 10
local actualCoins = 8
print("coins", actualCoins)

if actualCoins ~= expectedCoins then
    warn("Unexpected coin count")
end

3. Meldung, Warnung und Fehler unterscheiden #

print() zeigt einen Wert oder markiert einen abgeschlossenen Schritt. warn() hebt eine vom Autor gewählte Bedingung hervor. Hier entsteht die Warnung, weil 8 ungleich 10 ist. Lies die auslösende Bedingung, bevor du daraus auf einen Defekt schließt.

Ein Laufzeitfehler bedeutet, dass eine konkrete Operation scheiterte. Lies Text, Quelle und Testschritte zusammen. Die Farbe allein benennt keine Ursache. Prüfe, ob die Zeile zu deinem Script, einer anderen Komponente oder einem früheren Test gehört. Die Grafik trennt die drei Arten von Signalen.

4. Einen Wert ändern und erneut testen #

Stoppe den Test. Ändere im ursprünglichen OutputPractice actualCoins von 8 auf 10; expectedCoins bleibt 10. Beginne einen neuen Test mit geleerter Historie oder notierter Startzeit. Die normale Ausgabe sollte 10 zeigen und die Warnung dieser Bedingung verschwinden.

So prüfst du eine Änderung. Wenn du gleichzeitig Bedingung, Variablennamen und Skriptort änderst, bleibt die entscheidende Ursache unklar. Laufzeitänderungen an Objekten können beim Stoppen zurückgesetzt werden. Bearbeite daher das ursprüngliche Projekt nach Stop und speichere die bestätigte Korrektur.

5. Einen ungefährlichen Laufzeitfehler untersuchen #

Ersetze das Script durch das zweite Beispiel und teste neu. inventory ist absichtlich nil; inventory.Coins kann deshalb kein Tabellenfeld lesen. Erwartet wird ein Fehler beim Zugriff. Der genaue Wortlaut kann variieren, die Quelle sollte zum Beispiel führen.

Stoppe und ersetze local inventory = nil durch local inventory = {Coins = 10}. Beim nächsten Test liefert der Zugriff eine Zahl und Output sollte 10 zeigen. Das korrigiert die Eingabe der Operation. Das bloße Entfernen von print() würde nur die Übung entfernen, ohne die Ursache des ungültigen Zugriffs zu erklären.

local inventory = nil
print(inventory.Coins)

6. Bei fehlenden Meldungen den Start prüfen #

Setze vor das erste Beispiel vorübergehend print("OutputPractice started"). Fehlt auch diese Meldung, prüfe laufenden Test, aktiviertes Script, Container und RunContext. Kontrolliere danach die Output-Filter und den Kontext. Prüfe zunächst, ob der Code die Rechnung überhaupt erreicht.

Bei einem echten LocalScript zählen Client-Ausführung und passender Container. Eine Servermeldung bestätigt keinen Client-Handler. Kurze Markierungen vor und nach einer Aktion grenzen den Bereich ein: nur die erste bedeutet, den Zwischenbereich zu lesen; keine bedeutet, Start oder Anzeige zu untersuchen.

7. Quelle lesen und brauchbare Angaben sichern #

Suche Skriptname und Zeilennummer. Show Source zeigt diese Zuordnung, soweit verfügbar; ein Quelllink führt zum Code. Bei einer Aufrufkette lies auch die aufrufende Stelle. Die Zeile ist ein Einstieg: Ein falscher Wert kann vorher entstanden sein.

Notiere Schritte, erwartetes und tatsächliches Verhalten, Fehlertext, Script und Client- oder Server-Kontext. Ergänze einen kleinen relevanten Codeausschnitt. Entferne vor dem Teilen Zugangsdaten und Spielerdaten. Vermeide Ausgaben in jedem Frame: Der ständige Strom erschwert das Finden der ersten hilfreichen Meldung.

8. Verhalten und Meldungen überprüfen #

Wiederhole die ursprünglichen Schritte. Prüfe, dass das gewünschte Verhalten eintritt und der zugehörige Fehler ausbleibt. Beim ersten Beispiel sind das 10 und keine Warnung aus dem Vergleich; bei einer Schaltfläche die erwartete Aktion. Ein leeres Output-Fenster allein bestätigt keine Reparatur.

Prüfe anschließend einen benachbarten Fall, etwa eine Wiederholung oder eine andere gültige Eingabe. Entferne übermäßige Testmeldungen und behalte nützliche Diagnose. Bleibt das Problem, notiere die neue Beobachtung und ändere wieder eine Ursache. Der kurze Ablauf erhält eine nachvollziehbare, geprüfte Projektversion.