🟢 How does GSE currently work
A clear and concise description of what currently happens. Eg. Every time you go to do x you need to perform the following [...]

🟢 Describe the solution you'd like
A clear and concise description of what you want to happen instead of what currently occurs.

🟢 Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

🟢 Additional context
Add any other context or screenshots about the feature request here.

In GSE3, Pause blocks have a drop down of what type of thing they are. There is a “Clicks” option instead of MS where you can say pause for 5 clicks. GSE3 has a lot of Quality of Life changes to make things like pauses a lot simpler.

The executable macro is available as a table _G[“MACRONAME”] In lua you can reference the executable of each block via _G[“MACRONAME”][index] where index is the step number of the compiled block. Note this index can be different to the order in the GSE editor especially if you are using loops or if blocks and is only viewable from the Compile Template screen. (This is you actual macro as opposed to the template you are editing.). You can get the current step via _G[“MACRONAME”].GetAttribute(‘step’)

Hi Woodgray, any chance you can answer the 4 dot points or provide a bit more context? Visualise pauses how?

Pause blocks can be useful in a strait macro (one target) step by step. Even then because of all the factors in pause block variables especially m/sec conversion and normal block steps, they can get very complicated. This multiplies with more then one pause block and really gets complicated with multi targets. (I am trying to keep this as generic as possible.) So a pause block indicator with (macro/block/timer of some sort) would really help. I realize this would be a lot of clutter. So that's why I said visualizer

That is understood. Multi target is a perceptual take. While GSE is a convenience it does not cover all the needs of game play but, it sometimes can make it a bit more complicated.
Take:
Target 1
Block /cast xyz
Pause block wait 123
Block Do something maybe
Switch to target 2
Block /cast xyz
Pause block wait 123
Block Do something maybe
Switch to target 3
Block /cast xyz
Pause block wait 123
Block Do something maybe
It is understood the counters are interdependent and don't communicate
From a game play perspective all you can do is guess if you need to go back and reapply. Reapply does not get rid of the original counter for that target all it does add an additional counter if you did it to soon.
So, a mechanism to show when the counter(s) have expired would be helpful. It is not a given that you will try to use a counter as a absolute cast timer. I do not know if you can use the spell applied to a target and then the counter used in the sequence as any form of indicator

So assuming you cant guarantee a given number of clicks on multiple different sequences of different block counts. Is there a pad mechanism that works?
WeakAura OK, so if I have say 3 pause blocks (Maybe for gcd) in the same macro how does that work. I see it ok if they are /click block macros. Though you would need some way to keep up with that. I suppose weakauras could read the macro list and parse it for you macros if you prefigured them in a certain way

The problem arises when you have multiple targets that are not aoe targets. Even aoe targets can be a problem as new ones are drawn in by what ever tanking mechanism being used. Weak Auras as a visual guide for GSE macros seems to handle most of it except for the click exceptions you noted before. Reset after combat would handle most of the rest. I am not sure about target death.
So, that leads back to the click mechanism. I understand the padding argument. If you created a block or variable that has /cast null as the only predicate would that be able to help smooth out click sequence as test used by the sequence author. Can you have a per-sequance test, method or calibrate function based on the millisecond repeat (described in your video) that is used. (trying not involve any automated key function used). The test would only show base synchronization not the changes made because of any /cast usage. Ideally you could use it on the entire macro but that would be impossibly complicated and maybe to much like automation.

Hi is there a way to PM?

Based on TWW changes - closing this out.

There is now an event that is being sent to WA see #1504