[General] Should i use "triggering unit" instead of:

[Gumberbunbder]

should i use "triggering unit" instead of casting unit, entering unit, constructed unit, dying unit, etc on all occasions?

 

[Shadow Fury]

Don't. It is safer to use things like casting unit, entering unit etc... although triggering unit would work, it is not guaranteed that it will refer to the unit you want if in a trigger there are multiple units to whom you refer.

 

[WaterKnight]

Yes you can. Registering different kinds of events to the same trigger should be avoided anyway and you do not use event responses throughout the trigger code, instead save them in variables at the entry point. Writing triggering unit spares you from some corrections when you change the event later on/copy parts of the code and therefore makes tests less likely to fail, easier development.

 

[BloodDrunk]

You can use Triggering unit yes, but as shadow fury mentioned, it sometimes may not refer to the unit that you want to refer to.
For more safety and efficieny, use "casting, killing, dying...." And set that to a temp variable and then use the variable.

 

[Flux]

should i use "triggering unit" instead of casting unit, entering unit, constructed unit, dying unit, etc on all occasions?

Since you used the word "all occasions", the answer is no.

However if you are sure that Triggering Unit is refered like in A Unit Dies (dying unit = triggering unit) or A Unit Starts the Effect of an Ability (casting unit = triggering unit), use Triggering Unit because they are natives (Faster than Dying Unit in GUI) and local variables meaning no conflict with Waits

Triggering Unit refers to the Unit that causes the Trigger to Run.

 

[WaterKnight]

it sometimes may not refer to the unit that you want to refer to.
For more safety and efficieny, use "casting, killing, dying...."

The same can happen with your specific natives, you have to know what you are doing in any case. But at least Triggering unit always has a value in unit events.

because they are natives (Faster than Dying Unit in GUI) and local variables meaning no conflict with Waits

Most event responses are natives, even what is exposed to GUI. And the local-behavior is the same.

 

[Flux]

Most event responses are natives, even what is exposed to GUI. And the local-behavior is the same.

Most but not all..

 

[IcemanBo]

I agree pretty much with Waterknight.
And as said most others are natives as well, TriggeringUnit() is more general, which doesn't mean it's "unsafe" or less "efficient".
It's even rumor that triggering unit is slightly faster (haven't tested myself), that's why it's recommended.

Though me personaly do not critique someone in using other event response natives as I think it's more descriptive,
because they tell the reader something about the trigger event.

 

[Wietlol]

It's even rumor that triggering unit is slightly faster (haven't tested myself), that's why it's recommended.

function GetAttackedUnitBJ takes nothing returns unit
    return GetTriggerUnit()
endfunction

Why dont we use BJ functions?
Same answer.
(However this is only on this one.)

But in other cases... the same is done behind the screen.

As answer:
Use Last ... unit or Triggering unit in almost every case.
Always look at the event that you have.
The events ussually say "A unit does this."
Then "A unit" is the Triggering unit.
There is one exception (afaik) which is "Unit - A unit Begins construction"
Construction events where the Triggering unit is actually the structure instead of the builder.

 

[IcemanBo]

I don't understand your reason to quote me.

 

[Wietlol]

You dont have to test the ones that refer to GetTriggerUnit() in their BJ.
Which is why they are faster.

 

[IcemanBo]

I was talking about natives of course.