开发 / ROBLOX
Roblox 菜单在重生后重置：检查 ScreenGui 的位置与 ResetOnSpawn
区分 StarterGui 中的模板和 PlayerGui 中的玩家副本，比较 ScreenGui 的三种放置方式。这个分步练习将菜单替换与可见性、进度保存以及当前角色引用分开，帮助定位需要检查的环节。
先描述到底什么消失了 #
“菜单重置了”可能描述不同事件：面板不再可见、文字恢复初始值、选中的标签页关闭，或者旧对象被新对象替换。先确定一种可以重复的情形。例如，打开教学路线面板，修改标签，再让角色重生。分别记录可见性、标签值和按钮是否可用。一个笼统结论不能替代这些观察，也不能直接指出需要调查的是哪一部分。
练习使用虚构面板，初始标签是“尚未选择路线”，修改后显示“已选择北方路线”。这些是独立教学项目的原创标记，不是作者五款游戏的功能说明。本文根据官方条件提出自查流程。我们尚未在 Roblox Studio 中执行这个具体实验，因此不会把文档中的预期结果写成已经测量的实验报告。
分清模板与玩家实例 #
官方指南把 StarterGui 作为准备屏幕界面的位置。角色首次出现时，ScreenGui 与其内容会复制到该玩家的 PlayerGui。区分这两个位置对练习很重要。运行之前设置的标签属于模板；修改运行中的标签，则提供一个可观察的标记，用来检查当前会话的面板状态是否在角色重生之后仍然保留。
测试前记录两条路径：StarterGui 下的原始容器，以及 Players 中所选玩家的 PlayerGui 下找到的副本。不要只因为名字熟悉，就修改某个相似面板。检查期间确认修改的是预定客户端的实例。停止测试后，再核对原始层级。临时运行状态不应悄悄变成下一次比较的新起始条件，否则两次结果可能描述不同设置。
准备三种独立放置方式 #
创建一个使用普通角色生成方式的独立教学项目。在 StarterGui 下直接放置名为 RespawnA 的 ScreenGui，并设置 ResetOnSpawn=true。旁边添加 RespawnB，设置 ResetOnSpawn=false。然后在 StarterGui 内创建名为 RespawnFolder 的 Folder，在其中放置第三个 ScreenGui，命名 RespawnC，同样设置 ResetOnSpawn=false。名称与布局是原创练习标识，目的是让三个比较对象清楚可辨。
在每个 ScreenGui 中创建一个简单 TextLabel，命名为 RouteLabel，初始文字为“尚未选择路线”。把三个标签放在不同屏幕区域，避免相互遮挡。暂时不要加入商店、存档、资源加载或复杂处理器。第一项任务只检查容器生命周期。运行前记录每个容器的完整路径和属性值，让后面的表格描述真实条件，而不是对对象位置的猜测。
打开大图 ↗阅读完整的 ResetOnSpawn 条件 #
官方指南的条件表将 ResetOnSpawn=true 与重置关联起来。要保留容器，需要 false，并且 ScreenGui 直接位于 StarterGui 下。间接后代也会重置，例如位于 StarterGui 下某个 Folder 内的 ScreenGui。因此仅检查 false 不够，容器位置也是条件的一部分。这解释了为什么移动菜单到文件夹后，即使属性没变，预期行为也可能改变。
按本练习标识，文档预期为：A 重置、B 保留、C 重置。先把这些填写到“预期”列，而不是“观察”列。自行完成检查后再填写后者。如果结果不同，保留两份记录，并重新核对路径、属性和运行实例。不要事后修改条件，假装从一开始测试的就是另一种位置。差异可以揭示仍需调查的设置细节。
| 放置方式 | 预期 |
|---|---|
| A：直接，true | 容器重置 |
| B：直接，false | 容器保留 |
| C：在 Folder 内，false | 容器重置 |
修改运行副本的状态 #
启动教学项目，等待角色和可读标签出现。使用唯一名称，在所选客户端的 PlayerGui 中找到三个容器。把每个运行中的 RouteLabel 的 Text 修改为“已选择北方路线”。确认新文字确实出现在正确面板上。不要同时修改 StarterGui 模板文字，否则新副本可能看起来像保留的旧副本，掩盖你试图检查的替换行为。
记录初始标签、修改后标签和修改方式。如果找不到正确对象，或屏幕文字没有变化，先调查这一步。没有确认起始运行状态，后续比较就会有歧义。本练习只需要一个清楚的标记。多个隐藏设置和同时工作的菜单会增加其他原因，使它们难以与 ScreenGui 替换区分，也让重复实验变得不必要地复杂。
让角色重生并比较结果 #
使用测试中可用的角色重生操作，等待可控制的角色和界面恢复。然后分别阅读 A、B、C。记录修改后标签是否保留、初始标签是否回来，以及面板是否仍然可见。需要比较的是重生完成后的状态，而不只是过渡期间短暂消失的界面。等待画面本身还不是你要比较的最终结果，不应提前写成成功或失败。
在当前实例中重新设置明确的修改后标签，再重复一次比较。如果两次结果不同，不要把其中一次提升为通用规则。保存上下文：存在什么对象、在哪里修改值、还有哪些脚本在运行。这里提供的是建议检查顺序。真实标签和出现时间必须来自自己的运行，而不是从预期结果表复制到观察列。
打开大图 ↗不要把 Enabled 当成对象替换 #
Enabled 控制屏幕容器的可见性与活动状态。官方指南说明，禁用的容器不绘制内容，也不处理输入。这与重生时删除并重新克隆是不同问题。标签看不到时，先检查当前 ScreenGui 的 Enabled，然后调查子元素位置、覆盖它的面板或自己的显示隐藏逻辑。不要把每次标签缺失都解释成对象已经替换。
为 Enabled 单独添加记录列，不要用它替代“标签保留”列。隐藏的面板可能仍有修改后的文字；可见的新面板可能具有初始文字。相同容器名称也不能证明是同一个实例。严格比较引用需要独立的仪器化测试。本例文字标记检查可观察的面板状态，不作为对象身份完全相同的证明，更不证明所有内部行为都未变化。
检查对当前角色的依赖 #
菜单保留不代表所有相关信息都会自动更新。例如，面板自己的代码可能仍保存重生前角色的引用。把“保留选中标签页”与“更新新角色信息”分成两个要求，它们是不同开发任务。先识别哪些数据表示用户选择，哪些必须跟随当前游戏对象，而不是继续引用之前的对象。这有助于避免修复状态时引入另一种问题。
为教学面板准备依赖清单：所选路线、生命值标签、Character 引用和已连接事件。只有第一项直接对应我们的文字标记，其余需要在实际实现中另行检查。不要保证 ResetOnSpawn=false 单独就能修复旧引用。新事件连接还需要明确的拥有者，并清理旧连接，避免修复菜单时意外增加重复反应。界面生命周期与订阅生命周期不能互相代替。
区分界面保留和进度保存 #
重生后的观察只涉及当前运行中的界面状态，不能证明退出游戏、换设备或换服务器后，路线选择仍会保留。这些要求需要自己的数据，以及对保存机制的测试。不要把 ResetOnSpawn 称为存档系统。本练习中的文字变化只是菜单状态标记，不是把玩家成就写入持久存储，也不能确认跨会话恢复成功。
如果 CharacterAutoLoads 被禁用，指南把 StarterGui 的首次复制与 LoadCharacterAsync 调用关联起来。这样的项目不同于本例简单设置。先记录这个模式，再检查界面第一次出现的时间。不要把首次副本缺失与后续重生后消失混为一谈。初次比较使用普通生成，其他模式作为独立案例加入，并分别记录自己的预期和观察条件。
用清楚的比较表结束检查 #
为 A、B、C 保存路径、ResetOnSpawn、预期行为、每次尝试后观察到的文字，以及 Enabled。另行注明比较不覆盖存档、所有处理器或新 Character 引用。这样其他开发者能够重复情形，并理解结论的边界。如果只测试了直接放置的 B，就不要把它描述成已经执行了三个案例的检查。表格应忠实反映实际覆盖范围。
比较之后，为自己的菜单选择合适的生命周期。一次性教学、设置菜单和角色信息可能需要不同状态策略。先定义目标行为，再配置容器与代码。原创练习不会改变已发布游戏，也不使用他人的截图。请用官方来源核对最新条件，并只把自己实际实现中真正得到的观察加入最终结果，不用预期或猜测补齐未测试的部分。
| 字段 | 记录内容 |
|---|---|
| 路径 | 完整路径 |
| ResetOnSpawn | 实际值 |
| 重生后的文字 | 观察，不是预期 |
| Enabled | 与文字保留分开 |
原始资料
Roblox Creator Hub — On-screen UI containersRoblox Creator Hub — LayerCollector
