Triggers Handle Ids

10-21-2009, 07:05 PM

JASS:

            set .onCheck                      = CreateTrigger()
            
            call TriggerRegisterAnyUnitEventBJ(.onCheck,EVENT_PLAYER_UNIT_DEATH)
            call TriggerAddCondition(.onCheck,Condition(function thistype.onCheckFunc))

            call BJDebugMsg(I2S(GetHandleId(.onCheck)))
            return this
        endmethod
        
        static method onCheckFunc takes nothing returns boolean
            call BJDebugMsg(I2S(GetHandleId(GetTriggeringTrigger())))

I want to know why does it print 2 different Ids...
Am I doing something wrong ?

10-21-2009, 07:40 PM	#2
Vexorian	There's a reason the manual says you shouldn't use GetTriggeringTrigger inside methods. In this case, since you placed onCheckFunc bellow the function that is calling it, it is called in another trigger.

10-21-2009, 07:46 PM

Anachron

Quote:

Originally Posted by Vexorian

There's a reason the manual says you shouldn't use GetTriggeringTrigger inside methods.

In this case, since you placed onCheckFunc bellow the function that is calling it, it is called in another trigger.

Can you elaborate that?

I mean, the triggers should be the same, shouldn't they?

10-21-2009, 07:53 PM	#4
rain.mon	Aha got it, thanks. I guess I missed that part(along with the rest of the manual when I didn't read it xD)

10-21-2009, 08:37 PM

Anitarf

Quote:

Originally Posted by Anachron

Can you elaborate that?

I mean, the triggers should be the same, shouldn't they?

No, because vJass uses a trigger in order to allow the user to call a method that is below the line from which the method is being called.

10-22-2009, 07:34 AM

Anachron

Quote:

Originally Posted by Anitarf

No, because vJass uses a trigger in order to allow the user to call a method that is below the line from which the method is being called.

Aha!

So TriggerEvent based method calling will still work (2 triggers, one ID), right?

10-22-2009, 09:54 AM

Anitarf

Quote:

Originally Posted by Anachron

So TriggerEvent based method calling will still work (2 triggers, one ID), right?

What?

If you call functions above your code, vJass will use regular function calls.
If you call functions below your code, interface methods, function interfaces or use .evaluate, vJass will use a TriggerEvaluate on a trigger that uses the function you are calling as a condition.
If you use .execute, vJass will use a TriggerExecute on a trigger that uses the function you are calling as an action.

In the latter two cases, GetTriggeringTrigger will return the trigger that is being evaluated/executed instead of the original trigger.

10-22-2009, 10:09 AM

Earth-Fury

Quote:

Originally Posted by Anitarf

If you call functions below your code, interface methods, function interfaces or use .evaluate, vJass will use a TriggerEvaluate on a trigger that uses the function you are calling as a condition.

Not always true. There are optimizations with methods that cause .evaluate to sometimes compile down to a basic function call. This is really fucking annoying considering .evaluate is a great way to beat the op limit. A solution is to declare the method you want to evaluate as a stub and extend the struct, but that prevents non-evaluate calls. (You have to extend the struct due to optimizations with virtualization. Namely, calling a virtual method on a type that has no children can be dealt with at compile time. I'm not 100% sure Vex actually did this optimization, though.)

10-22-2009, 11:17 AM	#9
Vexorian	stub keywords are ignored when the struct has no children. Anyway, I did not know that TriggerEvaluate beat the limit. .evaluate is really meant to be optimizable, so I think I need a new method name for when you actually want to use TriggerEvaluate.

10-22-2009, 12:03 PM	#10
Anitarf	The problem is, the evaluate keyword already implies the use of triggerEvaluate, maybe use a different keyword for the action that is meant to be optimizable instead? Something like FunctionName.call()?

10-22-2009, 01:19 PM

#11

Earth-Fury

Quote:

Originally Posted by Vexorian

stub keywords are ignored when the struct has no children.

Different optimization then I was talking aboot, but yeah, also a problem.

Quote:

Originally Posted by Vexorian

Anyway, I did not know that TriggerEvaluate beat the limit. .evaluate is really meant to be optimizable, so I think I need a new method name for when you actually want to use TriggerEvaluate.

It even seems to beat the limit just fine in the main() thread... Dunno 'bout config().

Quote:

Originally Posted by Anitarf

The problem is, the evaluate keyword already implies the use of triggerEvaluate, maybe use a different keyword for the action that is meant to be optimizable instead? Something like FunctionName.call()?

I completely agree.

10-22-2009, 01:53 PM	#12
Vexorian	call is already a keyword, so no. Edit: err, the number of cases in which we use evaluate just to call the function is much greater than the number of cases in which we just need to break the limit, nevertheless, if we are hitting the limit , TriggerExecute wouldn't be a bottleneck anyway so .execute is fine... So I'll probably do a new name to force TriggerEvaluate or maybe do nothing.

10-22-2009, 01:57 PM	#13
Earth-Fury	FuncName.invoke()

10-22-2009, 04:39 PM	#14
Anachron	What about. FuncName.run()?