Evidence that Macros Do NOT Cause GCD Delay or Lost Casts

[Lck0ut]

Edit:

/macroicon "Glare"
/macroerror off
/ac "Glare"

A few suggestions I would make to this macro, if you really want to use it,

a) make the first line be '/mlock', which is shorthand for /macrolock. This will block restarting the macro, no matter how fast you mash, until the current instance of the macro has finished executing.

b) make as many lines of this macro be the action you want to be used as possible.

c) move everything but the /mlock and /macroerror off commands to the end, after the /ac commands.

I would still advise against macroing your gcds, as they do not get queued like pressing the gcd itself, same with your ogcds. However, there are niche use-cases where this can be useful. For instance, a macro of mine that I use a lot while playing DNC:

/mlock
/macroerror off
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>

I have 2 more of these for <7> and <8>, respectively, and they allow me to swap my dance partner in a single gcd (albeit with a microclip due to macros not queueing up), most notably WITHOUT needing to untarget the boss at any point.

Another niche use case for macros, a macro to make a certain variation of the fire/ice towers mechanic in Dragonsong's Reprise (Ultimate) more consistent:

/mlock
/merror off
/automove on <wait.1>
/automove off
/echo
/echo
/echo
/echo
/echo
/echo
/echo
/echo
/echo
/echo
/echo

This macro allows you to move at just the right pace to bait the meteor drops so they don't detonate, for when you dont have enough room to walk without stopping.

[LilimoLimomo]

A few suggestions I would make to this macro, if you really want to use it,

Oh, to be clear I know how to make an effective Glare macro; that was just my guess as to what the macro SaltedXIV was using probably looked like based on the video they provided.

a) make the first line be '/mlock', which is shorthand for /macrolock. This will block restarting the macro, no matter how fast you mash, until the current instance of the macro has finished executing.

This is definitely something players can try if they really love button-mashing but want to use macros; that said, /mlock wouldn't be my first suggestion to solve this specific problem due to the fact that it locks you out of running further instances of macros. Because of this, if the number of frames in your macro isn't a multiple of the number of frames between each of your button presses, there's the risk of a greater loss of frames with the /mlock than without it. Which isn't to say it's bad — if this gives you the results you want, then that's all that matters! — but it wouldn't be my first suggestion.

Instead, I'd suggest a macro like this:

/ac "Stone"
/micon "Stone
/macroerror off
/ac "Stone"
/ac "Stone"
/ac "Stone"
/ac "Stone"
/ac "Stone"
/ac "Stone"
/ac "Stone"
/ac "Stone"
/ac "Stone"
/ac "Stone"
/ac "Stone"
/ac "Stone"

This way even if you're mashing, the first frame will cast the spell you want. And if you're not mashing, then you'll get some queuing behavior. Depending on the cadence of your mashing, you might want to move /micon to different locations in the macro, and if I remember correctly a macro like this won't even benefit from /macroerror off so you could probably replace that with another Stone.

Alternatively, you could try the technique I just learned from that Macrology link and do a macro like this:

/ac "Stone"
/mlock
/hotbar copy WHM 10 WHM 1
/hotbar set "Stone" 1 5
/wait 1
/hotbar copy WHM 10 WHM 1
/micon "Stone"

When set up properly, this will give you a Stone macro that tries to cast Stone on frame one, and then continues to replace the button containing this macro with the normal button for Stone for 1 second, which is long enough for you to press it if you're mashing. In this way, you can take advantage of both the benefits of macros and the extended queue duration of normal actions.

I would still advise against macroing your gcds, as they do not get queued like pressing the gcd itself

This is difficult to truly confirm or deny without actually getting an inside look at both the frontend and backend code. Personally, the evidence I've seen suggests that if there is a difference, it doesn't produce any meaningfully different results. For example, the execution of actions — whether via macro or non-macros — seems to be restricted based on the player's framerate, which suggests to me that for all intents and purposes, the way that a queued normal action functions is that it tries to execute itself once-per-frame, just like a macro that tries the same action on several lines in a row.

So as long as a player can write a macro that queues in the way they want, and as long as they can reliably press said macro within the appropriate window, I don't think there will be an issue. And that's what the test I did at the beginning of this thread suggest as well.

/mlock
/macroerror off
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>
/ac "Closed Position" <6>

I have 2 more of these for <7> and <8>, respectively, and they allow me to swap my dance partner in a single gcd (albeit with a microclip due to macros not queueing up), most notably WITHOUT needing to untarget the boss at any point.

I'm curious, how are you clipping with a non-GCD action? In my personal experience, I find that with oGCD's I generally don't even need the repeated lines because the timing of when you can press them without action loss is a lot more flexible than GCD's. So especially with a 10 frame window for this macro, I'm confused about how it would result in any kind of clipping, unless I'm misunderstanding what you're saying somehow?

[Shurrikhan]

I'm curious, how are you clipping with a non-GCD action? In my personal experience, I find that with oGCD's I generally don't even need the repeated lines because the timing of when you can press them without action loss is a lot more flexible than GCD's.

The only reason for an oGCD to be less likely to clip than a GCD action is that you can theoretically fit multiple oGCDs into a single GCD gap. I.e., it's not that the individual actions clip any less (they clip identically -- or more, for lesser ability to queue), but simply that you have more room than you could not otherwise use. Try to fit in one oGCD more, though, and you'll likely end up delaying not only oGCDs but also the following GCDs, since they both share the same animation locks; the GCD cannot start until the minimum on-use delay of the previous action has passed.

Altogether, you have skills that...

1. Neither respect nor incur animation locks. (Certain "Commands")
2. Respect but do not incur animation locks. (Certain "General Actions")
3. Respect and incur animation locks. (Other among certain "General Actions")
   
4. Respect and incur animation locks and (shared near-)unique cooldowns. (Flood, Holmgang, Assize -- and Senei/Guren -- etc)
5. Respect and incur animation locks and share a SkS-scaled cooldown with an entire class of abilities. (Weaponskills)
6. Respect and incur animation locks and share a SpS-scaled cooldown with an entire class of abilities. (Spells)

While 1-4 are all "oGCDs", the term is usually used only to describe the Group 4, with "GCDs" being Groups 5 and 6. Groups 2-6 can delay all but Group 1. It's just a matter of what space you'd have spare.

[LilimoLimomo]

The only reason for an oGCD to be less likely to clip than a GCD action is that you can theoretically fit multiple oGCDs into a single GCD gap. I.e., it's not that the individual actions clip any less (they clip identically -- or more, for lesser ability to queue), but simply that you have more room than you could not otherwise use. Try to fit in one oGCD more, though, and you'll likely end up delaying not only oGCDs but also the following GCDs, since they both share the same animation locks; the GCD cannot start until the minimum on-use delay of the previous action has passed.

Altogether, you have skills that...

1. Neither respect nor incur animation locks. (Certain "Commands")
2. Respect but do not incur animation locks. (Certain "General Actions")
3. Respect and incur animation locks. (Other among certain "General Actions")
   
4. Respect and incur animation locks and (shared near-)unique cooldowns. (Flood, Holmgang, Assize -- and Senei/Guren -- etc)
5. Respect and incur animation locks and share a SkS-scaled cooldown with an entire class of abilities. (Weaponskills)
6. Respect and incur animation locks and share a SpS-scaled cooldown with an entire class of abilities. (Spells)

While 1-3 are all "oGCDs", the term is usually used only to describe the Group 3, with "GCDs" being Groups 4 and 5. Groups 2-5 can delay all but Group 1. It's just a matter of what space you'd have spare.

Yep, I'm on the same page with you. My best guess was that the clipping might be occurring when trying to fill the GCD gap past its capacity with oGCD's. But I also didn't want to go forward assuming that was the situation, as I know so little about the context of their usage, meaning that other explanations could be plausible. Plus, there have been enough times in my life where I've written a lengthy response based on an assumption that turned out to be false, and that wastes both my time and the time of anyone who reads it! Hence the request for more details, with a bit of my thought process on the side to hopefully explain how I might be thinking about the issue differently than them.

Regardless, I appreciate the way you framed the whole issue of oGCD usage and the potential for clipping; it was a really efficient and effective way to communicate about a topic that I'm used to seeing discussed in much more abstract ways!