System Timer Ticker

[Cohadar]

Ffs people check the version numbers of systems you use.

 

[Doom-Angel]

when did you add this one?
didn't know you updated it to have period
anyway good to know and sorry about the out of line question

 

[emjlr3]

what Doom suggested is exactly what i said above - and again - just above I answered Dooms question...wtf indeed

 

[Jesus4Lyf]

Just happened to glance over at this thread to see how TT is going...

Why are people telling Cohadar to make Timer Ticker do exactly what Key Timers 2 does? There would be no point in having the two different systems...

And he's right. The modulo thing would be a pretty nasty interface to use. Specifying the period would be OK but have invisible restrictions to the user.

And that's pretty impressive about ABCT.
Well done.

 

[Azlier]

You don't think it's alright to have multiple systems accomplishing the same task? Look at all the timer attachment systems, the timed effect systems, the damage detection systems... *fans hand across the horizon*

 

[Jesus4Lyf]

There should be a reason, for example, a significant advantage in the different implementation method. In this case, there would not be. The idea is to cut down on the number of redundant systems, isn't it?

This is really a redundant discussion anyway...

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.

Not to mention that that small performance benefit in special cases would cause a performance loss in every other situation.

 

[Cohadar]

Why are people telling Cohadar to make Timer Ticker do exactly what Key Timers 2 does?

I guess for the same reason you are not limiting the KT2 functionality to lower periods.

Some people always try to use hammer on a screw.
(or to screw down a nail...)

 

[emjlr3]

I personally like TT, but for anything that isnt done on my .04 interval (unless I were to run a modulo at my end), I need new timers - I was trying to see if Cohadar could avoid that

a .05 interval would work well - .25, .05 and 1. are good intervals to use, (.05 really being uneeded though with something like .03 or .04) - more often then not if you want to use .66 - .65 will work just as well

call TTI_Start(struct, .5, function Blurg)

would run my guy every .5, in your .05 interval timer

call TTIStart(struct,.76, function Blurg)

shit I either botched my code or really want it to run every .76 - either way, TT figures this out, and rounds it down to .75 anyways, so it runs every .75

I like it

intervals from .1-1. would be ideal (at .05 intervals), anything about 1. isn't worth it

 

[Jesus4Lyf]

I guess for the same reason you are not limiting the KT2 functionality to lower periods.

Some people always try to use hammer on a screw.
(or to screw down a nail...)

Well said.
I think with the lower periods thing I just see it a little differently... It's valid to say they should be restricted, and valid to say they shouldn't (as long as it's documented well). But let's not talk about that again here. XD

emjlr3, I'm very confused as to why you would want to remove TT's nice interface and make it less efficient instead of using KT2 if you really want multi-period, multi-instance, as it is designed to do exactly that from the ground up.

The plus of that suggestion with the modulo, btw, is that it would fire the first procurement at the wrong time. Just in case no one thought of that. It would be... like a real timer system! (LOL)
(Of course, the period may be incorrect, as mentioned. In fact, the likelihood of the period being wrong is based on the modifications made to the period in each individual map. Lol?)

Ahh... It's all starting to sound like nasty hack-jobs... XD

 

[emjlr3]

maybe ill make my own (^^) for my own personal use - even if its not faster its ease of use I am concerned with - as Cohadar said, I've never seen a map suffer more from inefficiency then from shear suckyness

 

[Jesus4Lyf]

Lol, I nearly suggested that as a joke, but was worried you may get the idea in your head and go do it. Turns out I didn't need to.

Hey, that's fine... But I still don't see why not use KT2, which will do exactly what you want it to do, but fast.

Or just use ABCT or something, if you don't care about speed anyway, if you must get the first period expiration firing correctly.

<_<

So many options...

I mean... TT even has ABCT in it now too...

But hey, if it's just for personal use, why not write your own. XD

 

[Cohadar]

But hey, if it's just for personal use, why not write your own. XD

Because there are more wc3 timer systems than wc3 good maps.

So my suggestion is: make a good map, and than if by some chance it suffers from non optimal timer system I will go to the Shiboku mountain to the great master Wu and ask him to train me for 10 more years after which time I will be able to make ultimate timer system that I will inserted into your map after which since I will have no more reason to live I will commit ritual suicide by meditating myself into the state of death.

 

[emjlr3]

meditating myself into the state of death

this I gotta see

 

[Builder Bob]

I'm just using the simplest form of TT without all the extras you recently added, but with a slight modification.

In case you're interested.

public function Start takes trigger whichTrigger, integer data returns nothing

private function HF_Handler takes nothing returns nothing
    local integer i = HF_Counter
    loop
        exitwhen i<=0
        set Data = HF_Dataz<i>
        if TriggerEvaluate(HF_Triggz<i>) then
            set HF_Triggz<i> = HF_Triggz[HF_Counter]
            set HF_Dataz<i> = HF_Dataz[HF_Counter]
            set HF_Counter = HF_Counter - 1
        endif
        set i = i - 1
    endloop
endfunction</i></i></i></i>

I've left out the obvious. It might not be as user friendly as you want, but it eliminates the need for swap and ClearConditions(). The user is required to create a trigger with no events, and add a condition to it. After that, the use is the same.

 

[Cohadar]

That is rather silly because the performance benefit is 0.5%
ClearConditions is almost as fast as I2H.

PS: you could hire Jesus4Lyf to do you a benchmark

 

[Builder Bob]

That is rather silly because the performance benefit is 0.5%
ClearConditions is almost as fast as I2H.

PS: you could hire Jesus4Lyf to do you a benchmark

I don't really care about benchmarking it, but would do it myself if I did. It's less computation which isn't a bad idea when dealing with code being executed as often as this.

In any case, I just thought I'd mention it. Ultimately it's your system, and you do with it as you seem fit.

 

[Cohadar]

Most people don't realize that timer system overhead is almost non-existent when compared with stuff that they put in their timer spells.

 

[Builder Bob]

Most people don't realize that timer system overhead is almost non-existent when compared with stuff that they put in their timer spells.

[del]Stupid people like me you mean?[/del]

Edit: Sorry, this was a lame comment by me.

 

[Jesus4Lyf]

I fail to see how you optimized TT at all, there.

Honestly. Didn't you only speed up removing instances?

And only by a few nanoseconds?

:nuts:

>PS: you could hire Jesus4Lyf to do you a benchmark

Haha... Was wondering if I'd get a reputation for that.

(PS. Cohadar's suggestion - right on. XD)

Remember kids, TT can already fire over 30,000 times a second. I'm curious as to why people are suddenly making their own timer systems as well, or mutated versions. Like... I thought between TT and KT2 we had everything clearly covered.

By the way, if you really want to get rid of that swap, use linked lists like KT2. But I will call you a silly head.

YEW SILLY HEAD!

 

[Builder Bob]

By the way, if you really want to get rid of that swap, use linked lists like KT2. But I will call you a silly head.

YEW SILLY HEAD!

I don't have a great desire to remove the swap. It's just a tiny bit of optimization where there is barely any code to begin with. Using linked list would add more overhead than TT has, so I don't see why you suggest that.

Cohadar is absolutely right that "overhead is almost non-existent when compared with stuff that they put in their timer spells.", so this optimization is clearly not noticeable with the usual usage of TT. You could even add stuff, or use linked lists if you so wanted, and it wouldn't be noticeable.

Even so, it's faster but less user friendly. TT puts ease of use over this unimportant optimization, which is very understandable. I was just putting it out there. Stop with the name calling.