rfvtgbzxc 发表于 2023-1-20 00:44
这个问题有一个比较简单的解决方式，还有更系统性的，真正异步的解决方案。
简单的解决方案就是，你的脚本 ...

这个牛逼啊.....! 学到了. 谢谢你了

改成这样的话,我想都可以直接在html标签中添加一个加载框,覆盖在游戏渲染之上, 就想浏览网页一样, 发起某个请求, 会有一个用户反馈. 当然, 网页的处理办法就简单的多了.
等待框避免用户体验差, 会觉得游戏卡了.
后面试试!

这个问题有一个比较简单的解决方式，还有更系统性的，真正异步的解决方案。
简单的解决方案就是，你的脚本添加一行：

1. Graphics.stopGameLoop()

复制代码

此时游戏被完全冻结。
等待异步函数返回，再使用

1. Graphics.startGameLoop()

复制代码

恢复游戏运行。
具体到你的事件，其形如

1. 
   
2. Graphics.stopGameLoop();
   
3. $http.init(1).then(result=>{
   
4. // 回应promise
   
5. // ...
   
6. 
   
7. // 恢复游戏运行
   
8. Graphics.startGameLoop()
   
9. });

复制代码

考虑到异步过程可能报错的问题，可以稍微优化逻辑链：

1. 
   
2. Graphics.stopGameLoop();
   
3. $http.init(1).then(result=>{
   
4.   // promise成功
   
5.   // ....
   
6. }).catch(err=>{
   
7.   // promise失败
   
8.   // ...
   
9. }).finally(()=>{
   
10.   // 恢复游戏运行
    
11.   Graphics.startGameLoop();
    
12. });
    

复制代码

最后需要在脚本指令后面加一条指令：等待1帧。因为本次逻辑帧中的事件的执行尚未告一段落，需要执行一次这种会触发事件暂停的指令来暂停事件的执行。

如果需要在回应到达前，游戏正常运行，回应到达后，择机跳回刚刚的事件，则较为麻烦。
这是因为非并行事件共用一个事件解释器，没有保存进度的功能，因此几乎没有任何方法可以不通过修改源码，让一个事件在请求完成后继续原进度执行。
每个并行事件有单独的解释器，每帧update一次，如果是并行事件，可能可以在微调源码的情况下比较简单的做到从一个“中断”中返回。待研究。

小秋橙 发表于 2023-1-18 12:21
你也许会注意到有很多事件指令对应的commandXxx函数都以if ($gameMessage.isBusy()) { return false; }开头 ...

谢谢您的回复, 我去试试

你也许会注意到有很多事件指令对应的commandXxx函数都以if ($gameMessage.isBusy()) { return false; }开头、以this.setWaitMode("xxx");结尾。
我猜想这个结尾的作用是“令具有上述开头的下一条指令保持阻塞，直到当前指令的异步回调解除了该waitMode再继续执行”，不妨试试看？