Entwicklung / ROBLOX
Roblox-Menü wird nach dem Respawn zurückgesetzt: ScreenGui und ResetOnSpawn prüfen
Trenne die Vorlage in StarterGui von der laufenden Kopie in PlayerGui und vergleiche drei Platzierungen von ScreenGui. Die schrittweise Übung unterscheidet Menüersetzung von Sichtbarkeit, gespeichertem Fortschritt und Verweisen auf den aktuellen Charakter.
Beschreibe zuerst, was tatsächlich verschwindet #
Die Aussage das Menü wurde zurückgesetzt kann unterschiedliche Ereignisse meinen: Eine Anzeige ist unsichtbar, Text hat seinen Anfangswert, eine gewählte Registerkarte ist geschlossen oder ein altes Objekt wurde ersetzt. Beginne mit einer reproduzierbaren Situation. Öffne beispielsweise eine Lehranzeige für eine Route, ändere ihre Beschriftung und lasse den Charakter neu erscheinen. Notiere Sichtbarkeit, Textwert und Verfügbarkeit des Knopfs getrennt. Eine allgemeine Schlussfolgerung ersetzt diese Beobachtungen nicht.
Unsere Übung verwendet eine erfundene Anzeige mit dem Anfangstext Keine Route gewählt. Nach einer Änderung zeigt sie Nordroute gewählt. Das sind eigene Lehrbeschriftungen für ein separates Projekt und keine Aussagen über Funktionen unserer fünf Spiele. Der Artikel schlägt eine Selbstprüfung anhand offizieller Bedingungen vor. Dieses konkrete Experiment wurde von uns noch nicht in Roblox Studio ausgeführt. Dokumentierte Erwartungen werden daher nicht als gemessene Prüfergebnisse präsentiert.
Unterscheide Vorlage und Spielerinstanz #
Das offizielle Handbuch beschreibt StarterGui als Ort zur Vorbereitung der Bildschirmschnittstelle. Beim ersten Erscheinen des Charakters werden ScreenGui und Inhalte in PlayerGui dieses Spielers kopiert. Für die Übung ist die Trennung beider Orte entscheidend. Die vor dem Start vorbereitete Beschriftung gehört zur Vorlage. Eine Änderung im laufenden Exemplar liefert einen beobachtbaren Marker dafür, ob der Zustand dieser Sitzung nach dem erneuten Erscheinen erhalten bleibt.
Notiere vor dem Test zwei Pfade: den ursprünglichen Container unter StarterGui und die unter Players, beim gewählten Spieler und in PlayerGui gefundene Kopie. Bearbeite keine ähnlich benannte Anzeige nur wegen ihres vertrauten Namens. Prüfe während des Versuchs, ob du die Instanz des gewählten Clients änderst. Kontrolliere nach dem Stoppen erneut die Ausgangshierarchie. Vorübergehende Laufzeitänderungen dürfen nicht unbemerkt andere Anfangsbedingungen für den nächsten Vergleich werden.
Bereite drei unabhängige Platzierungen vor #
Erstelle ein separates Lehrprojekt mit gewöhnlichem Erscheinen des Charakters. Platziere einen eindeutig benannten ScreenGui RespawnA direkt unter StarterGui und setze ResetOnSpawn=true. Ergänze daneben RespawnB mit ResetOnSpawn=false. Lege anschließend unter StarterGui einen Folder namens RespawnFolder an und darin den dritten ScreenGui RespawnC, ebenfalls mit ResetOnSpawn=false. Namen und Anordnung sind eigene Bezeichnungen der Übung, damit die Vergleichsfälle nicht miteinander verwechselt werden.
Erstelle in jedem ScreenGui einen einfachen TextLabel namens RouteLabel mit dem Anfangstext Keine Route gewählt. Platziere die drei Beschriftungen in verschiedenen Bildschirmbereichen, sodass sie sich nicht überdecken. Ergänze zunächst keinen Laden, keine Speicherstände, kein Ressourcenladen und keine aufwendigen Handler. Die erste Aufgabe betrifft nur den Containerlebenszyklus. Notiere vollständigen Pfad und Eigenschaftswert jeder Platzierung vor dem Start, damit die spätere Tabelle tatsächliche Bedingungen beschreibt.
Bild in voller Größe öffnen ↗Lies die gesamte ResetOnSpawn-Bedingung #
Die Bedingungstabelle des offiziellen Handbuchs ordnet ResetOnSpawn=true dem Zurücksetzen zu. Zum Erhalten sind false und ein ScreenGui direkt unter StarterGui erforderlich. Ein indirekter Nachkomme, etwa ein ScreenGui in einem Folder unter StarterGui, wird ebenfalls zurückgesetzt. false allein zu prüfen reicht deshalb nicht: Die Platzierung ist Teil der Bedingung. Das erklärt, warum ein Verschieben in einen Ordner die Erwartung ändern kann, obwohl die Eigenschaft gleich bleibt.
Für unsere Namen lauten die dokumentierten Erwartungen: A wird zurückgesetzt, B bleibt erhalten, C wird zurückgesetzt. Trage diese zunächst in eine Spalte erwartet ein, nicht in beobachtet. Fülle die zweite Spalte erst nach einer eigenen Prüfung. Bei einer Abweichung bewahre beide Einträge und prüfe Pfad, Eigenschaft und Laufzeitinstanz erneut. Schreibe die Bedingungen nicht rückwirkend um, als wäre von Anfang an eine andere Platzierung getestet worden.
| Platzierung | Erwartung |
|---|---|
| A: direkt,true | Container zurückgesetzt |
| B: direkt,false | Container erhalten |
| C: im Folder,false | Container zurückgesetzt |
Ändere den Zustand der laufenden Kopie #
Starte das Lehrprojekt und warte auf den Charakter und lesbare Beschriftungen. Suche die drei Container anhand der eindeutigen Namen in PlayerGui des ausgewählten Clients. Setze den Text-Wert jedes laufenden RouteLabel auf Nordroute gewählt. Bestätige, dass die richtige Anzeige den neuen Text zeigt. Ändere nicht gleichzeitig die Vorlage unter StarterGui. Sonst könnte eine neue Kopie wie eine erhaltene alte aussehen und den Vergleich unbrauchbar machen.
Notiere Anfangstext, geänderten Text und den Weg der Änderung. Kannst du das richtige Objekt nicht finden oder verändert sich seine sichtbare Beschriftung nicht, untersuche zuerst diesen Schritt. Ohne bestätigten Ausgangszustand ist der spätere Vergleich mehrdeutig. Ein verständlicher Marker reicht. Mehrere versteckte Einstellungen und gleichzeitig arbeitende Menüs ergänzen Ursachen, die sich schwer von einer ScreenGui-Ersetzung unterscheiden lassen und die Wiederholung unnötig kompliziert machen.
Lasse den Charakter neu erscheinen und vergleiche #
Verwende die im Test verfügbare Respawn-Aktion und warte auf einen steuerbaren Charakter sowie die zurückkehrende Schnittstelle. Lies anschließend A, B und C getrennt. Notiere für jeden Fall, ob die geänderte Beschriftung bleibt, der Anfangstext zurückkehrt oder die Anzeige überhaupt sichtbar ist. Der Zustand nach dem Respawn zählt mehr als ein kurzes Verschwinden während des Übergangs. Ein Wartebildschirm ist noch nicht das zu vergleichende Endergebnis.
Wiederhole den Vergleich einmal, nachdem du den aktuellen Instanzen erneut eine eindeutige geänderte Beschriftung gegeben hast. Unterscheiden sich die beiden Ergebnisse, mache aus einem Versuch keine allgemeine Regel. Bewahre den Kontext: vorhandene Objekte, Ort der Wertänderung und weitere laufende Skripte. Hier wird eine Prüfreihenfolge vorgeschlagen. Tatsächliche Beschriftungen und Erscheinungszeiten stammen aus deinem eigenen Lauf und dürfen nicht aus der Erwartungstabelle übernommen werden.
Bild in voller Größe öffnen ↗Verwechsle Enabled nicht mit Ersetzung #
Enabled steuert Sichtbarkeit und Aktivität eines Bildschirmcontainers. Laut offiziellem Handbuch zeichnet ein deaktivierter Container seine Inhalte nicht und verarbeitet keine Eingaben. Das ist eine andere Frage als Löschen und erneutes Klonen beim Respawn. Ist eine Beschriftung nicht verfügbar, prüfe Enabled am aktuellen ScreenGui. Untersuche danach weitere Sichtbarkeitsursachen wie die Position des Kindelements, eine überdeckende Anzeige oder eigene Einblendelogik, statt jede fehlende Beschriftung als Ersetzung zu deuten.
Gib Enabled eine eigene Protokollspalte und ersetze damit nicht Text erhalten. Eine verborgene Anzeige kann den geänderten Text enthalten; eine sichtbare neue Anzeige kann den Anfangstext enthalten. Ein gleicher Containername beweist ebenfalls keine identische Instanz. Ein strenger Vergleich von Objektverweisen braucht eine separate instrumentierte Prüfung. Unser Textmarker untersucht den beobachtbaren Zustand einer Anzeige und wird nicht als vollständiger Nachweis der Objektidentität dargestellt.
Prüfe Abhängigkeiten vom aktuellen Charakter #
Ein erhaltenes Menü bedeutet nicht, dass alles damit Verbundene automatisch aktuell wird. Sein eigener Code kann beispielsweise noch einen Verweis auf den Charakter vor dem Respawn halten. Trenne die Anforderungen gewählte Registerkarte erhalten und Angaben über den neuen Charakter aktualisieren. Das sind verschiedene Entwicklungsaufgaben. Bestimme zuerst, welche Daten eine Benutzerauswahl ausdrücken und welche einem aktuellen Spielobjekt statt dessen früherem Vorgänger folgen müssen.
Erstelle für die Lehranzeige eine Abhängigkeitsliste: gewählte Route, Lebensanzeige, Character-Verweis und verbundene Ereignisse. Nur die erste Aufgabe betrifft unmittelbar unseren Textmarker. Die anderen benötigen eigene Prüfungen in der tatsächlichen Umsetzung. Versprich nicht, dass ResetOnSpawn=false allein veraltete Verweise repariert. Neue Ereignisverbindungen brauchen auch einen klaren Besitzer und die Bereinigung der alten Verbindung, damit eine Menüreparatur nicht versehentlich wiederholte Reaktionen erzeugt.
Unterscheide erhaltene Oberfläche und gespeicherten Fortschritt #
Eine Beobachtung nach dem Respawn betrifft den Oberflächenzustand im aktuellen Lauf. Sie bestätigt nicht, dass die Routenwahl nach dem Verlassen, auf einem anderen Gerät oder nach einem Serverwechsel erhalten bleibt. Diese Anforderungen benötigen eigene Daten und Prüfungen des Speicherverfahrens. Nenne ResetOnSpawn kein Speichersystem. In der Übung ist der geänderte Text ein Marker des Menüzustands und keine dauerhaft gespeicherte Spielerleistung oder bestätigte Wiederherstellung von Fortschritt.
Ist CharacterAutoLoads deaktiviert, verbindet das Handbuch das anfängliche Kopieren von StarterGui mit einem Aufruf von LoadCharacterAsync. Ein solches Projekt unterscheidet sich von unserem einfachen Aufbau. Notiere zunächst den Modus und prüfe dann den Zeitpunkt des ersten Erscheinens der Schnittstelle. Vermische das Fehlen der ersten Kopie nicht mit dem Verschwinden nach einem späteren Spawn. Beginne mit gewöhnlichem Erscheinen und ergänze andere Modi als eigene Fälle mit separaten Erwartungen.
Beende den Vergleich mit einer klaren Tabelle #
Bewahre für A, B und C den Pfad, ResetOnSpawn, erwartetes Verhalten, beobachteten Text nach jedem Versuch und Enabled auf. Ergänze, dass der Vergleich keine Speicherstände, sämtliche Handler oder Verweise auf den neuen Character abdeckt. So kann ein anderer Entwickler die Situation wiederholen und die Grenzen der Schlussfolgerung verstehen. Hast du nur die direkte Platzierung B getestet, beschreibe das nicht als ausgeführte Prüfung aller drei Fälle.
Wähle nach dem Vergleich einen Lebenszyklus, der zum Zweck deines Menüs passt. Einmalige Einführung, Einstellungen und Charakterinformationen können unterschiedliche Zustandsregeln benötigen. Definiere das gewünschte Verhalten vor der Einrichtung von Container und Code. Die eigene Übung verändert keine veröffentlichten Spiele und verwendet keine fremden Bildschirmfotos. Prüfe aktuelle Bedingungen anhand offizieller Quellen und übernimm in den Ergebnisbericht nur Beobachtungen, die du tatsächlich in deiner Umsetzung gewonnen hast.
| Feld | Protokolleintrag |
|---|---|
| Pfad | Vollständiger Pfad |
| ResetOnSpawn | Tatsächlicher Wert |
| Text nach Respawn | Beobachtung,keine Erwartung |
| Enabled | Getrennt vom Textzustand |
Originalquellen
Roblox Creator Hub — On-screen UI containersRoblox Creator Hub — LayerCollector
