I understand exactly what you mean and again I wasn't trying to single you out, I simply wanted to use this opportunity to make a message to everyone. Lately I feel bombarded with "I don't understand, do it for me", which is rather frustrating and is the reason why I said what I said. Here's hoping that others will read this and be more open to learning!
Duckfarter could've been a bit more specific but I still think he explained things well. But for someone brand new it may have been better to say something along the lines of, "When you select an Event Response there is often a tip at the bottom of the window which explains which
Event this
Event Response is meant to be paired with". That and an explanation of how Events and Event Responses work together, but based on your trigger it appeared as though you knew already.
That aside, looking at your current "fixed" trigger, there's still an issue as well as a potential issue:
1)
-
Unit - John Mrgl 0007 <gen> Is issued an order targeting an object
This Event is doing nothing at the moment and serves no purpose here, which DuckFarter explained. If it appears to work, it's for the wrong reasons and you should delete it.
Events and Event Responses work like so:
For each
Event in the game you have very specific
Event Responses which can be used with them. These
Event Responses are nothing more than global variables which get set automatically by the game - the same way that you Set your own variables. For example, here's an Event:
-
Events
-

Unit - A unit dies
And here are the Event Responses that can be used with it:
-
(Triggering unit)
-
(Dying unit)
-
(Killing unit)
Through these Event Responses you can also run functions to get the Player that these units belong to and other important information.
It's important to understand that
NO other Event Responses will get set in response to this Event, so trying to reference them is a major mistake! So when you're trying to get the (Ability being cast) in response to an "A unit Issued an order" Event you're making this mistake - these are not paired together.
In the case of most casting Events you can use the following Event Responses:
-
(Ability being cast)
-
(Triggering unit)
-
(Casting unit)
-
(Target unit of ability being cast)
-
(Target point of ability being cast)
Note that (Target point of ability being cast) is only set if the ability actually targeted a Point, which can be used with abilities like Shockwave, Serpent Ward, Earthquake, etc. Also, the Finishes Casting event loses reference to everything
target related.
You may have noticed the (Triggering unit) Event Response being used in both of these examples. This always gets set to the
UNIT that is mentioned in a Unit Event -> A
UNIT dies, A
UNIT casts an ability, A
UNIT enters a region, etc. It's recommended to use this Event over others as it retains it's reference even after the Wait action - an issue I imagine you'll run into in the future.
2)
-
Unit - John Mrgl 0007 <gen> Begins casting an ability
This Event fires when the unit begins winding up to cast the spell, so before the ability is actually executed.
Executed is a term I use to describe that the ability has spent it's mana (if any), gone on cooldown (if any), and unleashed it's effects like summoning a pair wolves or throwing a hammer at the enemy unit.
The potential problem here is that you could interrupt the ability before it's executed and still cause the trigger to run. For example, if you issue a "Stop" order to your Murloc immediately after pressing the hotkey for Talk, the JohnTalk trigger will still run. The unit
BEGAN to cast the ability, but it was never successful because you interrupted it. The user could exploit this by constantly casting/cancelling the ability, causing the trigger to run repeatedly while the ability is never actually executed and thus it's mana cost is never spent and cooldown never starts.
This may be fine and even ideal for your Talk ability since I imagine it doesn't have a cooldown or mana cost in the first place, however, it can cause A LOT of problems for other types of abilities/triggers.
One last thing. These casting Events are tied to the animation system used in Warcraft 3. To explain:
Unit's have a field called
Cast Point, which is the amount of time it takes for their spells to execute.
This value is meant to be synced with the unit's "Spell" animation that their Model uses in order to execute the effects at an ideal time. In other words, this is used so that our Wizard's magical Fireball comes out of his staff after he has waved it around a bit, not before he has even lifted a finger. The added delay is also a nice mechanic for balancing combat and making things look pretty.
Unit's also have a field called
Cast Backswing, which is the amount of time they spend playing the rest of their "Spell" animation after it's been executed. This can actually be cancelled and if you've ever heard of the term "animation cancelling" this is exactly what it applies to. Much like Cast Point this mechanic is here to make the animations play out nicely.
Taking those two Cast fields into consideration when dealing with the different Cast Events should help clear some stuff up.