System vTimer

[Azlier]

>Everytime I see people use ExecCount to replace H2I I feel like jumping off the bridge.
Yes, I know, Vex. I just do it for the challenge. I'm not surprised that you're outraged. This doesn't preload timers too well. If it gets some sort of smart preloader that preloads about 512 at init and begins preloading more slowly over time, it's pretty good.

>Oh and it has an extra advantage over KT, this one actually works with long time intervals.
I do believe KT has something called HT in it now, to handle longer periods. I don't know the details.

I posted this because I misread the benchmark as it being faster. Right now, only the interface is "nice", though I did like the old interface more. The old interface was just a vJassy TimerUtils interface. .new, .release, etc.

 

[Troll-Brain]

You need to in TU also, because you need to release the timer. In this returning true both pauses and releases the timer, so it makes no difference at all. Actually, this is nicer because you don't need to get the expiring timer to release it, etc.
So having a periodic boolean is redundant, because returning true takes care of it...

Hmm you are right, didn't thought about that.

Well this system is actually slower than TU (25%). This system is just nice because it allows timer pausing.

No i mean H2I VS GetTriggerExecCount + a crazy stuff, like you have already written.

 

[Jesus4Lyf]

TriggerExecCount requires thoughtful use to remain efficient.

See, H2I is unstable without hashing or extended arrays or something else thats ugly. TriggerExecCount doesn't suffer that when used right, and is still fast. So for within systems, I condone TriggerExecCount, and condone it even further if its precached. But for common JASSers, it may be a bit much to master. I dunno.

I just don't believe that SYSTEMS should be released with h2i-0x100000 or something like that, because it breaks. And why subject your system's users to that sort of pain?

 

[Troll-Brain]

TriggerExecCount requires thoughtful use to remain efficient.

See, H2I is unstable without hashing or extended arrays or something else thats ugly. TriggerExecCount doesn't suffer that when used right, and is still fast. So for within systems, I condone TriggerExecCount, and condone it even further if its precached. But for common JASSers, it may be a bit much to master. I dunno.

I just don't believe that SYSTEMS should be released with h2i-0x100000 or something like that, because it breaks. And why subject your system's users to that sort of pain?

When you don't need the absolute fastest way possible Table + H2I is fine for me.
When you need the omg absolutest fastest way possible ever, there are other tricks like for units using an auto indexer which use UserData.
At least they make more sense and are faster to code with it, for me.

I don't consider you're not right, in fact "i hope" i'm wrong and that you will tell me why.

 

[Vexorian]

H2I is perfectly stable. It is getting tiresome with people saying that it ins unstable when it clearly isn't. Besides of being an incredibly well-tested method. The sad true is that shows how poor understanding of Jass there actually is. If H2I was unstable so would any variable/value of a handle type.

I think I may not have been clear enough using TriggerExecCount for this is just wrong. Don't come to tell me it is fast, it isn't. It will consume A LOT MORE time when attaching. It will slow down even after very low amounts of multi instances. "Use it right" You know what's actually very bad about TriggerExecCount? The situations in which it will work, are also situations in which a brain dead simple LINEAR LOOP will work. Because that's what TriggerExecCount actually requires from you: a retarded linear loop.

Nevertheless, the use of a Trigger (TriggerEvaluate) hints it is even worse than just a timer expiration

--
Oh. And H2I may require hashing or an array, but TriggerExecCount requires a giantic trigger, and a giantic loop just to work.

I cannot really cope with people getting away with saying that ExecCount is ANY good or that it can be ok when used correctly. That's misleading people. The method is an absurd one. One of the kind you would see in April first jokes back in 2005.

globals
    timer array t
    integer array ti
    integer N = 0
endglobals

// NO H2I and O(x) just like TriggerExecCount !!1111
function LeetAttachGet takes timer t returns nothing
 local integer i = 0
    loop
        exitwhen(i==N)
        if( GetExpiredTimer() == t<i>) then
             return ti<i>
        endif
        set i=i+1
    endloop
 return 0
endfunction

function LeetAttachSet takes timer t, integer x returns nothing
 local integer i = 0
    loop
        exitwhen(i==N)
        if( GetExpiredTimer() == t<i>) then
             set ti<i> = x
             return
        endif
        set i=i+1
    endloop
    set ti[N] =x
    set N=N+1
endfunction

</i></i></i></i>

 

[Azlier]

Once again, this was made almost purely for challenge. I myself don't need it.

Besides, TriggerExecCount is only O(n) when starting execution. I admit, TimerUtils Blue beats this at almost every turn. It was only posted because I misread the benchmarks.

I like to use ExecCount in simple situations, like 12 timers. Guaranteed not to fail in any situation, and requires no care from the end user. On a large scale, it becomes increasingly hard to create things at initialization, with such huge amounts of execution and O(n) needed.

 

[Jesus4Lyf]

Vexorian, with all due respect, you've seriously missed something here.

TriggerExecCount is not used to attach data here like as originally in KT2 and Key Triggers in the past, it is used to allocate a unique ID between 1 and MAX_TIMERS. This is used AS AN ARRAY KEY to access Data, meaning O(1) attaching, O(1) retrieval, and O(n) MAP initialisation (adds a second to the map's load time).

>It will consume A LOT MORE time when attaching.
Two natives and an array write, O(1) complexity, it may even consume a lot less.

>H2I is perfectly stable.
Never said it wasn't:
>Every time I see H2I-0x100000 considered "stable" without a second thought
I said H2I-0x100000.

>Nevertheless, the use of a Trigger (TriggerEvaluate) hints it is even worse than just a timer expiration
It actually fires using an event, not TriggerEvaluate. Otherwise the trigger would have to be attached to the timer some how (lol doesn't ABCT do something like that? I forget...). Anyway, you saw the benchmarks. And people can write their own if they'd like.

>At least they make more sense and are faster to code with it, for me.
Those methods don't use H2I-0x100000, so they're fine. I just personally don't use them because I know faster methods.

H2I-0x100000 is even OK for within your own maps - just I hate seeing it in published systems, because it will randomly fail in some maps without explanation.

And hey, if I was to release a system that needed to attach to units, 80% chance I'd use PUI too. (There are other O(1) complexity options sometimes.)

Hope this clears things up.

 

[Viikuna]

H2I-0x100000 is even OK for within your own maps - just I hate seeing it in published systems, because it will randomly fail in some maps without explanation.

Never heard that it could fail so badly that you cant easily make it work again.

Some example would be nice.

 

[Troll-Brain]

Simply if you have many many handles or/and many leaks.
And also there are pseudo handle like textags.
The "id" is much less , in fact it is between 0 and 99 for textags.

 

[emjlr3]

only simpletons would attach something to a texttag

triggers/timer/units is all that is needed IMO

 

[Troll-Brain]

only simpletons would attach something to a texttag

triggers/timer/units is all that is needed IMO

Attaching to a textag is soooo cooool

Seriously i was just talking about pseudo handles, that's all.
I didn't thought about any usefulness.

 

[kingkingyyk3]

H2I-0x100000 is bad. It will bug when too many timers use it, leading the attaching system to graveyard when a bug occurs. I prefer Cohadar's method, HASH_DOWN, HASH_BIAS, HASH_UP. Although Cohadar's method is slower but it wins in stability.

 

[Jesus4Lyf]

No, it will bug when there are too many handles, which usually has little to do with the number of timers.

Cohadar's method works, yes.
So does this.
H2I-0x100000 does not.
TU Red precaches so it can generally get away with it and work.
KT2 works and is fast too.

Anyway, I largely agree that all you need is units/triggers/timers, but I would say there's some legitimate cause to attach to things like rects and destructibles in very specific circumstances. And if you don't like H2I, this can be done with wrapping and attaching to triggers. Or something.

>Never heard that it could fail so badly that you cant easily make it work again.
I'll have to try making an example one day.

 

[Viikuna]

Well yea, you are right, TimerUtils Blue method can fail if your map is big enough. ( It would have to be pretty huge actually.. ) I was more thinking of Timer Utils Red -styled method which is pretty cool in my opinion.

But its not that H2I is bad. You can make a bad systems that use H2I, yes, but thats not H2I´s fault.

It is difficult to make a system that works fine for every map there is. Its way easier to make some more powerful systems for some spesific map, since you know how the map works and you can take some shortcuts here and there..

 

[Jesus4Lyf]

Yep. But those systems aren't usually the sort of thing you publish.

And yeah, it's not H2I's fault, but H2I + safety usually has faster alternatives.

EDIT: I just figured out that TU Red would become 100% stable (except for spamming NewTimer() leaks or using ridiculous numbers of timers) if the H2I subtraction "constant" was dynamically set. The reason is that handles are not freed until a wait, so since the precaching is done in intialisation, you're guaranteed a consecutive block of handles. Anyone disagree? Did I miss anything there?

 

[Viikuna]

Constant could be dynamicly setted, but it makes it slower.
Actually it was like that back in the day.

I dont really see it being a constant as a problem. You can always make some DebugMsg to find out Timer[0] handle index, write it down, and then set that value to constant. Its not that big job.


H2I( timer ) - MIN_HANDLE_COUNT just pwns.

You cant really make a faster NewTimer&ReleaseTimer like system, unless you find some other way to index timers that H2I. You can make a faster timer system, but then you cant have nice NewTimer&ReleaseTimer interface, which kinda sucks. ( Because there is so many other ways to use timers, other than those common periodic ones )

 

[Sim]

> I'll have to try making an example one day.

That would definitely be nice.

Unfortunately, I don't see much use for this system. I would use KT2 over it.

 

[Romek]

I don't see much use for this either.
It's slower than TimerUtils? Great.
Definitely a selling point.

 

[Azlier]

It was an experiment. And, once again, I posted it because I misread the benchmarks .

 

[Jesus4Lyf]

I can confirm that this system is practically useless as far as I can see.

But it's interesting code.