HardyNLee

> 考虑一种情况，可能 onLoad 触发时，由于快进或者某种原因，立绘已经退出，或者此时动画由于用户交互，应当被推到“终态”了。再加上演出管理系统会自动在指定的时间调用 stopFunction 来使演出进入终态，这里的处理可能会导致动画和立绘效果混乱。 在最新的提交中, 加了一个简单的 `ignoreOnLoaded` 布尔值来防止这种情况, 现在在未加载时, 退场, setTransform 和 setAnimation 均能阻止 onLoaded 执行

@MakinoharaShoko 已调整大部分界面，目前已适配1440*1440至同高更宽的分辨率，分辨率宽于2560将限制部分界面宽度 关于做限制，有一点与您不同的看法 - 很难权衡应当做多少限制，无法预测创作者更喜欢什么样的分辨率，我记得既然能暴露出来，就不用作太多隐式的限制，以免给创作者造成困扰 - 比起限制，我觉得更应当在文档或者WebGAL Terre中明显提示创作者，让创作者自行承担改分辨率的后果 > 推荐分辨率为2560*1440，修改为其他分辨率会影响UI布局和立绘定位，建议在项目一开始就设定好画布分辨率，并测试界面布局是否合适 - 修改界面的工程过于庞大，我认为应当在单独提一个PR以处理，此PR只专注于暴露画布分辨率的参数 界面 1 : 11440 * 1440 21 : 93360* 1440 主界面 游戏对话底部按钮可滚动快速读存档弹窗可自适应预览图 回想 存档 / 读档顶部页数可水平滚动单页存档可垂直滚动预览图自适应大小 选项可垂直滚动按钮自适应排布 鉴赏模式顶部页数可水平滚动可垂直滚动自适应CG图比例音乐列表展开后可垂直滚动

> setRootSize 函数放在 PixiStage 这个类里面，虽然实现上是没问题的，但是由于其作用范围实际上不是 PixiStage，而是外部 UI，放在这个类里可能有些奇怪。 其实我也不太明白应该放哪，只是需要找个能拿到document的地方，您可以安排一下

此 PR 的实现已过时, 预计将由 #766 或者其他 PR 以另一种方式实现

> 这个实际上有更加优雅的实现方式，用全局状态管理（Terre 使用了 zustand），记录游戏配置的宽高比，然后可以自动根据宽度算出来高度。 这里实际上是我有意为之，因为我认为不应该锁预览窗口宽高比，此修改是为了让用户更自由地调整预览窗口大小 > 另外，我提议用一个单独的配置项来设置是否启用分辨率调整。当这个配置项启用后，再展开调整分辨率的选项。并且，设置是否启用分辨率调整的配置项，使用类似于下图的方法，警告创作者功能的限制和可能引发的问题。 关于这点，其实我觉得加个开关有点太绕了，可否在旁边加一个恢复到默认值的按钮，外加醒目提示，这样更方便一点

> 这个实际上有更加优雅的实现方式，用全局状态管理（Terre 使用了 zustand），记录游戏配置的宽高比，然后可以自动根据宽度算出来高度。 > 关于这点，其实我觉得加个开关有点太绕了，可否在旁边加一个恢复到默认值的按钮，外加醒目提示，这样更方便一点 已修改 

由于 https://github.com/OpenWebGAL/WebGAL/pull/687 已被关闭, 与其强相关的此 PR 也一并被关闭

已复现, 目前临时的解决方案是, 您为第三行里的 `"duration":1000` 更改为 `"duration":0` , 然后刷新游戏

> 在Live2D Cubism 3及以上版本的部分模型中，motion（动作）和expression（表情）在导出的模型中不再区分，可以将表情和动作统一作为动效进行混合处理。以Project Sekai的模型为例，其表情文件同样以motion3.json格式存储，运行时采用先应用动效、再叠加表情的渲染顺序。 > 而WebGAL采用的解析方式无法识别作为动效储存的表情，导致在设置时，“Live2D表情”只能留空（如图） 1. 其实 model 3 也是有表情的，至少在 API 里确实存在（Expressions 对象），应该是 PJSK 的模型采用了“表情也用动作”的方案。所以现行的编辑器没有什么问题。 > 因此，若想要实现类似Project Sekai的live2d渲染，在目前的WebGAL版本中必须将Live2D分为两步，第一步定义动作，第二步叠加表情。 > 然而这引出了新的问题：如果按照上图所示开启“连续执行”，则后一步的表情将会覆盖前一步的动作，导致动作被重置，无法实现叠加。 2. 这个问题的根本在于，目前 WebGAL 使用的这个 Live2D 库不支持平行播放多个动作，此外还有 WebGAL 的数据驱动的逻辑。...