Triggers and conditions and stuff

04-22-2007, 08:55 PM

Hello, do you know our classic dynamic trigger usage, create trigger attach added trigger action then remove the trigger action before destroying the trigger...

It seems that using conditions instead of trigger actions is much better. With the limitation your dynamic trigger won't be allowed to have waits (not that it matters at all)

* conditions are faster than actions since the don't have to create a new thread.

* It seems that conditions don't have to be cleaned and that DestroyTrigger would already do all the dirty work:

JASS:

function h2i takes handle h returns integer
    return h
    return 0
endfunction

function Experiment_Child takes nothing returns boolean
   call DestroyTrigger(GetTriggeringTrigger())
   return false
endfunction

globals
    integer max=-1
endglobals

function Experiment_Main takes nothing returns boolean
local trigger t=CreateTrigger()
local integer k


    set k=h2i(t)
    if (max<k) then
         call BJDebugMsg(I2S(k))
         set max=k
    endif
   call TriggerRegisterTimerEvent(t,.01,false)
    set k= h2i( TriggerAddCondition(t,Condition(function Experiment_Child)) )

    if (max<k) then
         call BJDebugMsg(I2S(k))
         set max=k
    endif





   set t=null
   return false
endfunction

//==========================================================================
function InitTrig_Experiment takes nothing returns nothing
   local trigger t=CreateTrigger()
   call TriggerRegisterTimerEvent(t,0.015,true)
   call TriggerRegisterTimerEvent(t,0.02,true)
   call TriggerRegisterTimerEvent(t,0.035,true)
   call TriggerRegisterTimerEvent(t,0.04,true)
   call TriggerAddCondition(t,Condition(function Experiment_Main))
   set t=null
endfunction

After 7 minutes this test won't show the expected massive increase in memory nor any increase of handle ids...

...
* Theorically, conditions being implemented in a different way than actions could have a chance of not being vulnerable to our beloved chance of bug caused by DestroyTrigger() but this is just speculation and not tested.

04-22-2007, 10:52 PM

Sliderman

It looks very interesting but I don't understand all :/.

What does h2i do, to return the position in the memory, of the object handled by the parameter ? Why do you put return 0 after return h ? Can this be executed sometimes ?
edit : I just read it :

Quote:

Originally Posted by Blade.dk

WE's/Warcraft 3's parser only checks if the last type returned from a function are correct

OK, forget my question about "return 0" ^^

Quote:

Originally Posted by Vexorian

function InitTrig_Experiment takes nothing returns nothing
local trigger t=CreateTrigger()
call TriggerRegisterTimerEvent(t,0.015,true)
call TriggerRegisterTimerEvent(t,0.02,true)
call TriggerRegisterTimerEvent(t,0.035,true)
call TriggerRegisterTimerEvent(t,0.04,true)
call TriggerAddCondition(t,Condition(function Experiment_Main))
set t=null
endfunction

The booleans "true" mean that this is supposed to be periodic, right ?
Why, when i try it, the trigger is executed only 4 times ?
edit : oops sry, I checked by adding this in the main function and saw that it is executed periodicly:

JASS:

call BJDebugMsg(I2S(i))    //i has been added to the global variables ofc
set i = i+1

But why the numbers are displayed only once ?

On the screen is displayed :
1048673
1048676
1048677
1048679
1048680
1048682
1048683
1048685

Are these numbers the position in memory of the created triggers and their added condition ? If yes, what is the unit of these values (if there is one) and from which point of the memory does it begin ?

Quote:

It seems that conditions don't have to be cleaned and that DestroyTrigger would already do all the dirty work:

Can you explain me these two things please ?

Quote:

After 7 minutes this test won't show the expected massive increase in memory nor any increase of handle ids...

Is this "massice increase of memory" a leak ? And what is it from ?
Is it the same problem that causes memory leak with my monsters spawn trigger ? (cf. monster spawn leak topic)
Whats does "ids" mean ?

Quote:

Theorically, conditions being implemented in a different way than actions could have a chance of not being vulnerable to our beloved chance of bug caused by DestroyTrigger() but this is just speculation and not tested.

What bug, concretely ?

Sorry for all these questions, but I am a noob and I don't want to stay one all my life :(

04-23-2007, 02:41 AM

Vexorian

Quote:

Are these numbers the position in memory of the created triggers and their added condition ? If yes, what is the unit of these values (if there is one) and from which point of the memory does it begin ?

Jass uses its own virtual memory so these are 'positions in memory' but just for Jass, they don't have an actual relation with real memory addresses.

Quote:

Can you explain me these two things please ?

When we use TriggerAddAction we have to remove the triggeraction before calling DestroyTrigger but it isn't the case with conditions.

Quote:

Supposedly triggerconditions had a leak that was not cleaned automatically by DestroyTrigger, if it was true that those were not cleaned automatically with DestroyTrigger (As it is the case with trigger actions) then this test should have caused a big increase in memory, but even after 7 minutes it did nothing.

Quote:

What bug, concretely ?

That's a very long story and actually very controversial, try a wc3c search for "gamecache bug"

04-23-2007, 03:47 AM	#4
emjlr3	have similar tests been conducted with ta's? regardless, does the boolexpr added in the trigger condition not leak? even if the triggercondition itself does not

04-23-2007, 03:49 AM	#5
Vexorian	Yes, and the results were the opposite

04-23-2007, 08:17 AM	#6
Toadcop	Vexorian idea stealer... =) (once again) no the word "stealer" have no place here but i have/do allready use this... PS yes it does not leak ! conditions like events...

04-23-2007, 01:41 PM	#7
Vexorian	I had the idea then I contacted IceFrog and it happens that he also had the same idea then he told me it seemed that conditions didn't leak then I tested and they didn't I then tested for handle ids because grim told me to.

04-23-2007, 05:11 PM	#8
Mezzer	Ok, sounds good. Which ways are you planning on using this in vJass?

04-23-2007, 05:13 PM	#9
Vexorian	since it doesn't rely on dynamic triggers I would say none.

04-23-2007, 05:14 PM	#10
Mezzer	Thought as much. Ah well, nice find though.

04-23-2007, 05:19 PM	#11
emjlr3	neat find, I will try to incorporate this into my triggering now

05-12-2007, 01:40 PM

#12

Sooda

> With the limitation your dynamic trigger won't be allowed to have waits (not that it matters at all)

What are you keeping in mind ? When I use triggerSleepAction in condition function it should cause something bad or not ? I have used wait in condition function and haven' t saw nothing odd. If it causes bugs or something can we just call new function what has waits ? Example would be:

JASS:

function TriggerMainActions takes nothing returns nothing
        call TriggerSleepAction(30.)
        call DisplayTextToPlayer(Player(0),0.,0., "Are waits allowed when used like this ?")
endfunction

function ConditionFunc takes nothing returns boolean
       call TriggerMainActions
       return false
endfunctin

05-12-2007, 01:45 PM	#13
Vexorian	I think you may be suffering hallucinations, cause last time I checked a wait in a condition halts the thread...

05-12-2007, 01:57 PM	#14
darkwulfv	Maybe I'm just blunt, but I really don't see (from your example anyways) how conditions are able to replace actions. Your example confused me more than it did explain how using conditions replaces actions...

05-12-2007, 01:59 PM	#15
Vexorian	You want to run code when an event is triggered, right? both conditions and actions have that skill.