Evidence that Macros Do NOT Cause GCD Delay or Lost Casts

Quote:

---

Originally Posted by Mikey_R

Benefits of one does not mean it is a con for the other.

---

When there are only two options, as in this case -- effectively, [A] or [Not-A] -- yes, they do. That is exactly what they mean.

Quote:

---

Originally Posted by LilimoLimomo

Did you happen to test whether FPS affects the queue window for non-macro actions? My assumption would be that normal actions will not be affected by FPS, but I'd rather have data if anyone can conjure it.

---

It's .5 seconds prior to GCD refresh. Latency may be involved - lag compensation in this game has changed a couple times - but FPS isn't.

Also, to reiterate my stance:

1) I would caution anyone to be heavily skeptical of any claims about macros using deliberate frame timing unless they come with a hefty disclaimer about being absolutely 100% certain you can maintain a perfectly consistent FPS. (And, well... for most players, I wish you good luck with that. You're gonna need it.)

2) I still don't believe we have enough data to claim that there is *no* GCD delay or loss of casts until there's data from high latency tests. I have an idea for how to do it myself, but it's gonna be ramshackle as hell and I haven't got around to it yet.

Quote:

---

Originally Posted by LilimoLimomo

I want to encourage you to take a step back and consider the alternative: nobody should promote non-macro actions unless someone has a genuine need for it.

---

There's a key difference between advocating for macros and advocating for normal actions: only one of those options is how the game was designed to be played.

Quote:

---

Originally Posted by Iscah

There's a key difference between advocating for macros and advocating for normal actions: only one of those options is how the game was designed to be played.

---

You have it backwards: players wouldn't be able to use macros if the game wasn't explicitly designed to be able to be played with them. They aren't an accident, the devs added them on purpose, so players could use them.

Quote:

---

Originally Posted by LilimoLimomo

You have it backwards: players wouldn't be able to use macros if the game wasn't explicitly designed to be able to be played with them. They aren't an accident, the devs added them on purpose, so players could use them.

---

Though they also seemingly went out of their way to limit them, as certain constraints were added since the rerelease Beta, iirc, and comparable macro systems in other MMOs are not thus restricted. /shrug

For my part, macros seem good for cross-target functionality, allowing a single button to be useful both for clicking on allies and enemies. You give up some queuing leniency for it, but w/e.

More complex functions, though, seem to tend to break down or require an inordinate amount of gimmicking and hotbar space. Which is a bit sad. I feel like the game could simultaneously manage more difficulty and accessibility if it further fleshed out its means of linking buttons to actions in player-customizable --and thereby potentially far more intuitive and efficient-- ways.

Quote:

---

Originally Posted by Shurrikhan

More complex functions, though, seem to tend to break down or require an inordinate amount of gimmicking and hotbar space. Which is a bit sad. I feel like the game could simultaneously manage more difficulty and accessibility if it further fleshed out its means of linking buttons to actions in player-customizable --and thereby potentially far more intuitive and efficient-- ways.

---

Yeah, I presume it's similar to the reason they don't allow add-ons: they want players to be able to do certain things but not other things, so they designed a macro system that had different capabilities than some other games. It's certainly double-edged, and I wouldn't say no to more capabilities, especially if they helped with accessibility. But given that we've got the macro system we've got, the best we can do is to help educate people about it's capabilities, since it's in many ways unintuitive.

The hotbar gimmicking/space is certainly a cost of certain macros (generally my favorite macros), so I'm going to edit my main post to explicitly mention that.

Quote:

---

Originally Posted by Sindele

It's .5 seconds prior to GCD refresh. Latency may be involved - lag compensation in this game has changed a couple times - but FPS isn't.

---

Thanks!

Quote:

---

Originally Posted by Sindele

I still don't believe we have enough data to claim that there is *no* GCD delay or loss of casts until there's data from high latency tests.

---

This is a good point; rather than saying that we've proved it absolutely isn't a thing, it would be more accurate to say that "at present there isn't any evidence to suggest that macros result in GCD delay or lost casts". I'll adjust my main post to use that language.

Quote:

---

Originally Posted by LilimoLimomo

Yeah, I presume it's similar to the reason they don't allow add-ons: they want players to be able to do certain things but not other things, so they designed a macro system that had different capabilities than some other games. It's certainly double-edged, and I wouldn't say no to more capabilities, especially if they helped with accessibility. But given that we've got the macro system we've got, the best we can do is to help educate people about it's capabilities, since it's in many ways unintuitive.

---

It just seems to me that there's a much more useful balance, is all. If they immediately checked through each action in series (top to bottom) up to the point where one is actionable per its parameters and queued just that first one, we'd be able to essentially have a UImouseover-ally, UImousover-enemy, field-mouseover-enemy, field-mouseover-ally, target-enemy, target-ally, and, say, a range check and movement check option for each action, if we so pleased, we could still queue even without need separate buttons for the likes of Aetherial Manipulation, Ruin II, Aetherflow (as the subsequent actions are only possible with AF stacks available, so you could just attach Aetherflow in the same macro as them, lower than the desired action), Piercing Talon, Ogi Namikiri, and so forth, and healers, for instance, could have their instant cast GCD button, for instance, be Regen on an ally and Dia on an enemy, saving further space that way if they so please. Etc, etc.

Quote:

---

Originally Posted by Shurrikhan

It just seems to me that there's a much more useful balance, is all. If they immediately checked through each action in series (top to bottom) up to the point where one is actionable per its parameters and queued just that first one, we'd be able to essentially have a UImouseover-ally, UImousover-enemy, field-mouseover-enemy, field-mouseover-ally, target-enemy, target-ally, and, say, a range check and movement check option for each action, if we so pleased, we could still queue even without need separate buttons for the likes of Aetherial Manipulation, Ruin II, Aetherflow (as the subsequent actions are only possible with AF stacks available, so you could just attach Aetherflow in the same macro as them, lower than the desired action), Piercing Talon, Ogi Namikiri, and so forth, and healers, for instance, could have their instant cast GCD button, for instance, be Regen on an ally and Dia on an enemy, saving further space that way if they so please. Etc, etc.

---

I like the idea of a macro system that can intelligently queue, but I don't think a macro system that only queues one action would truly solve this issue, because there would be cases where actions that are available when the queuing started are no longer available when the player is ready to cast an action, and vice versa. Because in the time between queuing an action and it going off:

• My position can change, making a skill require 3 yalms either castable or not castable relative to a skill requiring 15 yalms. This could change due to player movement, knockback/pull-in effects, or Rescue.
• My ability to perform actions might change. For example, I could become Silenced, making my prioritized spell no longer castable, but my second-place skill would be.
• A status like Slow could even change when my GCD becomes available, which could in turn change whether an ability I have on cooldown would be available to cast at that time.

These edge cases have the potential to make the system feel clunky when unexpected things happen quickly.

Instead, I would suggest a small alteration to your idea: that the macro system queue the entire list of prioritized actions. Maybe that means that there's a cap to the number of actions that can be queued in this way to prevent 15 different actions from being attempted for the whole queue window? But that would at least mean that the first action to genuinely have all of its activation criteria met would be the one that gets used, which is probably what the player wants.

While we don't have that system, it's probably worth stating that we have a lesser version of it, and it can perform some of the things you've mentioned, just not with the same level of polish. On my PS5, I use the SMN version of the following macro and it works great for me without clipping any GCD's:

/macroicon "Ruin II"
/macroerror off
/ac "Ruin II"
/ac "Ruin II"
/ac "Ruin II"
/ac "Ruin II"
/ac "Ruin II"
/ac "Ruin II"
/ac "Ruin II"
/ac "Energy Drain"
/ac "Aetherflow"

Pressing this makes it so Ruin II is cast if GCD is available, but if not then it'll do Energy Drain if you have Aetherflow charges, otherwise it will cast Aetherflow. The repeated Ruin II lines not only act as a "queue" for Ruin II, but also for the other oGCD's as well. Technically there's a downside where Energy Drain and Aetherflow will always be "queued" for all of the Ruin II frames, and thus they will always have a short cast delay, but I've found that this doesn't matter at all for single-weaves, and depending on when you press buttons and your framerate you might be able to get it working for double-weaves. I'd recommend giving it a shot, probably adding more Ruin II or removing them to see if you can get it to line up with your preferences.

You can technically make a macro that does either Regen or Dia depending on whether you're targeting an ally or not, it's just going to cost you a single frame roughly half the time. It's up to you whether that's worth the cost. Something like this:

Edit: As Frizze pointed out, the below macro does not work because healing spells cast on yourself if an enemy is targeted.

/macroicon "Regen"
/macroerror off
/ac "Regen"
/ac "Dia"
/ac "Regen"
/ac "Dia"
/ac "Regen"
/ac "Dia"
/ac "Regen"
/ac "Dia"
/ac "Regen"
/ac "Dia"
/ac "Regen"
/ac "Dia"
/ac "Regen"

(I can't tell whether you meant that you already use a macro like this earlier, so forgive me if I'm telling you something you already know!)

Preliminary waitless lag testing complete, again using the "micon-error off-13x blizzard" macro. Not super comprehensive, but when I'm seeing no measurable additional delay over the standard queue in my initial simple worst-case test - 36fps @ >600ms (+270ms delay added to both sending + receiving packets) - I don't think there's a lot of merit to turning more dials for the sake of more complete but non-illuminatory data.

I'm mildly surprised, but I shouldn't be in retrospect - I already know the server gives the client an excessively long leash with what it considers valid with regards to ability casts and the GCD from the tools and exploits that exist in the wild.

That said, this is still only passing a basic "not actively detrimental when used as a 1:1 button replacement" test. My other concerns with more convoluted macros remain, as well as the dilemmas that can't be solved with data alone like the negative interactions with slidecasting and the fact that any double presses/mashing will bite you. Used correctly, you aren't likely to lose casts or suffer a GCD delay... but "used correctly" is a phrase doing some extremely heavy lifting there.

For the curious, potential vectors for continued investigation and/or slack methodology issues:
- are waits affected differently? logically this seems very unlikely given that everything else in macro resolution is handled clientside, but...
- i'm timestamping on chat message receipt (to pick up both /echo and casts in the battle log) - sniffing packets directly would be more precise but more tedious
- not a "real" lag scenario, but i'm confident that it was behaving reasonably accurate to lag in the wild. someone with more time could probably get a more accurate real-world test by running from NA on OCE