System Key Timers 2

[Vestras]

Question: Vexorian told me that if I do something like:

call KT_Add(function myFunc, myData, 0.06) <-- 54 seconds elapsed in game
call KT_Add(function myOtherFunc, myOtherData, 0.06) <-- 56 seconds elasped in game

Then when the first one expired, at 60 seconds elapsed, it would run the other one too because it has the same period and therefore not being very multi instanceable. Is that true?

 

[Jesus4Lyf]

>Is that true?
Thanks for asking. The answer is no, if I understood you right.

But let me get this straight...
>call KT_Add(function myFunc, myData, 0.06) <-- 54 seconds elapsed in game
>call KT_Add(function myOtherFunc, myOtherData, 0.06) <-- 56 seconds elasped in game
>Then when the first one expired, at 60 seconds elapsed

The first one will expire at 54.06, not 60...

If you mean 6.0 seconds instead of 0.06, the answer is still no. They will fire 2 seconds apart as they should.

If you did indeed mean 0.06 and you meant when the game finally hits 60 seconds, then yes they will fire at the same time, but that shouldn't effect multi instanceability.

Feel free to ask further questions.

 

[Vestras]

> Jesus4Lyf

Ok, thanks. And yes, I meant 6 xD

 

[Jesus4Lyf]

The released I've intended to do for a while but didn't get around to. (Guess what! I'm on HOLIDAYS now! )

Version 1.7.0.

• Optimised high periods a bit.
• Removed the background timer.
• Removed the 0.01 inaccuracy on high periods.

 

[Troll-Brain]

You have removed the cons which made me prefer TimerUtils for long periods and accurate not periodic timers.
Just to be sure, we can use it for a Timer(0), right ?

But you should display a message in debug mode if TAZO_INSTANCEMAX is reached.
Also what about comment better the constants ?
Or do you consider you need to look all the code to know what you are doing if you edit them ?
At least the names are not obvious.

 

[Jesus4Lyf]

Hey, thanks for the response.

>removed the cons which made me prefer TimerUtils for long periods
Cool.

>Just to be sure, we can use it for a Timer(0), right ?
Yep.

>But you should display a message in debug mode if TAZO_INSTANCEMAX is reached.
Yes I should. I'll stack on some debug messages next version, probably. Or just get rid of the need for them.

>Also what about comment better the constants ?
Good point. Done (1.7.1).

 

[kingkingyyk3]

I found nasty thing. period * 800. Then the periods need to multipliable by 8 and it must an integer.

 

[Troll-Brain]

Yes I should. I'll stack on some debug messages next version, probably. Or just get rid of the need for them.

Oh yes i've forgotten this last con, which why i prefer TimerUtils purple favor against TimerUtils red favor.
If you can get rid of the need of them it would be definitely cool.
But i'm just wondering if you can do that without H2I, or let's say GetHandleId

 

[Romek]

So.. What exactly is Tazo?
You mention it a few times, but you don't say what it is.

 

[Jesus4Lyf]

I found nasty thing. period * 800. Then the periods need to multipliable by 8 and it must an integer.

Add logic to your comments. *800 and *8 are not the same. Next time please find the documentation instead. (You are referring to the 0.00125 thing which is clearly stated.)

//    =Cons=
//         - The code passed into KT2 must call KT_GetData exactly once.
//         - Periods must be a multiple of 0.00125 seconds. Not 0.007, for example.

Oh, and that 0.00125 second thing only applies to periods under the threshold. Above its actually fully accurate.

If you can get rid of the need of them it would be definitely cool.
But i'm just wondering if you can do that without H2I, or let's say GetHandleId

Yeah. I can probably do that for ya. It's actually easier because I'm not using H2I. I'll do this when I get some time and its not 2:00 am (coding at 2 am ain't quality ).

So.. What exactly is Tazo?
You mention it a few times, but you don't say what it is.

Spoiler

It's a Tazo!

See?

Ok, fine... Firstly, from the doc.

    //////////
    // TAZO //
    ////////////////////////////////////////////////////////////////////////////
    // KT2 implementation for higher periods (low frequency).

        // Period Threshold is the point at which Key Timers 2 will switch from
        // using the single timer per period mechanism to using TAZO, which is
        // better for higher periods due to the first tick being accurate.

Did you want to know anything more?

 

[Romek]

Good enough.
So how does it work this time? I can't be bothered to look through that nightmare code.
A timer per period? A list? I'm curious.

 

[Troll-Brain]

I didn't take more than 5 min to understand the code, it's not that big or complicated, but the variables and function name are not obvious, i'm agree.

 

[Jesus4Lyf]

Good enough.
So how does it work this time? I can't be bothered to look through that nightmare code.
A timer per period? A list? I'm curious.

Well. The classic stuff (below threshold) works the classic way. The other stuff (Tazo, >= Threshold) works by a trigger per instance with exec count attachment and a timed event. It builds up the exec count triggers over time, then pops one off the stack when it comes time to use one. It uses the classic KT2 stuff to rebuild the triggers over time after the instance is done and the trigger is destroyed. It's slower than TU red, but doesn't matter for high periods anyway (and it's not significantly slower, still all O(1) complexity for adding, removing and ticking instances).

What to do next:...

Spoiler

I can remove the background reconstruction by using a "timer expires" event and having a timer along with each trigger (much like vTimer which Azlier and myself wrote). (Removes Tazo's internal reconstruction period constant.)

I can remove the instance limit by constructing more triggers when a low number is left. (Removes Tazo's max instances constant, but puts the internal construction period back.)

So I can remove one constant. I'll probably do both of the above in the near future. They will allow Tazo to automatically extend itself and remove the max instance constant, which I think is good. Still backwards compatible to the first version of KT2. :thup:

 

[Jesus4Lyf]

As said, done. No longer a maximum number of instances for TAZO, no longer reconstructs triggers.

I made a precache constant for TAZO, which is kind of nice. You can actually set it to 0 and it all still runs fine. The construction period is only used when approaching the PRECACHE limit (to slowly start precaching more in the background). If you happen to suddenly go over the precached limit, KT2 won't break, it'll just suddenly prepare a new instance for you, which might spike slightly (processing time varies with number of instances already in existance). The idea is that this doesn't happen (it's just a failsafe), so if you're particularly concerned about it, you bump up the precache limit.

... In my maps, I'd probably put the precache on around 32. But that's me.

So, yeah. Happy 1.7.2.

Hopefully the last release for a little while. Yet again.

So KT2 is now limitless on higher periods (>= 0.3), exact for them, still hasn't changed interface and still won't break over the return bug being removed.

 

[Aizen]

Awesome system. I consider it better than TimerUtils because of the backwards compatibility.

 

[lep]

>Awesome system. I consider it better than TimerUtils because of the backwards compatibility.

lol, dumbest reason ever. its not like TimerUtils isnt already compatible...

 

[cleeezzz]

>lol, dumbest reason ever. its not like TimerUtils isnt already compatible...

the updated timerutils would not work for 1.23 and the old timerutils wouldn't work for 1.24 so whys that a dumb reason?

its completely valid

 

[Summoned]

Trying the system out and the timer's working, but I'm having trouble getting it to stop for some reason. First time working with structs, too.

Basically, the problem is that even after the sliding stops, everything under the "else" statement keeps running.

function WW_Slide_Effect takes nothing returns boolean
    local projectile ww = KT_GetData()
    local real speed = (GetUnitMoveSpeed(ww.slider) * WW_SPEEDMULT) / 20
    local group effectgroup
    local unit effectunit
    local location castpoint
    local location movepoint

    if (ww.N <= ww.distance) and (GetUnitState(ww.slider, UNIT_STATE_LIFE) > 0) then
        //sliding stuff
        return false
    else        
        call PauseUnit(ww.slider, false)               
        call SetUnitPathing(ww.slider, true)
        call SetUnitAnimation(ww.slider, "stand")
        call RemoveLocation(movepoint)
        call RemoveLocation(castpoint)
        call ww.destroy()
        return true
    endif
endfunction

function WW_Point_Slide takes unit slider, real direction, real distance, real damage returns nothing
    local projectile ww = projectile.create()

    call PauseUnit(slider, true)
    call SetUnitPathing(slider, false)
    call SetUnitAnimation(slider, "Attack Walk Stand Spin")
    
    set ww.slider = slider
    set ww.angle = direction
    set ww.damage = damage
    set ww.distance = distance
    set ww.N = 0
    set ww.O = 0

    call KT_Add(function WW_Slide_Effect, ww, 0.05)
endfunction

 

[Jesus4Lyf]

It is hard to know the exact cause without more code.

Personally I would change the structure a little:

    if (ww.N <= ww.distance) and (GetUnitState(ww.slider, UNIT_STATE_LIFE) > 0) then
        //sliding stuff
        return false
    else        
        call PauseUnit(ww.slider, false)               
        call SetUnitPathing(ww.slider, true)
        call SetUnitAnimation(ww.slider, "stand")
        call RemoveLocation(movepoint)
        call RemoveLocation(castpoint)
        call ww.destroy()
        return true
    endif

-->

    if not ((ww.N <= ww.distance) and (GetUnitState(ww.slider, UNIT_STATE_LIFE) > 0)) then
        call PauseUnit(ww.slider, false)               
        call SetUnitPathing(ww.slider, true)
        call SetUnitAnimation(ww.slider, "stand")
        call RemoveLocation(movepoint)
        call RemoveLocation(castpoint)
        call ww.destroy()
        return true
    endif
    //sliding stuff
    return false

My best guess would be that you have a thread termination issue. Perhaps try using debug messages to figure out what's going on. From what you've shown me there, you're removing locations "movepoint" and "castpoint" which are local variables, but don't actually hold values. That will cause the thread to terminate (without returning a value, but probably translated as "false").

 

[Summoned]

From what you've shown me there, you're removing locations "movepoint" and "castpoint" which are local variables, but don't actually hold values. That will cause the thread to terminate (without returning a value, but probably translated as "false").

Didn't realize it'd spazz out when trying to destroy non-existent variables. Nice to know. Was just trying to cover all bases as far as leaks were concerned.