Evidence that Macros Do NOT Cause GCD Delay or Lost Casts

[Jeeqbit]

Not sure if this is a troll post or bad advice thread....do not use macros on ur ability....

It's one thing to say they are not optimal when done in certain ways. However, it's wrong to say they can never be. For example, I have intervention macros, nascent flash macros, shirk macros, rescue macros, aetherial manipulation macros, sacred soil/asylum macros, etc. It would definitely be sub-optimal to not macro them and even make me lose whole GCDs.

Where they are sub-optimal, this is often minor unless you macro a combo/combination of things, where the waits cause a whole 0.5 delay minimum or skipped casts in the macro.

For example, you can "macro two things together" to create a priority system where the macro will only actually use one based on factors such as level or if one of them is on cooldown.

Also, I think part of the point of these posts is that it's made more sub-optimal by pressing the macro more than once, restarting the macro before it can even execute.

[LilimoLimomo]

Okay, I've done a rudimentary translation of the article and it was very thoughtful. I learned a few things and thought it was a worthwhile read, but I'll let it speak for itself. Everything below here is the article, the original text can be found at: https://jp.finalfantasyxiv.com/lodes.../blog/4722988/.

As you can see, there is no delay in the GCD even if you change the normal weapon skill pre-entry to the 15-line rapid-fire macro pseudo pre-entry.

The reason why there is a 5-frame delay with the 15-line rapid-fire macro at 60fps is because the pseudo pre-entry acceptance time is too short at 60fps, so some inputs fail to be pre-entered.

As I said before, normal weapon skill pre-entry is a process that "determines whether the GCD has cleared every frame, and if it has, the next weapon skill occurs," while the 15-line rapid-fire pseudo pre-entry macro is a process that "executes a weapon skill every frame, and if the GCD has cleared, the weapon skill occurs."

Although there is a slight difference in the weight of the processing, the frame (calculation result) at which the weapon skill occurs does not change, so it is thought that there will be no significant delay in the GCD even if you change to the 15-line rapid-fire macro. The results of this test also suggest this.

---

However, is it always okay to macro skills? The biggest problem with macroing skills is that the time it takes to input in advance is short. Since macros are processed every frame, 14 lines at 60fps (1 frame is 0.01666 seconds) is only 0.2333 seconds.

Normal weapon skill input is said to take about 0.6 seconds to input in advance, so 0.2333 seconds is quite short. In fact, if you try it, you will find that it is almost impossible to continue inputting in advance for 0.2333 seconds.

Therefore, I think that in order to use pseudo input in advance macros in actual combat, the frame rate will have to be lowered to about 30fps.

However, the problem here is that, as can be seen from the above test results, there is no GCD delay even when you make a pseudo input in advance macro for weapon skills, but if you lower the game frame rate, there will be a GCD delay even when you input normal weapon skills in advance.

---

First of all, as mentioned above, FF14 skills occur "every frame", so even if the GCD ends, the next weapon skill does not activate immediately, but "in the next frame after the GCD ends". This is important.

Ultimately, a game is a 60fps flip book. 60 flip books per second are made to look like continuous motion.

And 60fps means that there is a gap of about 0.01666 seconds between each frame. Therefore, there is a delay of 0 to 0.01666 seconds between the end of the GCD and the next frame (skill activation). If frames always came every 0.01666 seconds, that would be a different story, but there is a slight difference, so on average, the delay is 0.008333 seconds.

If this is 30 fps, then from the end of the GCD to the next frame (skill occurrence), there is an average delay of 0.01666 seconds.

If 60 fps becomes 30 fps, the actual GCD will be increased by an average of +0.008333 seconds, so if you punch for 180 seconds (about 74 times) with a GCD of 2.41 seconds, the total delay will be about 0.6166 seconds.

In the above test, the GCD is delayed by about 0.716 seconds at 30 fps, so it can be said that it is roughly as expected.

---

In addition, if the interval between frames is always fixed at 0.01666 seconds, the GCD can only change in 0.01666 second increments, so there should be a delay of 1.233 seconds when changing from 60fps to 30fps. However, this did not happen, so it seems safe to assume that there is quite a bit of variation in the time per frame.

If you lower 60fps to 30fps, it seems safe to say that the GCD will increase by 0.01 seconds (about 100 in substats). In that case, 60fps would be better, but warriors have no value unless they use macros to send Nascent Glint to others, so I am hesitant to go to 60fps. Well, the mechanics of Nascent Glint are so bad that they should definitely be abolished in 6.0...

Or rather, if you play end content at 60fps, your PC will heat up tremendously, so it's not possible... I guess it's impossible to stick with the top players with just a notebook...

Other than that, the 14-line consecutive tapping pseudo-pre-input macro has the advantage that you can pre-input from outside the attack range. Since you can't pre-input from outside the range of a normal skill, it's difficult to "attack the moment you come within range" manually. However, the 14-line consecutive tapping macro makes this possible, so for example, you can "run up and hit Onslaught the moment you come within Onslaught's range"

---

For now, please remember that

× If you make a weapon skill into a macro, you can't input it ahead of time

〇 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

[Mikoko_Miko]

One question I have is that I notice some of your macros have /targetlasttarget twice in a row. Can you tell me a bit more about that? I'm always interested to learn new tricks!

Thank you for your interest. I'm pleased to read your kind words. My intention of doubled /targetlasttarget is for consistency; my target won't change by the macro whether I canceled a target before execution or not. I usually target an enemy and focustarget a tank and my mouse cursor is on a job icon of the tank in a party list. When I want to place something at the target, I just execute the macro. But when I want to place one at the tank, first I need to cancel a target (× button of a controller) and then execute the macro. I wanted to re-target automatically in the latter case.

target A -> target B -> execute macro
first /tlt targets A
second /tlt targets B

target A -> target B -> cancel target -> execute macro
first /tlt targets B
second /tlt targets B

target nonexistent -> target A -> execute macro
first /tlt targets A
second /tlt targets A

target nonexistent -> target A -> cancel target -> execute macro
first /tlt targets A
second /tlt targets A


I was advised several times to not using macros because actions are queued and macros are not. But I noticed that I can't queue actions in certain circumstances by several reasons; target is out-of-range, MP is insufficient, aether flow is empty, etc. In these cases pseudo-queued macros can be executed when available but non-macro actions can't. I expect that macros can be more efficient than actions in these limited cases.

It can be verified by the following procedure.
1) Make a macro that repeats the same instant attacking (or healing) action.
2) Target an enemy (or a party member) and take a distance until an action text colour turns red.
3) Execute the macro while you are out-of-range and move toward the target.
4) Repeat 2) and 3) on another target with a non-macro action.
After several experiments, I found that macros succeeded in the almost all cases but non-macro actions always failed.

[Dysvalence]

I use macros extensively and it's great to see a writeup like this but there's a few additional things I'd add:

1] IME macros are not super reliable with fast keyboard inputs- I use all 10 hotbars and exp crossbars for extra space and toggle them constantly but have dedicated on/off keys because occasionally one gets stuck out of sync with the others, and not from cancellation. I also don't use hotbar copying for branching menus because it broke too often, especially when I had a macro to commit changes to a backup hotbar for basic version control.

2] Not everyone has a stable framerate so pseudobuffering is inconsistent

3] Sometimes I repeat multiple different things to give some extra reliability to anim lock conditional logic; inline waits are good for cramming more stuff in

4] Single weave macros have fixed weave timing- some jobs want to early or late weave specific ogcds, and occasionally change between the two

5] IME macros increase button usage and haven't ever saved space for me. Like many others, I mostly use ogcd ground placement or mouseover macros. But most of the time I'll still need the non macroed version for early/late/double weaves or other stuff; on ground placements I also have both macro to self, and macro to target. For dashes to allies like icarus etc, I have regular and mouseover macro versions, and for PVP I'll often have all of these, especially bishop and southern cross. Ultimately this turns one button into two or three and at best there's no net change with non macroed versions going to click only space.

6] In trusts/duty support, the hard clipping loss from waits is worth it if you use macros to AFK during trash packs. Target of target <tt> on each line then targetting the tank even removes the need to manually target things. Great for glam farming. BLM is prone to getting jammed on swaps between AF and UI if something dies early but disproportionately benefits from sps tuning

7] Not a fan of using it for saving keystrokes in combat; interrupts, losing uptime, or panic triple weaving mits makes things really weird. People who need macros are more likely to do this, and recovering typically needs raw inputs and the ability to play without macros in the first place. IMO it's an active detriment to self improvement and is frequently a crutch for poor hotbar layout, but I'm also of the opinion that jobs that have static rotations suitable for extensive macro automation are poorly designed and uninteresting.

[Mikoko_Miko]

If you lower 60fps to 30fps, it seems safe to say that the GCD will increase by 0.01 seconds (about 100 in substats). In that case, 60fps would be better, but warriors have no value unless they use macros to send rage to others, so I am hesitant to go to 60fps. Well, the mechanics of rage are so bad that they should definitely be abolished in 6.0...

"rage" is for "Nascent Glint" by WAR's "Nascent Flash" action. I was amazed that other in-game Japanese jargon were translated into English properly.

In JP community × symbol represents denial, negative or bad, and 〇 symbol represents affirmation, positive or good.

[LilimoLimomo]

I also don't use hotbar copying for branching menus because it broke too often, especially when I had a macro to commit changes to a backup hotbar for basic version control.

This is interesting, I've never had this feature break for me. Maybe it's because I always put the copycrosshotbar command in the first few lines of the macro? Or maybe somehow the non-cross hotbar version works differently? I'm not sure if I understand what you mean by "commit changes" in the context of macros...though that does make me want a Github for macros! ^^

2] Not everyone has a stable framerate so pseudobuffering is inconsistent

Definitely, this is one of the aspects that make it important to understand your own subjective needs, not only of your human body but of the device your game is running on.

5] IME macros increase button usage and haven't ever saved space for me.

Interesting, so you like to have multiple versions of the same ability, so you can take advantage of the different behaviors depending on your dynamic needs. I've never heard of that before, but that's cool!

Perhaps it's because I'm on controller and thus don't use mouseover macros that macros have only ever reduced my button bloat?

6] In trusts/duty support, the hard clipping loss from waits is worth it if you use macros to AFK during trash packs.

Sometimes if I'm out doing FATES with my spouse as a healer, I'll make an /ac Stone <tt> <wait.3> macro because repeatedly casting Stone is so dull, plus it lets my arthritic hands rest. Not my preference for "real fights", but nice when it's casual.

[Dysvalence]

Maybe it's because I always put the copycrosshotbar command in the first few lines of the macro? Or maybe somehow the non-cross hotbar version works differently? I'm not sure if I understand what you mean by "commit changes" in the context of macros...though that does make me want a Github for macros! ^^

I wanted to use fast input sequences like fighting game combos or NIN mudras, especially for jobs/settings changes, and this meant coordinating where stuff was on different bars to minimize finger movement, so when making changes I was effectively testing all the bars at once. It'd be too easy to accidentally wipe any changes I made if I didn't update the bar I stored it on when switching, so I used to have a separate macro for each bar pairing to save any changes I made before copying the new one in. But this would then make it hard to keep track of overall changes and revert things if I didn't like it, so I had a second layer of backups for all the saved bars that I could revert from, and write to when I liked the changes I had. I doubt I was doing frame perfect inputs fast enough to frequently interrupt a 2-3 line macro without waits in the middle of execution, so I suspect the game was ghosting lines in the middle of saving changes to files on drive storage, though I don't have any hard evidence to actually back this up.

Wasn't fun to maintain this mess even without the reliability issues so now I just use a lot of keybinds and deal with stretches, including adding some duplicates to cut down on finger movement for really important things like vpr weaves.

You might be onto something with having it early in the macro- the one I use to toggle visibility all 10 bars+crossbars and some other UI elements only fails on something in the second half, even if the rest of the macro before and after works fine.

And yeah a macro github would be amazing.

Perhaps it's because I'm on controller and thus don't use mouseover macros that macros have only ever reduced my button bloat?

Maybe, though it could just be that I hate target switching in XIV and want nearly everything on keybinds because I came from older shooter games lol. I doubt the average kb/m user cares about being able to toggle /mountbgm while joining a hunts party, flying through tight spaces, and switching jobs all within 2 seconds.

[LilimoLimomo]

I wanted to use fast input sequences like fighting game combos or NIN mudras, especially for jobs/settings changes, and this meant coordinating where stuff was on different bars to minimize finger movement, so when making changes I was effectively testing all the bars at once. It'd be too easy to accidentally wipe any changes I made if I didn't update the bar I stored it on when switching, so I used to have a separate macro for each bar pairing to save any changes I made before copying the new one in. But this would then make it hard to keep track of overall changes and revert things if I didn't like it, so I had a second layer of backups for all the saved bars that I could revert from, and write to when I liked the changes I had. I doubt I was doing frame perfect inputs fast enough to frequently interrupt a 2-3 line macro without waits in the middle of execution, so I suspect the game was ghosting lines in the middle of saving changes to files on drive storage, though I don't have any hard evidence to actually back this up.

Interesting! What sorts of settings do you save and change when switching jobs via macros? I've never done that kind of thing (I don't have the macro slots to spare XD). I've heard of folks making macros to switch to different HUD loadouts in different contexts, is it that sort of thing?

I generally try to avoid anything that copies multiple crosshotbars (especially trying to swap 2 crosshotbars!) because of the danger of an interrupted macro resulting in the loss of data. So in my combat macros, I generally only copy a single crosshotbar to retrieve a state that I manually setup earlier; I treat crosshotbar 1 (my primary combat hotbar) as a canvas that things only ever paste to, never copy from. The lone exception is that I have a macro that I manually use whenever I update my WVR crosshotbar; it copies my WVR crosshotbars to all the other crafting classes, since they're all the same and I don't do any dynamic hotbar stuff when I'm actually playing them.

Maybe, though it could just be that I hate target switching in XIV and want nearly everything on keybinds because I came from older shooter games lol. I doubt the average kb/m user cares about being able to toggle /mountbgm while joining a hunts party, flying through tight spaces, and switching jobs all within 2 seconds.

In my opinion that's part of what's cool about macros though; they're a way for every person to tailor certain aspects of the game to their needs. It would certainly be nice if the system were more robust, but it's cool to hear about how you're setting up systems to streamline on-demand transitions! ^^

[GrizzlyTank]

Normal abilities queue, macros do not. Therefore macros will always be inferior.

[LilimoLimomo]

Normal abilities queue, macros do not. Therefore macros will always be inferior.

Macros queue if you write them to queue. All the details of how that works are in the first post.