我感觉这么做就是为了优化游戏的运行吧。
这个引擎原本方向就是做简单的游戏吧。

好家伙翻译到第一个次我就懂了问题的答案(小白 看不懂7楼
每次运行后需要等待1帧才能运行下一次
要修复这个bug需要改代码
爷不会代码
爷加个循环
循环一次不用等待1帧
所以就不会吞按键了XD

等待帧是个好东西，其实事件也可以等待帧（选择“等待”选项）
如果我记得没错的话，渐变画面需要等待相应的帧数，以及运行脚本后至少要等待1帧
如果是纯事件标题的话就可以用等待帧微调手感
一般的情况下我基本上是使用“事件陷阱”来保证选项成功触发
简单的说，和原版一样，使用变量来控制你的选项，然后按回车后根据变量触发打开的事件，应该是这样的。
事件菜单可以做到很多东西，例如LOGO和开头CG之类的。
顺便，还有一个重要的事。
第一个选项下的“移动图片”后面还要有个“1帧”对吧。
你那三个1帧需要3帧来完成这个动作
所以后面一定要至少等待3帧来保证图片正常的显示完成。
“脚本不会考虑执行图片处理的等待帧”
是这里出了问题
移动图片，更改色调等图片操作，都需要等待帧。
选择项中间也要必须插1帧，这样的话才能正确的反映输入情况，因为循环执行起来似乎整个游戏都停止工作了（？）
“有的时候跑得太快也不是啥好事”
所以写脚本的时候也会加入@wait_count或者是Graphics.sleep来控制脚本速度

今天才发现！！学到了！

未执行完啊！我明白了——“因为事件没有结束，所以就跳过了多出的一帧”

双叶荆棘 发表于 2018-6-1 21:24
【作业】多加了wait，还有其他事件

其实这里面的原理……是加的脚本一定会控制时间什么的

【作业】多加了wait，还有其他事件

RM确实有很多操作是直接设置体验dio差，但是中间加个等待一帧就手感贼6了，大概是因为等待一帧从某种角度避免了6楼说的毛病？

Mayaru 发表于 2018-4-11 05:20
（哇！瞧我发现了什么！一个野生的九姐姐教程！青蛙味嘎嘣脆，蛋白质是触手的五倍x）
感谢教程~大概理解了 ...

for也是可以的，用法是 for [variable] in [range]，比如

RUBY 代码复制

for i in 1 .. 5
  p i
end

for i in 1 .. 5


  p i


end

就能输出1、2、3、4、5。其中 1 .. 5 表示一个range。

上面的@index表示的是“当前执行事件的过程中正执行到的序号”。@list是事件列表，所以@list[@index]就是从@list中取出当前执行的那一条事件了。while @list[@index]，只要当@index不超出@list的范围就能一直循环下去。它的初始值是@list的第一条，应该就是0了。