User:Zespri/TwoSpellsInAMacro

Copied from Blizz UI forum, author Legorol.

Q u o t e: It's currently one hardware event per action without SpellStopCasting, but you can use SpellStopCasting to reset the 'action performed' state and then try to cast something else. Cooldowns are still enforced, however, so it only helps for instant cast spells that dont trigger any cooldowns.

(And yes, you can combine this with busy loops to cast multiple spells that DO trigger cooldowns, but you'll lock up your game in the meantime, so it's not necessarily a very good idea)

Since this little trick is now out in the open, I will elaborate on this a little bit. I have tested and successfully cast multiple chained Fireballs with a single button press, using the method Iriel described. I do lock up the UI in the process, but if you want to cast the same sequence of spells (e.g. Warlock DoTs) no matter what happens to you, this does work.

From here on, I enter the world of educated guesswork (rather than hard facts), based on various observations about the WoW client behaviour.

The reason why and how this works has to do with the nature of the client-server communication that WoW performs, and with the real effect of SpellStopCasting. When you cast a spell, you don't really cast it. You merely ask the client to send a request to the server, which still has to verify whether you can really cast the spell. The client at this point enters a "locked" state, where it's awaiting response from the server on whether you really started casting the spell. Even if you wait a little bit in the Lua script (e.g. by putting in a loop for a few seconds), the client doesn't get to interpret the response from the server until you return from Lua, even if it has arrived back already. So simply casting a spell, waiting a bit, and then casting another one doesn't work.

However, calling SpellStopCasting (whose original, intended function is to cancel spells that really do take time to cast) causes the client to send a message to the server saying you cancelled the spell, and immediately unlocks itself, allowing you to attempt to cast another spell. The reason why it's implemented this way I presume is because if the client didn't unlock immediately, and instead waited on server confirmation of a cancellation message, it would mean that the player has to wait (depending on latency) a noticable amount between cancelling a spellcast and being able to start a new cast. This is not desirable from a gameplay experience point of view, because you usually want to cancel a spellcast in an emergency and quickly recast something else.

The bottom line is that the sequence of events that take place with a chained spellcasting is something like this. I will try to illustrate what's happening in parallel, as you are sitting in the Lua engine, next to the client<->server communication

Note that throughout the entire time that the game is spending time in the Lua engine, the client keeps receiving messages from the sever that it buffers, but doesn't act on.