那么就是教程里有瑕疵了，你看#alias Testidle {#alarm +@time {#if (@idle>0) {#say 运行情况良好;#var idle 0} {#say 机器人已经中断;let it run}};testidle}
他最后的testidle是在#alarmtime {} 之外的
最 ...
貌似是版本问题
这种判定，zmud可能有两种解释
1、#alarm运行，@time后执行指令，加入这个状态后就认为#alarm执行完毕，马上执行testidle，这样就像糖果刚才回复的，会死循环，因为testidle没有延迟，不停重复
2、#alarm运行，@time后执行指令，直到@time之后zmud才认为#alarm执行完毕，然后执行testidle，这样判定的话这个写法就是可行的
安全起见，testidle还是写在{}内吧
我知道的是，在462里，#wa 5000;command;testidle肯定是5s后执行，不过这是废话
但是如果再命令栏里输入path，path中有延时，比如去华山村的是
xiaocun=do 5 n;nw;#wa 1000;do 4 n
而你如果输入xiaocun;hi，回车，其实zmud的执行时do 5 n;nw;hi;#wa 1000;do 4 n
意思是在zmud462的命令行判定中，xiaocun开始进入执行状态后，zmud462就认为xiaocun执行结束，马上执行了hi，后果就是hi被插到了path里，我做慕容时经常beijingb;s;s;w;l，如果用命令栏，s;s;w;l就会插到beijingb里导致行走错误
但是，令人无语的是，如果path;command这种格式放到触发指令里，却是可行的，一直到path整个执行完才会执行command，无语
所以，找这个判定推测，如果是在{}外的话，462会导致死循环，因为testidle是用别名执行而不是用触发器执行，别名执行相当于就是在输入栏里直接输入回车，那么后果就是结果1
不知道推断正确否，没真的试过这个alarm嵌套 搞那么复杂干啥呀，在timer里设一个就好了！ 我也不明白为什么搞这么复杂，在一个长时间运行的机器人中，反复创建临时tr，会增加很大的系统开销，常规性自身调用，也会增加不稳定因素，甚至造成内存混乱。其目的无非是尽量降低发呆的时间。其实发呆本身就是非常规现象，那么遇到了多等几秒也无所谓。
简单的一行 #alarm -10 {hi} 创建一个永久运行的定时器。比ts的好处是程序集成度高，不争抢那唯一的ts。
如果非要自动控制，那么在开始的时候创建，任务结束了#untrigger删除就是了。 可以用time功能防止退出嘛
比如#time 60 5 kiss littlexi 诚三你说的#untr -10的特点只有721才有，如果用的是721，绝对是用#untr -10，一个永久性的定时器肯定比反复的嵌套创建要好
另外timer只有1个，如果在某个更重要更需要稳定的地方已经用了timer，那么防发呆就只能用#alarm了。timer比#alarm简单稳定。
我一直还是主张能简单尽量不要复杂的。
页:
1
[2]