Evidence that Macros Do NOT Cause GCD Delay or Lost Casts

[Iscah]

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.

[LilimoLimomo]

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.

[Shurrikhan]

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.

[LilimoLimomo]

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.

[Shurrikhan]

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.

[LilimoLimomo]

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

[Shurrikhan]

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.

That's why I mentioned the first actionable/possible action. Wrong target type (between PM/friendly/nonfriendly)? Target dead? Target out of range? It'd then check the next action macroed and use the highest of that list. Note that even regular actions do this, such that the range we can pull off an action from can be well above our actual "maximum range", given sufficient difference in position between when the action was checked and when it appeared to go off.

And again, the idea is simply to strike a balance between what behavior the devs want to forbid (e.g., auto-play or PvE combo consolidation... beyond the ones they already consolidated) and what they allow, un-neutering just whatever seems to be the intended uses of macros.

Yes, we can already use a Dia/Regen macro to make it so the button is of use regardless of target type, but we sacrifice queuing to do so. Given that we CAN do that through the macro with just a bit more timing or button-mashing, though, it seems well enough intended to be functional that the devs may as well let that be queued.

On the other hand, something like a <wait> macro using decimal seconds or %GCDs is not at all decently possible, while combo-in-1-button macros rely on the clunkiest of gimmicks and disused hotbars to draw from. As such, they seem wholly unintended, and so I wouldn't bother asking for what all would be necessary to make them function properly.