So basicly replace every ''dying unit'' to ''triggering unit''?
Correct. If there's a Wait in your trigger then the only safe Event Response you can use AFTER the Wait is Triggering Unit. The other Event Responses (like Entering unit, Dying unit, etc) work like basic Global Variables and can run into problems. Edit: Actually, this isn't entirely true, some Event Responses are safe and others are not, it's inconsistent unfortunately.
This is because a Global Variable can only be set to one value at a time, and this value will change globally across all of your triggers (hence the name). Triggering Unit, however, is treated like a Local Variable, which has the special property of remaining the same throughout your trigger. In other words, Triggering Unit will NOT change regardless of what you do.
Here's an example of an Event Response being overwritten. Let's say 5.00 seconds after a unit dies it's corpse is removed from the game:
A unit dies -> Wait 5.00 seconds -> Remove Dying unit from the game
This trigger appears to work fine, however, there's a big problem.
What happens when another unit dies before that first 5.00 second Wait is finished?
So a unit dies and the trigger runs:
A unit dies -> Wait 5.00 seconds -> Remove Dying unit from the game
But then 1.00 second later another unit dies:
A unit dies -> Wait 5.00 seconds -> Remove Dying unit from the game
Dying Unit is now set to the most RECENT unit that died. Meaning our first trigger is now going to reference the SECOND Dying unit, not the first one. See the problem?
It's quite annoying that none of this is made clear to the user but that's just the way it is.
Luckily, there are some tricks you can use to make using Waits a viable option, for example:
local udg_
There's also Hashtables, Dynamic Indexing, and using Local Variables in Custom Script (or not using GUI at all and writing the code yourself) that can offer ways to get around these issues.
