- Reaction score
- 91
So... Key Timers fails with custom shields? I think you'd better see what you can do about it.
Although the problem has been misstated again it seems that isn't in the cons and should be. Cheers.But you really should add more details to your first post / comments in the trigger itself...
Especially about the accuracy problems especially with higher periods ....
I can't agree with that. KT1 is easily the best system. KT2 is a nice interface for KT1 and is faster than TU, and TU is brilliant for exactly what I've said in section 5 (which is a specific case).You should also tell people that for most cases TimerUtils (Red,Purple,Blue) are the best system to choose...
I'd say that's "most cases", not the contrary. Especially in writing spells. Obviously this is up for debate.shows that KeyTimers is faster for special cases ..with lots of similar periods
// =Cons=
// - Periods should only be taken to 0.005 of a second, not 0.007 for example.
// - Limit of 20 different periods.
// - Limit of 400 instances of each period.
// - Period can't be above 40.955 seconds.
// - Key Timers only uses one timer per period to keep things efficient,
// especially in attaching data.
I agree with you there. But...Vex was mostly complaining on stuff he should not be because KT2 clearly states:
JASS:// =Cons= // - Periods should only be taken to 0.005 of a second, not 0.007 for example. // - Limit of 20 different periods. // - Limit of 400 instances of each period. // - Period can't be above 40.955 seconds.
You're wrong. In fact, that doesn't even make sense for a multi-instancing timer system.How it works:
KT2 is using attaching method that adds index to timer by applying a small modification to it's period.
For example if you wanted to attach index 71 to 0.05 timer you would create a 0.050071 sec timer.
the 0.000071 modification is too small to be noticed and can be extract back as index with some simple math. (check system code for details)
// =Cons=
// - Periods should only be taken to 0.005 of a second, not 0.007 for example.
// - Period can't be above 40.955 seconds.
// - Cannot have more than 8191 instances at once.
Edit: And just to reassure everyone, unlike what Cohadar said, the exact period you enter is used, taken to an accuracy of 0.005.
Well actually, we really can't...We could debate on this but I don't see the point if new version is coming.
You're wrong. It jammed exactly what the user put in into the period.public function Add takes code func, integer attachment, real period returns nothing
...
if maxp+399==p*400 then
call TimerStart(KeyTimer[p],period,true,function KeyTimerLoop)
endif
endfunction
I assumed you used the same stuff as old methods that did TimerGetTimeout() so yes I was wrong, sorry.You're wrong. It jammed exactly what the user put in into the period.
// - Key Timers only uses one timer per period to keep things efficient,
// especially in attaching and retrieving data.
// - The first procurement of an instance is random between 0.0 seconds and the period
// (Doesn't effect periods less than 0.100 seconds).
private constant real RESOLUTION = 200.0 // must be real not integer
Does your estimation technique consist of using a combination of magic mushrooms, old bones and chicken blood?The speed is within margin of error to version 1.1, but an estimated 0.2% efficiency gain...
I thought I was the only one.I assumed you used the same stuff as old methods that did TimerGetTimeout() so yes I was wrong, sorry.
Thought about it, but if people write spells using KT2, and someone messes with that value in the wrong way, the spells will break. I'd rather make some sort of standard. I like 0.03125 though. I'll consider knocking down the value, but generally intend to leave it hard coded. If people want to screw with it, it's not hard anyway; but I wouldn't want to encourage it for the purpose of shared spells on TheHelper and such.1. Why isn't 200.0 a constant?
I assume by pivot pointer you mean store the previous in the loop...2. Why are you using double-linked lists when single-linked list + pivot pointer would do the job?
Haha... Was wondering when that would come up. Actually, it's already come up in this thread. Actually, there already is half a security function - it uses id/200.0 instead of period. XD3. Why the frak you don't have a security mechanism in Add function?
Hahaha... A reasonable question for someone who hasn't read my documentation . It's the same efficiency test I used to compare timer systems. KT2 version 1.1 scored 31,850 executions per second, and KT2 version 1.3 scored 31,900. But of course, this is within margin of error (which is about 200 the way I do it).4. Does your estimation technique consist of using a combination of magic mushrooms, old bones and chicken blood?
Yeah, agreed about your actual points (but I'm not pushing it to be something it isn't, check the documentation; I recommend TU Red for high frequencies or whatever). However, I use this system for 1 second periods all the time. For AI and camera systems.5. And last and the most important:
Why are you trying to push this sys to be something it is not?
Yep, you lost me there. I can only assume 8's and 0's are good things for unknown reasons. XDTIP: Since all numbers in jass are either hex or decimal it is best to use a resolution in form of (2^n * 5^m) where n>=m
...
set t_id=R2I(GetPeriod*800.0) mod 8000
loop
exitwhen KeyTimer[t_id]==GetExpiredTimer()
set t_id=t_id+1
endloop
...
No.Aww c'mon... Aren't you gonna say that you're impressed with my initiative or something nice? XD
So it is old fashioned bat wings, pig guts and snake eggs combination after all.Hahaha... A reasonable question for someone who hasn't read my documentation . It's the same efficiency test I used to compare timer systems.
TimerUtils is just ABC with bad syntax.I recommend TU Red for high frequencies or whatever).
I have yet to see a wc3 map that suffers more from efficiency issues than from sucking issues.Of course, sadly this comes at a mild efficiency sacrifice... =/
...
set t_id=R2I(GetPeriod*800.0) mod 8000
loop
exitwhen KeyTimer[t_id]==GetExpiredTimer()
set t_id=t_id+1
endloop
...
Aw.
QFT. <_<I have yet to see a wc3 map that suffers more from efficiency issues than from sucking issues.
So you can have periods of over 9,000! (Seconds.)Why the mod?
So you can have periods of over 9,000! (Seconds.)
More to the point, so I don't have to put "Limited to periods of up to 10" in the cons.
Then people could change the resolution to 8000 without breaking the system at all.
Read it carefully. It iterates from there until it finds the correct timer. I'd probably compare on period instead, though.