昏睡有可能被1500阴阳修为干扰，需注意
至于大港的强制控制，我猜大概是addtimer(0 吧

waitforbattleupdate
这个用来控制玩家，“真是绝佳的函数”

还有一点很大的疑问，强行用AI控制玩家ID毕竟是一种严重非法的行为，无法严格控制这个时机，会不会受到电脑配置的影响。不加昏睡，会不会低配时给玩家操控权的间隙就长；加了昏睡，会不会低配电脑没等到AI接管ID就被系统跳过了。

混乱、昏睡我当时试过，效果好像也不太好
addtimer（0,XXXX)不间断循环优先级太低，遇到wait就不动了（当然CALL也一样），不过在没有快捷键干扰的情况下还是可以的
X5除了快捷键干扰，就是AID和AMODEL不一致的问题

这种老物也会被翻出来

AID≠AMODEL这种情况在5Q好像很常见，自动战斗出现的“假连击”就是一例

客户端不知道能不能发gif

昏睡的玩家，套上反震，受到菜刀，会解除昏睡吗

如果昏睡真的有效，可以把它改成“催眠”：不仅仅是失去控制权，还可能被系统控制

timer0自循环的一个问题是一回合里所有的操作只应该是有限次，这个比较麻烦

测试结果好奇怪
我刚才调整了一下
我把WaitUpdate那些全部改到了技能脚本里，原来是在AI脚本里的。现在技能脚本里的加血居然不延迟了。
A 1 B
1代表应该释放吟唱后技能的瑾轩；A表示他前面的ID，B表示他后面一位
写法1、
global.WaitForBattleSEEnd(183)
if nextid==1 and battle.CheckPlayerStat(1,157)==1 then
global.WaitForBattleUpdate()
battle.Skip()
player.RemoveStat(0,1,157)
battle.MagicToNpc(id,25082,1)
end
此情况，A完毕，1被跳过，活动ID显示B，但表观正常，是1做出了施法动作；同时，通过调整仙攻，得出吟唱技能确实是1放出的。行动完以后，B再次执行了他自己的AI。表面看起来整个流程并没有不对。
写法2、skip和update换了下顺序
battle.Skip()
global.WaitForBattleUpdate()
此情况，未发现和写法1有区别，完全相同。
写法3、把update搬到了最后
global.WaitForBattleSEEnd(183)
if nextid==1 and battle.CheckPlayerStat(1,157)==1 then
battle.Skip()
player.RemoveStat(0,1,157)
battle.MagicToNpc(id,25082,1)
global.WaitForBattleUpdate()
end
此情况，A完毕，1被跳过，活动ID显示B，表观也不对了，是B做出的施法动作，根据伤害大小得出吟唱技能是B放出的……但是行动完以后，B还是再次执行了自己的AI。
写法4、把battle.Skip()去掉了
global.WaitForBattleSEEnd(183)
if nextid==1 and battle.CheckPlayerStat(1,157)==1 then
global.WaitForBattleUpdate()
player.RemoveStat(0,1,157)
battle.MagicToNpc(id,25082,1)
end
此情况，居然和写法1结果也相同，也就是说skip变成了无用的语句，但是昨天不行，难道就因为从AI改到skill里来写的原因？？
写法5写法6，去掉global.WaitForBattleUpdate()、以及把skip和update都去掉。
global.WaitForBattleSEEnd(183)
if nextid==1 and battle.CheckPlayerStat(1,157)==1 then
（battle.Skip()）
player.RemoveStat(0,1,157)
battle.MagicToNpc(id,25082,1)
end
这是令我最诧异的结果，这两种也是一样的（所以关键的是update？）
ID1直接被跳过了，B执行它自己的内容，按理说没有update应该就跟他无关了，seend后面再有magicto应该id不变继续活动才对，一时间实在是不能理解。。。

还有一个现象
我发现执行global.WaitForBattleUpdate()的时候，npc备战动作会被复位到第1帧重新开始播放。还没有注意过是必然现象还是有条件现象。

rrun call timer都是技能脚本，不是AI