Evidence that Macros Do NOT Cause GCD Delay or Lost Casts

[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?

[LilimoLimomo]

A long time ago, circa 2015 or 2016, there were several threads on macros here. I've completely forgotten them, but according to my post history I've posted pseudo-queueing macros and hotbar changing macros. They were not my own invention, so such tips were already widely known in JP community. At that time there were more macro users and less aversion in English forum than today.

User Macros: New Options + Sharing Macros with others in game
Is it a DPS loss to use macros?
Useful Healing Macros
WHM Macros
[SCH] Macro and Targeting Issues
Bug in AST Rez skill?

You keep sharing so many cool resources with me! I'm really appreciative! I don't have time to go through all of these right now, but I'm looking forward to it! ^^

[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!

[LilimoLimomo]

A long time ago, circa 2015 or 2016, there were several threads on macros here. I've completely forgotten them, but according to my post history I've posted pseudo-queueing macros and hotbar changing macros. They were not my own invention, so such tips were already widely known in JP community. At that time there were more macro users and less aversion in English forum than today.

User Macros: New Options + Sharing Macros with others in game

I'm going through these one at a time so I can truly enjoy them all when I have a few moments here and there.

Wow, you weren't kidding! All the way back in 2014 you had already discovered and shared how to pseudo-queue macros! I wish I had been on the forums back then, it would have been great to be able to benefit from that knowledge and take part in those kinds of discussions! :O

It's also interesting to catch a glimpse of the design goals the devs had for the macro system at that time, and how for different players that either aligned or didn't align with what they wanted the system to grow into. I particularly like being able to measure how successful the team was at meeting each design goal by thinking about different macro use cases that either stay within or exceed the devs' intended limitations.

[Mikoko_Miko]

I was glad when I found this thread, and now I'm glad to have a meaningful interchange.

I remembered when I first made a macro by myself without copy-and-paste. It was mid 2013. I was annoyed with the auto redirection into <me> when I cast a healing spell targeting an enemy. I wanted to change it into <tt>. I didn't think of targeting a tank and use /action [attacking action] <t> / <tt>. Instead, after some trial and error, I created a macro like this.

/macroicon "Cure"
/macroerror off
/macrolock
/target
/focustarget
/target <tt>
/targetlastenemy
/targetlasttarget
/action "Cure"
/target <f>
/focustarget off

It worked as intended, but introduced a noticeable delay. I searched the web and found <mo> macros. After a while, I found pseudo-queueing macros. I started to post in English Forum much later (mid 2015).

[Mikoko_Miko]

I've long wondered why some people have an illusion of nonexistent clipping in the Blizzard macro video. But the mystery was solved.

Spell recast time displayed is not accurate to actual recast time

Blizzard is not an instant spell, so the time between casts is about 100 milliseconds longer than its recast time. This is "Working as Intended". This gap (so-called caster tax) was misunderstood as a clipping.

Low frame rate also increases real recast time, but it is not relevant to the video.

Low frame rate increases recast time

[Rin_Sato]

But rather than trust an armchair theory, why not simply engage with hard data? Check out the video evidence I provided in my first post, and let me know if you can see a meaningful difference between in the GCD.

You're absolutely right.
Please record yourself playing a complete duty with macros such as these as a demonstration, rather than armchair it against a dummy, with hardly 30 seconds of combat.
Further, I'd urge you to view the combat log of such a duty and in whatever way you please, be it by writing code or manually, figure out how much uptime you had (how many gcds you lost/didnt lose).
After posting a complete log with all actions listed along with your skill speed, it will not be difficult for others to replicate or counter whatever the "proof" ends up being, which would be a reasonably thorough methodology.

Though, it is now apparent to me that you are likely baiting, so I'll offer my apologies for not realizing this sooner.

[LilimoLimomo]

I've long wondered why some people have an illusion of nonexistent clipping in the Blizzard macro video. But the mystery was solved.
Blizzard is not an instant spell, so the time between casts is about 100 milliseconds longer than its recast time. This is "Working as Intended". This gap (so-called caster tax) was misunderstood as a clipping.

Ah, that makes a lot of sense. It does seem likely that this is probably what folks like Collin were seeing.

By the by, I love how accessible and high-quality your posts are! ^^

[Collin_Sky]

Ah, that makes a lot of sense. It does seem likely that this is probably what folks like Collin were seeing.

No. Stop looking for excuses lol