Strange Timer delay

08-05-2006, 10:03 AM

While I was testing if an unit loses mana when casting a spell before the spell actually takes effect, I noticed a very interesting delay when starting a timer. First of all, here is the code:

JASS:

function Fizzle takes nothing returns nothing
   local unit cast = GetHandleUnit(GetExpiredTimer(), "cast")
   call IssueImmediateOrder(cast, "stop")
   set cast = null
endfunction

function TimerTest takes nothing returns nothing
local timer t = CreateTimer()
local unit cast = GetTriggerUnit()
call SetHandleHandle(t, "cast", cast)
call TimerStart(t, 0.30, false, function Fizzle)
call IssueImmediateOrder(cast, "stop")
set cast = null
set t = null
endfunction

//===========================================================================
function InitTrig_Untitled_Trigger_001 takes nothing returns nothing
    set gg_trg_Untitled_Trigger_001 = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( gg_trg_Untitled_Trigger_001, EVENT_PLAYER_UNIT_SPELL_CAST )
    call TriggerAddAction( gg_trg_Untitled_Trigger_001, function TimerTest )
endfunction

You can notice that the timer is executed at this point after 0.3 seconds. Normally, the following line from TimerTest should take place BEFORE the timer. I tested the code with a Mountain King casting Thunder Clap. With a value of 0.30, the unit would stop casting the spell before losing any mana. However, if I set the value of the timer, to 0.45 the unit would lose mana but the spell would not be cast. If I set the value of the timer to 1.00 or 10.00, the same thing would happen, because the order within TimerTest would take place before the one from Fizzle.

What do you think about this?

Edit: This is getting even stranger. Now that I removed the order from TimerTest, the unit loses mana just when the spell is cast.

Edit 2: Jesus christ, this is even stranger. If I have only the TimerTest that looks like this (same trigger initialization):

JASS:

function TimerTest takes nothing returns nothing
local timer t = CreateTimer()
local unit cast = GetTriggerUnit()
call SetHandleHandle(t, "cast", cast)
call TriggerSleepAction(0.35)
call IssueImmediateOrder(cast, "stop")
set cast = null
set t = null
endfunction

The spell takes place with mana loss and cooldown fired. Warcraft 3 engine has sooo many bugs.

Edit 3: This is getting out of control. Check this out (same initialization):

JASS:

function Trig_Untitled_Trigger_001_Actions takes nothing returns nothing
call TriggerSleepAction(0.25)
call IssueImmediateOrder(GetTriggerUnit(), "stop")
endfunction

If I set the TriggerSleepAction() to 0.27, the spell takes place, while if I set it to 0.15, it doesn't. I thought TSA() had a lower limit of 0,27 which I personally tested by running a timer in paralel and made a 0.00 seconds wait.

Edit 4: Sorry for so many edits but I found another weird behaviour. If I set the value of TriggerSleepAction to 0.25, sometimes the spell is cast, while other times the unit is stopped before hitting the ground.

~Daelin

08-05-2006, 11:26 AM	#2
Blade.dk	Are you 100% sure that it is not just the spell that has a delay? Because it often takes time from issuing an order to a unit actually does what ever it was ordered to. Especially with abilities.

08-05-2006, 11:33 AM	#3
Daelin	They were all tested with the same spell... I know the spell itself has a delay, but I do not understand why two stop orders make difference, and only in that case mana is drained without casting the spell.. It's strange that a function called in a different thread after 0.30 seconds takes place before a function called just after creating that thread. ~Daelin

08-05-2006, 11:43 AM	#4
Blade.dk	In my map, I have a system that prevents units from casting spells while being in certain areas.. It detected when a unit beings casting a spell, and all instant cast spells drained mana, but no effect took place - And I did not use timers. Triggered spells had an effect there.

08-05-2006, 12:08 PM	#5
Captain Griffen	Stop orders can be buggy. Recommended to use the pause/unpause trick.

08-05-2006, 12:14 PM	#6
Daelin	So the order itself is not buggy... Hmm, I suspected it had sometihng to do with the waits/timers. It's good to know. ~Daelin