System Timer Ticker

[~GaLs~]

>>what it points to never gets removed
I don't really get it.

In my oppinion(noob oppinion), nulling it or not will just make no difference. It won't flaw the system nor creating any lags.

 

[emjlr3]

it wont make a difference, but it is not needed, so why do it

the infinitesimal amount of time it saves does not matter, agreed, but still, why do it if its not needed

the same reason you do not need to null variables pointing to say heroes that will remain in the game always, they will always be there, thus their allocation will be as well, nulling is so you remove the memory that is spent keeping that so

Cohadar may be able to explain it better, I hardly know what I am talking about

 

[~GaLs~]

>>I hardly know what I am talking about
True... I just understand a few lines.

"The super duper small amount of time, save it or not doesn't matter."

 

[Cohadar]

what it points to never gets removed, so nulling it would do nothing

This is the correct answer.
The triggers inside TT are never destroyed, they are simply recycled over and over.
Since swap is simply pointing to recycled triggers it does not need to be nulled.

Basically the same reason you do not need to null timers when you use CSSafety.

EDIT:
I could explain you the whole story with how handles in wc3 work, about reference counters and all that technical stuff but basically all you need to know is:
When something is never destroyed -> you do not need to null it.

The most famous example would be a local trigger inside InitTrig

public function InitTrig takes nothing returns nothing
    local trigger trig = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( trig , EVENT_PLAYER_UNIT_SPELL_EFFECT )
    call TriggerAddCondition( trig , Condition( function Conditions ) )
    call TriggerAddAction( trig , function Actions )
    //set trig  = null // no need to null this since trigger is active during the whole game
endfunction

 

[~GaLs~]

So, is it because the index is keeping recycling?

 

[Cohadar]

So, is it because the index is keeping recycling?

Ok let me try to explain this in non-programmerish way.

Lets say TT uses 4 triggers at some point and that those triggers got this values from the game:


0x10003, 0x10007, 0x1000A, 0x1000C

At some point user function that called trigger 0x1000A stops and we need to remove it from the system
0x10003, 0x10007, 0x1000A, 0x1000C

But instead of deleting the 0x1000A I recycle it,
I use swap variable to move it to the end of trigger array
0x10003, 0x10007, 0x1000C, 0x1000A

After that 0x10007 trigger also stops
0x10003, 0x1000C, 0x10007, 0x1000A

But after some time you use TT_Start again and instead of creating a new trigger you reactivate the old one

0x10003, 0x1000C, 0x10007, 0x1000A

Ok but what happens if there are 5 user functions active at same time?
Simple we create a new one and add it to the array.
0x10003, 0x1000C, 0x10007, 0x1000A, 0x1000F

After that recycling process continues..

Ok but how many of these can be active at the same time?
Theoretically if you have 12 players and they all cast a spell that uses TT at the same time you can have 12 active triggers inside system.
Add a couple of other things that might use TT (like physics engine and similar) and you easily get to 20 triggers.
The demo map contains 60 heroes that use TT at the same time with no lag.

 

[cr4xzZz]

> //set trig = null // no need to null this since trigger is active during the whole game
Hmm, you learn something new every day... ^^

 

[~GaLs~]

>>Ok let me try to explain this in non-programmerish way.
Sorry but truly, I am not a programmer.
I'm just a small girl.

>>But instead of deleting the 0x1000A I recycle it,
I wonder how you do it.. lol..
How you recycle it? (In which part of your code? That non-nulling?)

Edit -
>>When something is never destroyed -> you do not need to null it.
I see. I would like to listen the big theory about warcraft handle. lol
It is better if you tell me how nulling works in warcraft. (Or even in programming world)

 

[emjlr3]

why is this not approved?

useful - yes
bugs - no?
used - yes

 

[Cohadar]

I resent that question mark.

 

[Joker(Div)]

onDestroy functions works with TT, right?

 

[Sooda]

> This method fails if PERIOD > 0.1 second

Is it because if PERIOD would be > 0.1 then newly added userFuncs would need to wait more time until timer again expires? When PERIOD is <= 0.1 then waiting would be not noticeable for players?

> onDestroy functions works with TT, right?

Yes, but don' t add waits into method (not even possible?).

JASS line from TT Demo map

    set data.ticks = R2I(distance / (SLIDE_SPEED*PERIOD))

These suggested PERIODS are for map maker who decides how smooth (Performance consuming) effects (Slide, Life Drain kind of effects, DotA Hook ability hook effect) he wants for his map.
Now something pretty clever what you have done. That PERIOD is used by ability function itself to calculate how much should unit be moved when using PERIOD X (X would be random PERIOD from suggested ones). By doing that ability maker can know should unit be moved less (when PERIOD is smaller) per tick or more (when PERIOD is bigger).
As much I understand there is no contradiction between different PERIODS so far ability maker takes into consideration PERIOD like Cohadar did in his example ability.
This system is very well thought trough. Everything looks pretty perfect. Well done Cohadar.

EDIT:
Your TT System gave me inspiration and I modified your system to use boolexpr. It now dosn' t require triggers.
Only downside is that I need to find better native what can execute boolexpr. Not time to search now. It works currently maybe little slower than yours or at same speed (I repeat everything depends how fast boolexpr can be executed). I named this system Lightning

library Lightning initializer Init
    globals
        public constant real TIMEOUT = .03125
        constant player playerX = Player(0)
        boolexpr array boolexprz
        integer array structIdz
        integer instance = 0
        integer enumStructId = 0
        timer mainTimer = CreateTimer()
        group placeHolder = CreateGroup()
    endglobals


    private function Handle takes nothing returns nothing
        local boolean bl = false
        local integer n = 0
    
        loop
            exitwhen n > instance
                set enumStructId = structIdz[n]
                call GroupEnumUnitsOfPlayer(placeHolder,playerX,boolexprz[n])
                if FirstOfGroup(placeHolder) != null then
                    call GroupClear(placeHolder)
                    set boolexprz[n] = boolexprz[instance]
                    set structIdz[n] = structIdz[instance]
                    set instance = instance - 1
                else
                    set n = n + 1
                endif
        endloop
    endfunction

    public function New takes boolexpr bx, integer structId returns nothing
        set instance = instance + 1
        set boolexprz[instance] = bx
        set structIdz[instance] = structId
    endfunction
    
    public function EnumStruct takes nothing returns integer
        return enumStructId
    endfunction

//===========================================================================
    public function Init takes nothing returns nothing
        call TimerStart(mainTimer,TIMEOUT,true, function Handle)
    endfunction
endlibrary

It' s your system concept. Demo map also (With your TT Demo map ability using Lightning)

 

[Cohadar]

Ye I had a similar idea while I was experimenting with different beta versions of TT.

Lets do a little compare:

call TT_Start(function PeriodicFunc, data) // TT
call Lightning_New(Condition( function PeriodicFunc), data) // Lightning

I think it is obvious why I chose the first one.

Besides no matter what you do you can make it only as fast as TT,
you cannot make it faster.
I use the same trigger technique Vexorian used inside vJass to run interfaces and inheritance, if there was a faster way to do it we would know, trust me.

 

[duyen]

Ye I had a similar idea while I was experimenting with different beta versions of TT.

Lets do a little compare:

call TT_Start(function PeriodicFunc, data) // TT
call Lightning_New(Condition( function PeriodicFunc), data) // Lightning

I think it is obvious why I chose the first one.

Besides no matter what you do you can make it only as fast as TT,
you cannot make it faster.
I use the same trigger technique Vexorian used inside vJass to run interfaces and inheritance, if there was a faster way to do it we would know, trust me.

For 1 less word

 

[emjlr3]

and the fact that it is not any faster, for the most part of what matters

 

[Sooda]

> trust me.

I will.

 

[Magentix]

// One Timer to rule them all, One Timer to find them,
// One Timer to call them all and in the jass bind them
// In the land of warcraft where the desyncs lie.

<3 J.R.R. Tolkien


What if I have TT (period: 0.04) in my map and I need a periodic (0.04) event at some point.

Do I:
A) Create a periodic trigger and add actions
B) Create a periodic timer and add a callback
C) Call a TT with only userFunc and null data?

 

[emjlr3]

er, create your struct and set your data

call TT_Start(struct, funtion actions_function)

it does realy explain this in the Read Me....

 

[Magentix]

No, you misunderstood:

I use spells with TT, all on a 0.04 timer.
At some point, I need a periodic event to start, without any struct data.

Do I:
A) Create a periodic trigger and add actions
B) Create a periodic timer and add a callback
C) Call a TT with only userFunc and null data?

(Since I don't need any external data (bar some globals) to be used inside the callback)


EDIT for more clarification:

Which one is the fastest, assuming I'm already using TT inside my map (and thus have a 0.04 timer running already)?

//THIS,
call TimerStart(t,0.04,true,function TimerCallback)

// THIS
call TT_Start(function TimerCallback,-1)

// OR THIS?
call TriggerRegisterTimerEvent(T,0.04,true)
call TriggerAddAction(T,function TimerCallback)

 

[Joker(Div)]

The first one.

Timers > Triggers

TT = A slower timer that allows struct passing

So Timers > TT > Trigger

I'm not a 100%, but I think I'm right.