System Timer Ticker

[Cohadar]

It depends really.
But using null data with TT is absolutely possible.

 

[Technomancer]

This is almost an exact copy of my timer system without the interfaces.

 

[emootootoo]

I just downloaded the TT demo map from here and saved it after opening it (w/ newest ver of jasshelper) and it gave this error:

Function passed to Filter or Condition must return a boolean

call TriggerAddCondition(TT__Triggz[TT__Counter] , Condition(userFunc))

edit: redownload+install fixed it

 

[XeNiM666]

hello, Cohadar.

Been using your System for a while and i would like to suggest a command to pause the General Timer.

 

[cr4xzZz]

Merry Christmas (and merry 900 posts to me).

You should update it to 4.0.

 

[Darius34]

It's automatically paused when it's currently not handling anything

Is it? Do you mean how the callback function Handler does nothing when no functions are assigned?

 

[Flare]

Oh my bad Would've sworn that it paused itself when it wasn't running anything

 

[Romek]

Oh my bad Would've sworn that it paused itself when it wasn't running anything

I thought it did too. Just checked now, and it doesn't..

Maybe that could be a suggestion for the next version?
..Or maybe there's some explanation for it. (The extra if will slow the system down slightly, and it's not exactly noticeable if it's running anyway).

 

[Darius34]

Hmm, it does seem like it wouldn't matter much.

Anyway, I saw that 4.0 was out at WC3C before the recent downtime, so it should be posted here as well soon.

 

[Cohadar]

Hmm, it does seem like it wouldn't matter much.

Anyway, I saw that 4.0 was out at WC3C before the recent downtime, so it should be posted here as well soon.

Updated to 4.0.
I am really sorry for not doing this earlier people.
I thought I did it and I just left the scene for some time without noticing it.

hello, Cohadar.
Been using your System for a while and i would like to suggest a command to pause the General Timer.

Somebody already asked that and like I said: testings showed that to be a bad idea.

 

[Tyrande_ma3x]

v4.1? Saw it in your demo map.

 

[Cohadar]

v4.1? Saw it in your demo map.

Experimental version, not tested, not supposed to be released -> ignore it.

 

[emjlr3]

Thought:

the limitation of TT is that you can only have one timer inteval - this is nice for any kind of knockback, periodic movement, projectile etc.

but seriously though, sometimes you need something timing out every .1, or .2 - still being able to use TT for things that expire in under .25 or so would be nice

would it be possible to add the functionality in to allow multipules of the timer interval - obviously this can be done from the users end, with a Modulo of some integer that you increase every interval, and only run your effects when desired - but if this could be done internally (within the system), things would be great

for instance:

TT interval = .04

say I want something to run every .2

function TT_Multiple_Start takes integer data, integer multiple returns nothing

now if I went and did

call TT_Multiple_Start(my struct, 5)

this guy would only be called every .2s, so I didnt have to worry about it at my end

or perhaps you could make it such that

function TT_Multiple_Start takes integer data, real interval returns nothing

I would do

call TT_Multiple_Start(my struct, .2)

now this is fine for multiples of the TT interval, but if the user specifies a time that isnt an exat multiple, you could run an algorithm to determine the closest time possible

I think this would be a great addition to TT!!!

my only concern is whether the added overhead would be worth it

thoughts?

 

[Azlier]

Huh. And I thought

function TT_StartEx takes code userFunc, integer data, real period returns nothing

meant that I could specify a period. Especially with the period parameter.

 

[emjlr3]

that uses a timer/instance however

i was suggesting using the single main TT timer

 

[Cohadar]

that uses a timer/instance however

i was suggesting using the single main TT timer

public function StartBy takes code userFunc, integer data, integer multipl returns nothing
    if (multipl<2) or (multipl>20) then
         call BJDebugMsg("blah blah")
         return
    endif
    // do the magic here
endfunction

Sounds ok?

EDIT:
==============
hmm I dunno, since it depends on TT_PERIOD which is changeable it coul create problems for people that want exactly 0.2
and calculating approximates is something I don't like.

Besides overhead would slow down the main TT timer.

What I could do however is not add a new function but change implementation of TT_StartEx
If you for example give it a timer that is one of: 0.05, 0.10, 0.15, 0.20, 0.25, 0.30, 0.35, 0.40, 0.45, 0.50
it sets all to default 0.05 timer by using multiples
and if it is greater than 0.50 it uses the old behavior

So this way I would have default TT_PERIOD timer, default 0.05 period timer and others would be instance timers.

Sounds sane enough?

EDIT2:
==============
Argh it all sounds somewhat not stable.....
Maybe I should add a new function after all

//=============================================================================
//  Allowed periods: 0.05, 0.10, 0.15, 0.20, 0.25, 0.30, 0.35, 0.40, 0.45, 0.50
//=============================================================================
TT_StartBuff takes code userFunc, integer data, real period returns nothing
    // check if period is ok
    // do the magic
endfunction

I named it StartBuff because that is what most people would use it for, would someone use it for something else?

Dunno... anyone has any better ideas?

EDIT:
After thinking this thoroughly I concluded that small performance benefit in some special cases is not worth of bloathing the system interface.
TT stays the way it is.

 

[emjlr3]

you'd have to check and see if the overhead addition is worth it

 

[Cohadar]

you'd have to check and see if the overhead addition is worth it

Strenght of my systems is a good interface.
Once I set the good function names I can improve on the implementation as much as I like.

ABC for example is version 6.0 and each version had drastic changes in implementation but all that time function names stayed the same so it did not really matter to end users what is under the hood.

So if I ever decide to include the same period optimization in TT it will be implementation modification.

But right now it is not on my priority list so it will simply have to wait.

 

[Doom-Angel]

i was thinking how to make use of TT without having the need for a constant period and i think i have an idea so i thought i should ask you about it first:

my idea to add the ability of making non constant period (well not exacly non) was that i would give the period my lowest period needed in my map and add another paramater to the function call for period like in ABCT and the use of this paramater would be used with the Modulo function so each time the Modulo is not equal to 0 it would avoid the use of the action function which was sent.

as far as i thought of it, it seems pretty possible, though i don't know how your system works that well so you can guess why im here.

i hope you understood my explanation of the idea

 

[Tyrande_ma3x]

Doesn't this

public function StartEx takes code userFunc, integer data, real period returns nothing

provide you that "non-constant" period you're talking about?
Or you wanted something like making the timer start with different periods on each run (like first time: 0.75, 2nd time: 1.25, 3rd time: 0.66, etc.)?