Evidence that Macros Do NOT Cause GCD Delay or Lost Casts

[Mikey_R]

Technically this isn't true, as I macro this way, and I know others do as well. But you are correct that not many people macro this way, and often that's because they don't understand that they should be macroing this way to actually access the queuing benefit that macros have to offer. That's part of the misinformation I'm hoping to correct.

Your macro doesn't queue, it just smashes the button over and over until it goes off (assuming the macro doesn't end before), this is different to ACTUAL action queuing where it stores the action to use, then executes it when it is available. This even applies to oGCDs and them being executed as soon as the action lock from the previous action is dropped.

As for your macro example, assuming you don't have the other actions available on your bars, why would you want to restrict yourself in that way? What if you don't want to Swiftcast and Sharpcast in the same GCD window? If your answer is you have them on separate buttons so you can separate them if you want, then why not just use those buttons instead of the clunk of a macro. Also, why have you done AE in that way? You cannot guarantee it goes off if you don't properly time it and it will be much more responsive if you had it as a separate button.

Also, you can have /micon as the last line and it will still show the right icon on your macro and it won't delay the rest of your macro by however long it takes to run 1line, making it slightly more responsive. I do not believe you can do that with the /macroerror off however.