[讨论]关于等待的精度问题

麦德三世

另外red_wolf得出等待0.00秒就是等待0.125秒这种结论完全是出于他把启动时间忽略了~~

其实一个Timer启动开始到启动完毕的时间耗费正好是0.125秒~~TriggerSleepAction启动到启动完毕也正好0.125秒~~如果在Timer的启动动作后面直接加一个Debug已用时间的话它仍显示为0.125秒~~虽然中间没有任何等待~~

另外~~如果不考虑等待其他进程的情况~~Wait用的TriggerSleepAction的实际等待精确性其实比Timer高~~因为它计算的是真实流逝时间~~而Timer用的是游戏流逝时间~~试着创造一个瞬间狂卡的情形就能看出这一点了~~无论实际卡了多少秒~~Timer都显示为一个极小值~~

在宏观上Wait比Timer更不精确的原因是操作系统的并行处理造成的问题~~因为它不但要等待一个真实时间~~还得等待其他进程~~

麦德三世

引用第20楼everguo于2007-02-01 11:49发表的:
那   "比如从技能伤害事件等待到BUFF出现"   这个怎么搞

我做了一个连锁击晕,是等待目标单位出现BUFF后再创建辅助单位      如果用wait来做   那怎么做啊

我的演示中出现的Buff判断还少么？~~像风暴之锤这种技能只要目标受到伤害之间之后等待0.00秒~~再判断Buff之后立即删除Buff即可~~这样就知道单位是否被风暴之锤击中~~

麦德三世

和Timer一样~~
TriggerSleepAction也需要占用0.125秒的启动时间~~

Wait gametime由于需要多次启动TriggerSleepAction所以才会出现额外的多次0.125秒~~但是如果Wait0秒就不需要多次启动TriggerSleepAction~~所以活用wait0.00是会有不错效果的~~

<font c

呃...多次启动TriggereSleepAction的素wait gametime吧...

麦德三世

哦~~其实问题就在这里~~

看楼主引用的那个函数~~显然是wait gametime~~我还以为新版的wait改了所引用的bj函数呢~~

我说太多~把两个扯一块了~~嗯嗯~~改下~~应该wait gametime才是多次启动TriggerSleepAction的嗯嗯~~

麦德三世

wait0.00=TriggerSleepAction(0)~~启动需要花0.125左右的秒时间（但由于操作系统的并行处理~这个启动时间是不确定的~~）~~

而wait gametime0.00则其实是一个空的函数~~根本不进行等待~~可以说几乎不占用时间~~

麦德三世

不过如今的风暴之锤已经是在伤害时直接就有buff了~~所以已经不用等待了~~

老早时候经常用~~

另外一些特殊技能如震荡波上还有用处~~

kook

我想知道timer的启动时间0.125是如测出来的？是不是TimerStart就算在0.01秒循环时在第一次启动时要加上额外的0.125秒？

麦德三世

编辑下~~

看来不是如此~~


我发现0.125的启动时间是以一个Timer的采用极大的存活时间为前提的~~貌似采用小数字就没有~~

Hmmm看来这东西比我想象的还奇怪~~待我看看他们的分界线~~

麦德三世

似乎Timer设置的存活时间越长~~启动时间就越长~~

存活时间设为最小值0.00秒的时候是在十万分之一左右~~当然这个时候用Timer来给自己记数已经不做不得数了~~

然后设得越大~~启动时间就越长~~把存活时间设为最大的话就是0.125秒~~

kook

原来如此～本来是想计量下Timer（0.000）的精度，但恐怕用timer本身作量度已经不行了吧？
[jass]function timer_count takes nothing returns nothing
set udg_Time_C=udg_Time_C+1
if udg_Time_C+1>100 then
call PauseTimer(GetExpiredTimer())
call msg("Timer(0.000) "+R2S(TimerGetElapsed(udg_T_Timer[1])-udg_Timer_Time))
set udg_Timer_Time=TimerGetElapsed(udg_T_Timer[1])
set udg_Time_C=0
endif
endfunction
function Trig_debugTimer_Actions takes nothing returns nothing
call TimerStart(udg_T_Timer[1],20,false,null)
call TriggerSleepAction(0)
call msg("TriggerSleep(0) "+R2S(TimerGetElapsed(udg_T_Timer[1])-udg_Timer_Time))
set udg_Timer_Time=TimerGetElapsed(udg_T_Timer[1])
call TimerStart(udg_T_Timer[2],0.000,true,function timer_count)
endfunction[/jass]

Red_Wolf

楼上可以拿块表来测......

不知道麦德的timer启动时间是哪里冒出来的
对于wai的精准度，最简单的例子：wait0秒删除buff，一样会看到buff显现；而使用timer就不会有这样的事情
而且wait使用的是实际时间，在玩家掉线或是游戏卡机的时候甚至会出现数十秒的误差

So时间长的如英雄复活需要考虑玩家掉线等情况；短的如各种技能制作又精度不够；注定了wait的鸡肋作用，而像PolledWait这种不断切换进程的做法就更不值一提了

麦德三世

Wait的精确度地球人都知道不准~~但是不准有不准的用处~~实际时间也有实际时间的用处~~我们说Timer用来给buff计时比较好~~但是wait也有自己的特性可以利用~~当几个触发一起运作时~~等待0.00秒能确保所有的触发都运行完毕~~我们何必拿它做英雄复活的计时？~~

至于察看Timer的启动时间也是很容易的~~启动一个Timer~~把它的周期设为最大（10000000）~~然后在紧跟的下一句动作里Debug它的逝去时间就行~~

如果周期设为0~~它的启动时间将非常短~~直接用Debug时后面几位会被截断~~直接显示0.00~~可以把这个值乘以一百万后再显示~~

有一点特别的地方是~~一个一次性Timer运作结束后~~它的逝去时间将始终显示为它的周期~~所以如果有这样2个触发~~

一个是启动一个周期为0.00的一次性Timer~~然后紧跟一个Debug逝去时间~~另一个触发器以该Timer到期作为事件~~然后也Debug它的逝去时间~~

结果将是第一个触发的Debug先显示~~后一个触发的Debug后显示~~而且输出的结果是前一个值比后一个大~~我说这点并非是为了指出Timer的精度有问题~~而是作为一个事实来陈述~~

hackwaly

引用第33楼麦德三世于2007-02-01 15:23发表的:
似乎Timer设置的存活时间越长~~启动时间就越长~~

存活时间设为最小值0.00秒的时候是在十万分之一左右~~当然这个时候用Timer来给自己记数已经不做不得数了~~

然后设得越大~~启动时间就越长~~把存活时间设为最大的话就是0.125秒~~

经过我的测试，麦德的结论也不完全正确
测试T
放大100W倍
[trigger]
瀵规垬鍒濆?鍖?
    浜嬩欢
        鐜╁? - 鐜╁? 1  (绾㈣壊) 褰撹緭鍏ヤ互涓嬪唴瀹圭殑鑱婂ぉ淇℃伅 <绌哄瓧绗︿覆>, 鍖归厤鏂瑰紡涓?A瀛愪覆
    鐜??
    鍔ㄤ綔
        Custom script:   local real r1 = S2R(GetEventPlayerChatString())
        Custom script:   local real r2 = 0
        Custom script:   local timer t = CreateTimer()
        Custom script:   call TimerStart(t,r1,false,null)
        Custom script:   call PauseTimer(t)
        Custom script:   set r2 = TimerGetElapsed(t)
        Custom script:   call BJDebugMsg(R2S(r1)+"<----->"+R2S(r2*1000000))
        Custom script:   call DestroyTimer(t)

[/trigger]
测试结果
注意结果中对0的测试，返回值是负数，不知道是什么道理？难道素欺骗
而且到后来的测试结果居然比实际时间还大得多，估计是测试值大得过火的缘故
经过测试最大存活时间1000000对应0.125或0.0625
        

麦德三世

显然Timer在pause后取逝去时间会得出一个欺骗性的修正值~~这点和等它们到期后再取逝去时间是一样道理~~所以我是不pause的~~

hackwaly

恩，应该是酱紫的