Разработка / ROBLOX
Меню Roblox сбрасывается после возрождения: как проверить ScreenGui и ResetOnSpawn
Отличите шаблон в StarterGui от игрового экземпляра в PlayerGui и сравните три варианта размещения ScreenGui. Пошаговое упражнение поможет понять замену меню, не смешивая её с видимостью, сохранением прогресса и ссылкой на персонажа.
Сначала опишите, что именно исчезает #
Фраза «меню сбросилось» может означать разные события: панель больше не видна, текст вернулся к исходному, выбранная вкладка закрылась или старый объект был заменён новым. Начните с одной воспроизводимой ситуации. Например, откройте учебную панель маршрута, измените её подпись и возродите персонажа. Запишите отдельно видимость, значение подписи и доступность кнопки. Один общий вывод не заменяет эти наблюдения.
Для упражнения используем вымышленную панель с текстом «Маршрут не выбран». После изменения она показывает «Выбран северный маршрут». Это придуманные подписи для отдельного учебного проекта, а не сведения о функциях пяти игр автора. Ниже дан план самостоятельной проверки на основе официальных условий. Мы пока не запускали именно этот эксперимент в Roblox Studio и не приводим его ожидаемые результаты как измеренный отчёт.
Разделите шаблон и экземпляр игрока #
Официальное руководство описывает StarterGui как место подготовки экранного интерфейса: при первом появлении персонажа ScreenGui с содержимым копируется в PlayerGui конкретного игрока. Для нашего упражнения важно различать эти два места. Подпись, которую вы подготовили до запуска, относится к шаблону. Изменение подписи в игровом экземпляре позволяет наблюдать, сохранится ли состояние этой сессии после возрождения.
Перед тестом запишите два пути: исходный контейнер в StarterGui и найденную копию в Players, у выбранного игрока, внутри PlayerGui. Не редактируйте похожую панель наугад только потому, что у неё знакомое название. Во время проверки убедитесь, что меняете именно экземпляр выбранного клиента. После остановки теста снова сверяйте исходную иерархию; временные изменения игрового состояния не должны незаметно стать новыми условиями упражнения.
Подготовьте три независимых варианта #
Создайте отдельный учебный проект с обычным появлением персонажа. Под StarterGui разместите ScreenGui с уникальным именем RespawnA и задайте ResetOnSpawn=true. Рядом создайте RespawnB с ResetOnSpawn=false. Затем добавьте в StarterGui папку RespawnFolder и поместите в неё третий ScreenGui, RespawnC, тоже с ResetOnSpawn=false. Имена и схема размещения — оригинальные обозначения упражнения; они нужны для точного сравнения.
В каждом ScreenGui создайте простой TextLabel с именем RouteLabel и исходной подписью «Маршрут не выбран». Разместите три подписи в разных областях экрана, чтобы они не перекрывались. Не добавляйте магазин, сохранения, загрузку ресурсов и сложные обработчики. Сначала изучается только жизненный цикл контейнеров. Запишите полный путь и значение свойства для каждого варианта до запуска, чтобы последующая таблица описывала реальные условия, а не догадки.
Открыть изображение крупнее ↗Прочитайте условия ResetOnSpawn полностью #
В таблице официального руководства ResetOnSpawn=true соответствует сбросу. Для сохранения нужен вариант false и прямое размещение ScreenGui под StarterGui. Косвенный потомок, например ScreenGui внутри Folder в StarterGui, также сбрасывается. Поэтому одной проверки значения false недостаточно: расположение контейнера — часть условия. Это объясняет, почему перенос меню в папку способен изменить ожидаемое поведение, даже если само свойство осталось прежним.
Для наших обозначений ожидаемая по документации схема такая: A сбрасывается, B сохраняется, C сбрасывается. Сначала внесите её в колонку «ожидается», не в колонку «наблюдал». Затем проведите собственную проверку и заполните вторую колонку. Если результат отличается, сохраните обе записи и перепроверьте путь, свойство и работающий экземпляр. Не исправляйте таблицу задним числом так, будто изначально был проверен другой вариант.
| Размещение | Ожидание |
|---|---|
| A: напрямую, true | Сброс контейнера |
| B: напрямую, false | Сохранение контейнера |
| C: внутри Folder, false | Сброс контейнера |
Измените состояние именно игровой копии #
Запустите учебный проект и дождитесь появления персонажа и доступных подписей. Найдите три контейнера в PlayerGui выбранного клиента, используя уникальные имена. Для каждого RouteLabel измените Text на «Выбран северный маршрут» в работающем экземпляре. Убедитесь, что новая подпись действительно появилась на нужной панели. Не меняйте одновременно исходный текст в StarterGui: иначе новая копия сможет выглядеть как сохранённая старая.
Запишите исходную подпись, изменённую подпись и способ изменения. Если нужный объект не найден или текст не изменился на экране, сначала разберите этот шаг. Отсутствие подтверждённого исходного состояния делает последующее сравнение неоднозначным. Упражнению достаточно одного ясного маркера. Набор скрытых настроек и несколько одновременно открытых меню добавляют причины, которые сложно отличить от пересоздания ScreenGui.
Возродите персонажа и сравните результат #
Используйте доступную в тесте команду возрождения персонажа и дождитесь возвращения управляемого персонажа и интерфейса. Затем отдельно прочитайте подписи A, B и C. Для каждого варианта запишите, осталась ли изменённая надпись, вернулась ли исходная и видна ли панель вообще. Важен результат после возрождения, а не только краткое исчезновение интерфейса во время перехода. Не считайте экран ожидания окончательным состоянием.
Повторите сравнение ещё один раз, предварительно снова задав понятную изменённую подпись в текущих экземплярах. Если первый и второй результаты расходятся, не объявляйте одну попытку универсальным правилом. Сохраните контекст: какие объекты присутствовали, где задавалось значение и какие дополнительные скрипты работали. Здесь предлагается последовательность проверки; фактические подписи и длительность появления следует записать из собственного запуска, а не переписать из ожидаемой таблицы.
Открыть изображение крупнее ↗Не путайте Enabled с пересозданием #
Enabled управляет видимостью и активностью экранного контейнера. В официальном руководстве отключённый контейнер не отрисовывает содержимое и не обрабатывает ввод. Это другой вопрос, чем удаление и создание копии при возрождении. Если подпись недоступна, проверьте Enabled у текущего ScreenGui. Затем ищите другие причины видимости: расположение дочернего элемента, перекрывающую панель или собственную логику показа.
Добавьте в журнал отдельную колонку Enabled, не заменяя ею колонку «текст сохранился». Скрытая панель может продолжать содержать нужную подпись; видимая новая панель может содержать исходную. Одинаковое имя контейнера тоже не доказывает, что это тот же экземпляр. Для строгого сравнения ссылок потребуется отдельный инструментальный тест. Наш текстовый маркер проверяет наблюдаемое состояние панели и не выдаётся за полное доказательство идентичности объектов.
Проверьте зависимость от текущего персонажа #
Сохранённое меню не означает, что всё связанное с ним автоматически стало актуальным. Например, собственный код панели может хранить ссылку на персонажа, существовавшего до возрождения. Разделите требования: сохранить выбранную вкладку и обновить сведения о новом персонаже. Это разные задачи разработки. Сначала определите, какие данные относятся к пользовательскому выбору, а какие должны следовать за текущим игровым объектом.
Для учебной панели достаточно заранее составить список зависимостей: выбранный маршрут, подпись здоровья, ссылка на Character и подключённые события. Только первая из этих задач непосредственно относится к нашему текстовому маркеру. Остальные нужно проверять отдельно в реальной реализации. Не обещайте исправление старых ссылок одной настройкой ResetOnSpawn=false. При новом подключении событий также нужен понятный владелец и очистка прежней подписки, чтобы исправление панели не добавляло повторные реакции.
Отличите сохранённую панель от сохранённого прогресса #
Наблюдение после возрождения относится к состоянию интерфейса внутри текущего запуска. Оно не подтверждает сохранение маршрута после выхода из игры, входа с другого устройства или смены сервера. Для этих требований нужны собственные данные и проверка механизма сохранения. Не называйте ResetOnSpawn системой сохранений. В нашем упражнении изменение текста — маркер состояния меню, а не запись пользовательского достижения в хранилище.
Если в проекте отключено CharacterAutoLoads, руководство связывает первоначальное копирование StarterGui с вызовом LoadCharacterAsync. Такой проект отличается от выбранного простого упражнения. Сначала укажите этот режим в журнале, затем проверьте момент первого появления интерфейса. Не смешивайте отсутствие первоначальной копии с исчезновением после второго появления. Для первого знакомства используйте обычный старт, а дополнительные режимы добавляйте как отдельные случаи с собственным ожидаемым результатом.
Завершите проверку понятной таблицей #
Сохраните для A, B и C путь, ResetOnSpawn, ожидаемое поведение, наблюдаемый текст после каждой попытки и Enabled. Рядом запишите, что проверка не охватывает сохранения, все события и ссылки на новый Character. Это позволяет другому разработчику воспроизвести ситуацию и понять границу вывода. Если вы тестировали только прямой вариант B, не описывайте его результат как проведённую проверку всех трёх вариантов.
После сравнения выберите жизненный цикл под задачу своего меню. Для одноразового обучения, настроек и сведений персонажа могут понадобиться разные правила состояния; сначала сформулируйте желаемое поведение, затем настройте контейнер и код. Оригинальное упражнение не меняет опубликованные игры и не использует чужие снимки. Проверяйте текущие условия в официальных источниках и добавляйте в итог только наблюдения, которые действительно получили в своей реализации.
| Поле | Что записать |
|---|---|
| Путь | Полный путь |
| ResetOnSpawn | Фактическое значение |
| Текст после respawn | Наблюдение, не ожидание |
| Enabled | Отдельно от сохранения текста |
Первоисточники
Roblox Creator Hub — On-screen UI containersRoblox Creator Hub — LayerCollector
