Fastest way of attaching an integer to a trigger/timer?

[RaiJin]

i know there's always the H2I(key)-0x100000, but i wanted to know the fastest way and the most stable way of doing it without H2I ( and i don't have H2I phobia )

and with no GameCache and HashTable

 

[Joker(Div)]

Made by someone with a H2I phobia.

 

[RaiJin]

Made by someone with a H2I phobia.

sadly i can't understand that

 

[kingkingyyk3]

Trigger, I figured out you can use GetTriggerExecCount, but you cannot add any action to it. In this case, you need to add the actions to condition....

But, it is slower

Example :

library TriIndex

globals
    private integer temp //local
endglobals

public function Attach takes trigger t, integer i returns nothing
    set temp = i
    loop
    exitwhen i == 0
        call TriggerExecute(t)
        set i = i - 1
    endloop
endfunction

public function Get takes trigger t returns integer
    return GetTriggerExecCount(t)
endfunction

public function Clear takes trigger t returns nothing
    call ResetTrigger(t)
endfunction

endlibrary

Array is still the fastest way, but you need to figure out the trick about how to store and get data.

 

[RaiJin]

this is pretty much KT

 

[kingkingyyk3]

Yes. But I think H2I is still the fastest way..

 

[Kenny]

If your using structs and methods and you want the most ridiculously fast way to attach things, use Timer32.

Something like this:

private struct Data

    unit cast = null
    real newx = 50.00

    method onDestroy takes nothing returns nothing
        call KillUnit(this.cast)
        
        set this.cast = null
    endmethod

    method periodic takes nothing returns boolean
        if this.newx == 0.00 then
            call this.destroy()
            return true
        else
            set this.newx = this.newx - T32_PERIOD
        endif

        return false
    endmethod

    implement T32

    static method create takes nothing returns thistype
        local thistype this = thistype.allocate()

        set this.cast = GetTriggerUnit()

        call this.startPeriodic()

        return this
    endmethod

endstruct

Otherwise you can just use KT2, which is ridiculously fast anyway, and has very minimal downsides.

 

[RaiJin]

o.o how would i attach it without any system requirements

 

[Azlier]

...Why would you want to do it without outside systems?

 

[kingkingyyk3]

Then just use :

local integer index = H2I(trigger)
set index = index - (index / 8191) * 8191
set Data[index] = your data

This method is quite stable in H2I.

OR :

local integer index = H2I(trigger)
set index = index - StartingHandleID
set Data[index] = your data

The StartingHandleID will be assigned in map Init :

set StartHandleID = H2I(CreateTimer()) - 32

But it will exceeds the 8191 limit easily.

 

[Azlier]

>This method is quite stable in H2I.
Since when? There's not even any collision prevention.

>set StartHandleID = H2I(CreateTimer()) - 32
A broken 0x100000 with a leaked timer?

 

[Nestharus]

local integer decimalPlaces = 1000000
local real timeout = time + (id/(decimalPlaces*10))
call TimerStart(timer, timeout, false, function someFunction)

local real timeout = TimerGetTimeout(GetExpiredTimer())
local integer timeInt = R2I(timeout)
local real stripped = timeout-timeInt
local integer decimalPlaces = 1000000
local integer id = R2I(stripped-((stripped-timeInt)*decimalPlaces))*(decimalPlaces*10))

???

That "might" be faster than H2I, but when I look at it, it might not : |.

As for triggers.. no way I know of around H2I, but then again, I've only worked on timers so far : ).

 

[Azlier]

>(GetTimeout(GetTriggerTimer())-I2S(GetTimeout(GetTriggerTimer()))*10000000???

That's not even valid code...?

GetTimerTimeout or whatever it is is also inaccurate.

 

[Jesus4Lyf]

Everything has options:

• Attaching to triggers:
  
  [*]Are you declaring it on map initialisation?​
  [*]Use direct triggerexeccount and conditions returning false.​
  [*]Are you declaring it during the map's execution?​
  [*]Use an array with unique precached triggerexeccount as the index.​
• Using timers (not necessarily attaching to them):
  
  [*]Are you using multiple or varying periods in your system?​
  [*]Use KT2, or the triggerexeccount precached array index method with recycling based on timer events instead of timed events.​
  [*]Are you using a fixed period?​
  [*]Can you have a first procurement inaccuracy?​
  [*]Use T32 or copy/paste the contents of T32 and modify it to use a single timer (stupid, you should really just use T32). This is called a struct/stack loop, and isn't as fast as T32. You can change the period if you copy/paste modify.​
  [*]Must it be precise (no first procurement inaccuracy)?​
  [*]Use a list of data which the timer reads the first item of, and then removes it. When you fire a new timer, add a new item to the list. Because the timers will expire in the same order as fired, you can always just read from the top of the list to get the associated data.​

Hope you now know why to just use T32 or KT2 for timers, and try not to attach to triggers (at least after initialisation).

Why are you trying not to require systems? You'll probably get grilled for it if you're trying to submit something, but if it's for your own educational purposes, by all means...

Edit: Oh, and try not to listen to kingking's unstable H2I suggestions. If you want to use stable H2I, use Hash(H2I(handle)) to return a unique index without hashtables. But it ain't as fast as the above methods. In fact, I don't believe any H2I is faster than the above methods. H2I isn't even that fast compared to the confusion that is... Black Magic. (My stuff. XD)

Nestharus:

Spoiler

local real timeout = time + (id/10000000)
call TimerStart(timer, timeout, false, function someFunction)

local real timeout = TimerGetTimeout(GetExpiredTimer())
local integer id = R2I((timeout-R2I(timeout))*10000000)

???

??? is right. You need a good pancake bunnying.

PS. I know what you're trying to do, but you broke it.

 

[Nestharus]

Too big, of a post to quote.

Jesus, that worked on multiple timers etc in something I was doing awhile back...

I really have no clue what you are referring to : |. That code has worked in the past.

You remind me of those guys who insisted on telling me you couldn't use an index of 0 in an array : P. I kept telling them, try it out if you don't believe me, they're all like No No No, then they link me to some crappy guide for their site stating u can't use it as an index in an array : D.

That argument lasted a week o-o, and in the end the post was deleted and I got neg rep and a ban, but the -rep said, you are right but I'll look bad if I don't do this o-o.

 

[Jesus4Lyf]

Your code only works for integer durations. Look again.

But this is going off topic. That method isn't that fast. He requested fast alternatives to H2I.

 

[Nestharus]

Your code only works for integer durations. Look again.

But this is going off topic. That method isn't that fast. He requested fast alternatives to H2I.

no it doesn't?

timeout is a real??

and uhm... you can make decimals if you want.. woops o-o. I guess multiply by how many decimals you have : |.

 

[Tom Jones]

kingking's (first) suggestion is as stable as it gets with the tools Blizzard gave us. If some bonehead exceeds 8191 handles it'll simply start over.

...Why would you want to do it without outside systems?

Because there isn't an all purpose attachment system as in the old days? I really really miss KaTTaNNas handle vars.

There is no alternative to H2I(...), or GetHandleId(...) as it is called now, attachment.

 

[Jesus4Lyf]

kingking's (first) suggestion is as stable as it gets with the tools Blizzard gave us.
...
There is no alternative to H2I(...), or GetHandleId(...) as it is called now, attachment.

If you want to use stable H2I, use Hash(H2I(handle)) to return a unique index without hashtables.

Tadahh.

Now may I remind you that this thread is EXPLICITLY about not using H2I? Which means, yes, there is no one system.

(But my suggestion there is more stable than kingking's, and a good replacement for handle vars.)

 

[Tom Jones]

How is hash any different than what kingking suggested, other than you make a collision check?

I know he wanted alternatives to GetHandleId(...), which is fine if he were to attach to atomic types. However, the thread title indicates that he is attaching to handle derived types, and as such there is really no excuse as to not use a GetHandleId(...).