Studio / ROBLOX
Client und Server in Roblox Studio: Zustände im Test vergleichen
Erkenne die beobachtete Testseite, finde ein Objekt und vergleiche Explorer mit Output. Mit einem Übungsmarker, einer eindeutigen Aufzeichnung und einer Prüfung nach dem Stoppen.
Formuliere eine genaue Zustandsfrage #
„Das Objekt hat sich geändert“ reicht zur Fehlersuche nicht aus. Benenne den Ort: Clientansicht, Serverhierarchie oder Protokoll. Wähle ein harmloses Element in einem getrennten Prototyp, etwa einen verankerten Part namens ContextMarker. Verwende keine Währung, Käufe oder gespeicherten Spielerdaten als Übungsanzeige.
Unsere Frage lautet: „Welchen Eigenschaftswert beobachte ich auf jeder Seite dieses Tests?“ Das ist etwas anderes als mehrere Spieler oder dauerhafte Speicherung zu prüfen. Notiere Workspace → ContextMarker und eine Eigenschaft, beispielsweise Color. Der Marker ist ein Übungsvorschlag; für diesen Artikel wurden weder eigene Spiele verändert noch Studio-Tests ausgeführt.
Starte einen geeigneten Testmodus #
Wähle Test oder Test Here im Testmenü und starte die Simulation. Die Dokumentation beschreibt für diese Solomodi getrennte Client- und Serversimulationen. Test fügt eine Figur ein, Test Here verwendet den Bereich vor der aktuellen Kamera. Für diese Übung brauchst du keine mehreren Clientfenster.
Ersetze den normalen Spielerablauf nicht ohne Prüfung durch Run: Dieser Modus fügt keinen Avatar ein. Notiere Modus und Ausgangsbedingungen, bevor du Werte vergleichst. Falls der Prototyp eine Figur voraussetzt, prüfe ihr Erscheinen. Zwei Aufzeichnungen aus verschiedenen Modi können sich durch ihren Start unterscheiden; beginne deshalb mit einer festen Konfiguration.
Erkenne die aktive Seite #
Nutze während des Solotests den Schalter Client/Server. Sein Zustand zeigt die beobachtete Simulation. Notiere die Seite vor dem Lesen einer Eigenschaft und kontrolliere sie nach dem Umschalten erneut. Eine Kamera beim gleichen Gegenstand bestätigt keinen gleichen Kontext; ähnliche Weltansichten können zu unterschiedlichen Seiten gehören.
Beschrifte Aufzeichnungen mit „Client“ und „Server“, wie in Studio. Ein Hierarchiebild ohne Seitenangabe kann später mit einer anderen Beobachtung verwechselt werden. Unsere beiden Zeichnungspanels stehen für Kontexte, nicht für zwei tatsächlich gestartete Spieler. Sie sind weder Studio-Screenshots noch Nachweise eines laufenden Projekts.
Suche den vollständigen Objektpfad #
Öffne im Clientmodus Explorer und suche den festgelegten Pfad. Schalte zum Server und kontrolliere denselben Pfad und dieselbe Eigenschaft. Prüfe Elternobjekt und Namen: Ein ähnlich benannter ContextMarker in einem anderen Modell ist ein anderes Objekt. Fehlt das Element, notiere dies statt einen erwarteten Wert zu erfinden.
Die Hierarchien unterscheiden sich nach Kontext. Die Roblox-Dokumentation zeigt PlayerScripts auf dem Client sowie ServerScriptService und ServerStorage auf dem Server. Ein Objekt im ServerStorage bestätigt nicht seine Verfügbarkeit beim Client. Bei aktiviertem Streaming erhält der Client anfangs möglicherweise nur Teile des Workspace; das ist eine andere Frage als ein falsch geschriebener Name.
Speichere das Ausgangspaar #
Notiere vor einer Änderung zwei Zeilen: Client, vollständiger Pfad, beobachteter Wert; Server, gleicher Pfad, beobachteter Wert. Ergänze Zeitpunkt oder Szenarioschritt. Nenne Werte nicht gleich, bevor du beide gelesen hast. Die Tabelle dieses Artikels ist ein Aufzeichnungsformat und kein ausgefülltes Protokoll unseres eigenen Tests.
Unterscheiden sich Werte bereits, prüfe zunächst vorhandene Skripte und die Möglichkeit verschiedener Objekte oder Zeitpunkte. Füge kein neues Verhalten über einen ungeklärten Ausgangszustand hinzu. Ein einfacher separater Prototyp erleichtert die Übung, weil du feststellen kannst, was auf die ausgewählte Eigenschaft des Markers einwirkt.
Ändere eine Sache und vergleiche erneut #
Wähle in einem getrennten Übungstest Client und ändere über Properties nur eine beobachtete Markereigenschaft. Notiere sofort die Seite der Änderung und lies danach beide Seiten. Das Ziel ist, Handlungsort und Beobachtungsort zu unterscheiden; damit wird keine allgemeine Regel für jede Roblox-Eigenschaft bewiesen.
Stoppe, stelle die Ausgangsbedingungen wieder her und führe einen getrennten Vergleich mit einer Serveränderung durch. Vermische beide Änderungen nicht in einer unprotokollierten Folge: Ein Skript, eine Verzögerung oder eine weitere Änderung kann das Bild beeinflussen. Bewahre bei unerwartetem Ergebnis beide Aufzeichnungen auf, statt aus einer Farbe eine kaputte Replikation abzuleiten.
Vergleiche mit Output #
Öffne Output und beachte die Herkunft der Meldung. Roblox beschreibt blaue Kennzeichnungen für Clientmeldungen und grüne für Servermeldungen. Bei ModuleScript hängt die Seite vom Aufrufer ab. Die Farbe ist ein zusätzlicher Hinweis; zur Untersuchung brauchst du ebenfalls den Meldungstext und den Pfad seiner Quelle.
Hat dein Prototyp bereits Diagnoseausgaben, vergleiche Zeitpunkt und Objekt mit Explorer. „Bereit“ ohne relevante Seite oder Wert erklärt wenig. In einem erfundenen Fall steht im UI „ausgewählt“, während das Protokoll ein anderes Objekt betrifft. Gleiche Wörter beweisen keine Serverbestätigung dieser konkreten Handlung.
Prüfe Skripttyp und Speicherort #
Fehlt die erwartete Meldung, prüfe Typ, Ort und bei einem Script die Eigenschaft RunContext. Ein Symbol oder das Wort Script allein bestimmt nicht die Ausführungsseite. Laut Roblox kann ein Script abhängig von Kontext und Ort auf Client oder Server laufen; LocalScript läuft auf dem Client.
Verschiebe funktionierende Skripte nicht zufällig, um eine Outputzeile zu erzeugen. Sichere erst Pfade und Einstellungen und vergleiche sie mit der offiziellen Anleitung. Bei ModuleScript zählt zusätzlich der Aufrufer. Ein Verschieben kann weitere Ausführung oder ein anderes Problem verursachen, deshalb verdient jede Änderung eine eigene Beobachtung.
| Prüfung | Warum wichtig |
|---|---|
| Script | Ort und RunContext |
| LocalScript | Clientkontext und geeigneter Ort |
| ModuleScript | Welche Seite das Modul aufruft |
Unterscheide Stoppen und Speichern #
Stop beendet die Simulation und setzt Objekte auf ihren Zustand vor dem Test zurück. Kontrolliere danach den Ausgangsmarker im Bearbeitungsmodus. Eine nur während der Simulation sichtbare Änderung ist nicht automatisch eine gespeicherte Projektänderung. Halte den tatsächlichen Bearbeitungsort fest, statt aus einem vorübergehenden Bild auf Speicherung zu schließen.
Diese Übung prüft weder DataStore noch einen Kauf oder einen erneuten Besuch der veröffentlichten Experience. Ein erfolgreicher Kontextvergleich beweist keine Speicherung zwischen Sitzungen. Dafür brauchst du ein separates Szenario mit passenden Quellen und Bedingungen. Ergänze einen Farbvergleich nicht um eine unbelegte Aussage zur dauerhaften Speicherung.
Formuliere einen begrenzten Befund #
Notiere Testmodus, Änderungsseite, beide Beobachtungsseiten, Pfad, Eigenschaft, Folge und zugehörige Outputmeldung. Formuliere genau: „In diesem Schritt wurde auf dieser Seite dieser Wert beobachtet.“ Liste offene Fragen getrennt auf, etwa andere Clients, Netzwerk, erneuten Beitritt oder wirkliche Spiellogik.
Wiederhole nach einer Korrektur dasselbe Szenario unter den ursprünglichen Bedingungen. Geht es darum, was andere Spieler sehen, verwende einen eigenen Server & Clients-Test; Umschalten ersetzt ihn nicht. Der Artikel bietet eine eigene Methode und Übungszeichnungen, keine tatsächlichen Studio-Ergebnisse, Änderungen an Spielen oder Replikationsmessungen.
| Aufzeichnung | Was speichern |
|---|---|
| Start | Modus und Ausgangsbedingungen |
| Änderung | Seite, Pfad und eine Eigenschaft |
| Beobachtung | Beide Seiten und Outputmeldung |
| Befundgrenze | Noch ungeprüfte Fragen |
Originalquellen
Roblox Creator Hub — Studio testing modesRoblox Creator Hub — Client-server runtime
Roblox Creator Hub — Script types and locations