Evidence that Macros Do NOT Cause GCD Delay or Lost Casts

[PommesFrites]

I found this: [en]Macrology(the Third Edition)

It seems outdated by now, but very comprehensive! The translation is rough in some areas since it appears to be translated from Chinese originally, but I was able to follow it well enough. It includes the method posted earlier of swapping hotbars to an identical one with a queue-able action which then resets on a timer. This seems to be the most clever "compromise", but has very little room for mechanical imprecision (not masher friendly!).

[Collin_Sky]

I found this: [en]Macrology(the Third Edition)

It seems outdated by now, but very comprehensive! The translation is rough in some areas since it appears to be translated from Chinese originally. It includes the method posted earlier of swapping hotbars to an identical one with a queue-able action which then resets on a timer. This seems to be the most clever "compromise", but has very little room for mechanical imprecision (not masher friendly!).

This stuff is even worse than what OP is suggesting. Please do not do this.

[PommesFrites]

This stuff is even worse than what OP is suggesting. Please do not do this.

Did you... did you read any of the rest of it? This is literally an example of the use of <wait>, it has no endorsement one way or the other in the text. Goodness you folks are aggressive!

[GrizzlyTank]

I'm also using a similar macro. Mine only toggles XHBs (Astral Fire / Umbral Ice) and sets Transpose action on the slot of itself, so I need to press the same button twice to Transpose.

/macrolock
/crosshotbar copy BLM 2 BLM 3
/crosshotbar copy BLM 1 BLM 2
/crosshotbar copy BLM 3 BLM 1
/crosshotbar set Transpose 1 RAU
/macroicon Transpose action <wait.1>
/crosshotbar copy BLM 3 BLM 1

This is based on a macro I saw somewhere in Japan. I suppose that this type of macro should be allowed, even if using actions in macros remains controversial.

Yeah, macros that modify the UI is fair-game since that is all client side, thus not a victim of the ability queue issue OP constantly ignores.

Also sneaky to make the hotbars replace each other than to swap *to* the them. Can ignore the overlap between shared hotbars then for controller or rotate the entire bar like a wheel.

And guess that wait is to prevent accidental duplicate presses? Since that's something I've been having issue with when trying bar swapping macros, least on the same button.

[Mikoko_Miko]

I mean, you're allowed to use any kind of macro you want; if it works for you, then it works for you.

Thank you for your comment. I agree with you. I just wanted to nullify one of the reasons for not using macros.

My purpose of /macrolock is for ensuring overwrite by the last line. I use it because I don't have BLM macros other than Aetherial Manipulation and it seems easy to extend it to 4 XHBs ((Fire / Ice) * (Single / Multi)) without worry. Original Transpose macros I saw were two separate macros (fire to ice and ice to fire) and I united them. As a heavy user of macros, it is always necessary for me to save slots in macro editor. As the saying goes, necessity is the mother of invention. If I want to execute other macros within a window, I will simply delete macrolock and add "/chotbar copy" to those macros. If I feel pressing twice uncomfortable, I will assign the same macro to the left and right sides. If I want to use similar macros with other DPS jobs, I will apply it to make 1-2-3 combo to 1-1-1-1-1-1.

[Mikoko_Miko]

And guess that wait is to prevent accidental duplicate presses? Since that's something I've been having issue with when trying bar swapping macros, least on the same button.

It is macrolock rather than wait that prevents accidental duplicate presses. /macrolock prevents the execution of any additional macros until all steps have been executed. I guess macrolock may solve your problem.

Yeah, macros that modify the UI is fair-game since that is all client side, thus not a victim of the ability queue issue OP constantly ignores.

Probably there might be misunderstandings. Afaik OP didn't ignore the ability queue issue. There is an article which was originally posted in Japanese language and OP translated into English. "pseudo-pre-input" works like a queue.

...snip...
〇 If you make a weapon skill into a macro with a 15-line pseudo-pre-input macro, you can input it ahead of time

but the input time is short

And here is a video by the author of this article. It compares GCD delay of normal actions and macros.

Recently I found the following video.
https://youtu.be/sns_9GhUTqU

But until now I didn't take ping or latency issues into consideration. I'm not aware of them since I live near JP servers. If their effects are significant, I need to investigate. I will try DC traveling to Oceania DC.

[LilimoLimomo]

So I just watched your video, because honestly at this point I figured I'd humor you, and something felt really off, I could notice a delay after every single GCD when using macros. It's really, really noticeable when watching it, I physically felt something was wrong (I have autism so this genuinely triggers that sort of reaction in me when I can tell something is off). I even had to mute the video and watch it without sound to make sure I wasn't imagining it due to the UI sounds.
I even logged into the game and tested my GCD to make sure I wasn't wrong and ground myself to something I can control.

My dude, you are definitely clipping on every single GCD, if you say you're not, I'm convinced you don't actually know what clipping is, or just haven't learned to feel small instances of clipping (similar to how some people can't tell the difference between 30fps and 60fps). But you are 100% clipping in your video. The GCD isn't smooth when it rolls over onto the next.
The video I watched, since you called someone else out for using the wrong video: https://www.youtube.com/watch?v=H-LgAGXETgA

I watched the video again, and I'm guessing what you're seeing is simply the difference in the timing of the button presses for macros and non-macros; when a button is pressed, it creates a flash over the button icons that temporarily obscures the GCD. For macros, this flash occurs much closer to the time the GCD rolls over than for non-macros, because macros have a shorter window in which they can be pressed to not clip the GCD. This results in an aesthetic difference, and I think this is what you are probably seeing.

However, I'm not satisfied with just thinking something; I wanted to get data that could either support or deny my hypothesis. So I started with some math.

That footage was taken on a PS5 running in performance mode at 60 fps. In that context, a single frame takes 1/60 of a second. There were 25 casts per test in that video. If there was a delay of even a single frame on each cast, then that would result in a roughly 0.4 second disparity between the macro test and the non-macro test. That's nearly half a second, which is a large enough disparity that we should easily be able to see it with the naked eye in the video.

As luck would have it, the macro test's 25th castbar completes right before the timer drops from 2:02 to 2:01. This is really convenient because it makes it super easy to compare this with the timing of the non-macro test. So to find out whether this delay exists, we just check the non-macro test as the timer goes from 2:02 to 2:01. If at that time the castbar has just completed, then we'll be able to tell that there isn't a 0.4 second disparity, and thus that there haven't been any frame delays. But if the 25th non-macro cast completes more than a quarter of a second earlier than the moment the clock rolls from 2:02 to 2:01, then that's evidence that every macro cast has clipped the GCD.

And sure enough, we can see that the castbar completion for the 25th non-macro cast doesn't occur 0.4 seconds early, which supports the hypothesis. So whatever you're seeing, the APM isn't dropping, and thus it can't be clipping. Conveniently, FF14's UI flashes whenever button is pressed, and thus in both tests you can very clearly see that I press a button only once for every cast, and that all of these presses occur before the GCD is available.

[LilimoLimomo]

What is being demonstrated is that each line in a macro adds a delay.

I explain this in my initial post: every single line of a macro runs in order, with one line running per frame. Depending on how we build our macro, this can either be a boon or a detriment, which is why it's important to understand how macros function so that you can lean into the strengths and avoid the pitfalls of the weaknesses.

By exacerbating the issue through adding duplicate lines the issue as well as my point is made more clear: macros add an inherent delay independent of GCD.

It's odd that you claim that duplicate lines are "exacerbating the issue" and "adding a delay", when they're providing desired functionality. If I'm getting what I want, that's not an issue.

It doesn't take much reasoning past that to infer that they are (to an extent) going to cause a loss in GCD.

I can see how you'd come to that conclusion, but this reasoning is flawed because it fails to take into account the primary means by which GCD loss actually occurs in game: clipping. In FF14 we cast our skills and spells in chains by taking advantage of queuing, thus minimizing the delay between the GCD becoming available and the triggering of our next skill. Because of this, we can actually leverage what you're framing as a downside into a powerful tool that will allow us to avoid clipping.

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.

[LilimoLimomo]

I found this: [en]Macrology(the Third Edition)

It seems outdated by now, but very comprehensive! The translation is rough in some areas since it appears to be translated from Chinese originally, but I was able to follow it well enough. It includes the method posted earlier of swapping hotbars to an identical one with a queue-able action which then resets on a timer. This seems to be the most clever "compromise", but has very little room for mechanical imprecision (not masher friendly!).

Interesting, thanks for providing this! I'm looking forward to perusing this when I have the time! ^^

[LilimoLimomo]

Thank you for your comment. I agree with you. I just wanted to nullify one of the reasons for not using macros.

My purpose of /macrolock is for ensuring overwrite by the last line. I use it because I don't have BLM macros other than Aetherial Manipulation and it seems easy to extend it to 4 XHBs ((Fire / Ice) * (Single / Multi)) without worry. Original Transpose macros I saw were two separate macros (fire to ice and ice to fire) and I united them. As a heavy user of macros, it is always necessary for me to save slots in macro editor. As the saying goes, necessity is the mother of invention. If I want to execute other macros within a window, I will simply delete macrolock and add "/chotbar copy" to those macros. If I feel pressing twice uncomfortable, I will assign the same macro to the left and right sides. If I want to use similar macros with other DPS jobs, I will apply it to make 1-2-3 combo to 1-1-1-1-1-1.

That makes perfect sense! I go hardcore on my BLM macros so I'm willing to give them as much space as they need...I think right now I have 23 BLM-specific macros? But I very much feel the limitations of only 200 macro slots, as right now I'm capped at 200 and thus have to delete a macro if I ever want to add a new one...

"Necessity is the mother of invention" indeed; that's why I started researching macros in the first place! And it's nice to know that if push ever comes to shove and I really need to clear out some space, there are other options that I can use to condense some of these macros! ^^