Timer Nullify Bug

09-03-2006, 06:57 PM

Even though I didn't exactly get the bug (but as I know, it is due to nullifying a local timer variable in some conditions) I was wondering if in most cases it wouldn't be safe to use a global variable to store the timer, as long as there are no delays into the code to mess up the instanceability? Or does the instanceability still get messed up for very fast timers? I just thought about it and sorry if it is completely stupid. I admit I didn't get when the bug exactly occurs (sorry PipeDream... your explanation still left me

).

~Daelin

09-03-2006, 07:04 PM	#2
DioD	just use triggers, it faster and take less memory.

09-03-2006, 07:17 PM	#3
Daelin	Triggers also seem to have the bug so it's not a solution. And besides, since when are triggers faster than timers? ~Daelin

09-03-2006, 07:39 PM	#4
Vexorian	Triggers have a much worse bug than timers and they take more memory

09-03-2006, 07:45 PM	#5
Captain Griffen	Globals also wouldn't solve the problem. It is not a timer nullifying bug in reality, but a bug that only occurs when no variables are pointing to handle. This means changing it away from the timer can have the same effect.

09-03-2006, 08:01 PM

DioD

http://www.wc3campaigns.net/showpost.php?p=836082

Plz explain what take more memory...

JASS:

//                                                                                               //
function Register takes integer Slot , real Time , code Func returns nothing                     //
    set udg_LH_Events[Slot] = CreateTrigger()                                                    //
    set udg_LH_Actions[Slot]= TriggerAddAction(udg_LH_Events [Slot],Func)                        //
    call TriggerRegisterTimerEvent(udg_LH_Events [Slot],Time,true)                               //
endfunction                                                                                      //
//                                                                                               //

This function create "Timer" and fix all data to static arrays.
i tested it hard, it dont leak

09-03-2006, 08:06 PM	#7
Vexorian	that function is awfully lame.

09-03-2006, 08:10 PM

Daelin

DioD, I know you are trying to help but why not reading the other replies first?

Quote:

Originally Posted by Vexorian

Triggers have a much worse bug

And I quote from blizzard scripts.

Quote:

Originally Posted by Blizzard

// Creates it's own timer and triggers when it expires
native TriggerRegisterTimerEvent takes trigger whichTrigger, real timeout, boolean periodic returns event

So in base (native code made in C++) it still uses a timer => bug still exists.

~Daelin

09-03-2006, 08:13 PM	#9
blu_da_noob	It uses a timer in the native implementation, but you never reference the timer or attach anything to it, so the timer bug doesn't come into play here. The trigger one does, however. We also don't actually know if Blizzard cleans those timers up....* *do we?

09-03-2006, 08:15 PM

#10

Vexorian

Well triggers' bug is not really related to periodic timers but with DestroyTrigger

anyways:

JASS:

function Trig_Melee_Initialization_Actions takes nothing returns nothing
 local integer i
 local integer j=20
 loop
     exitwhen j==0
         call TriggerSleepAction(0.)
         set i=0
         loop
             exitwhen (i==5000)
             //call CreateTrigger()
             call CreateTimer()
             set i=i+1
         endloop
    set j=j-1
 endloop
 call BJDebugMsg("!!!")
endfunction

Test with triggers ends up taking 154440KB of memory, test with timers ends up taking 120330 KB , also the test with timers seems to freeze the screen for smaller times.

09-04-2006, 02:53 AM	#11
DotA_DR	i think, need test with full construction JASS: set t = CreateTrigger() call TriggerAddAction(t, function Action) call TriggerRegisterTimerEvent(t, 10000, false) and JASS: set tm = CreateTimer() call TimerStart(tm, 10000, false, function Action) btw, nobody answer on first post, it's intresting to me too

09-04-2006, 03:11 AM	#12
Vexorian	ah yes, the globals wouldn't help too much, if you assign other timers to them. It would have the same effect as nulling a local. And if you don't ever assign new timers to the globals, then the system would be static and limited.

09-04-2006, 11:16 AM

#13

Toadcop

Pff ! soon i will present or oh yes ! i have already uploaded my solve for timer "nulling" problem it 100% with out bugs + fast !

http://xgm.ru/forum/attachment.php?attachmentid=8656

it's copyrighted ;)

here the link possibly someone will not understand the sense of it...

Attached Images

SteamThroneFinal.jpg (76.9 KB)

09-04-2006, 11:39 AM	#14
Captain Griffen	We've already solved the bug, I think. Just pause repeating timers before you destroy them.

09-04-2006, 11:48 AM

#15

Toadcop

Quote:

Just pause repeating timers before you destroy them

and after this you will create a new timer in a buged func and it will have shit handle index... =)

PS in Rising~Dusk map the are not only timer bugs there are also effect bugs (i mean they have some times identical indexes...) so some effects are not removed correct... to use effect array maybe will help a bit =)