Will the recent PTR patch that breaks the auto-Interrupt script affect GSE?

Here’s the patch notes in question. I’m nervous that as a consequence of breaking the macro-scripts that were plaguing PVP, that blizzard might have also broken GSE.

Does this also mean that [group][nogroup][raid] etc no longer do anything?

    • Macros can no longer conditionally execute commands based on your party state.
    • Macros can no longer change equipment using /script, /run, or the Lua API. Equipment can still be changed using regular macro commands such as /equip.
    • Technical notes:
      • UI Macros have been restricted in a few ways. The general issue was there were several exploits to conditionally execute macro commands. These exploits tended to use un-restricted Lua API functions that happened to mutate states that various macro options/conditionals queried, or selectively register the globally available MacroEditBox for the event that would run commands
      • To address the state mutation, two methods were employed:
        • Converting APIs like PickupInventoryItem to be restricted when trying to change gear during combat.
        • Caching the state queried by the macro conditional when combat starts so that the state remains invariant while combat is in progress. Macro options that check party membership and composition uses the cached state approach.
      • To address selective event registration the MacroEditBox was removed from the global namespace and the event was replaced with a callback.

As GSE uses Macro commands in combat not API commands this has no impact.

This is essentially a status quo situation for GSE as it cannot change a macro in combat. You would possibly need to use Function variables in GSE to replicate things like [party] but these are all evaluated outside combat so are not affected by the combat lockdown.

Phew, that’s a relief! I don’t do the “1-button-macro” thing, but the QoL GSE provides is immeasurable.

Thanks for the quick response, hope you’re doing well and thanks a ton for making GSE!

So things like this will still work for If statements for running a block? correct

if GetSpellCooldown(391888) == 1 then
return true
return false

but maybe not the /click Macroname to run outside macro as a variable?

That function will work BUT it’s never going to do what you wanted. It’s only evaluated OUtSIDE combat. It’s never going to check if your spell is on cool-down in combat.

IFs are not dynamic. They are checked and a macro is created. Once combat starts that’s macro is set in stone and does not change until combat ends. You need to think of ifs for things like “am I this race?” Or “am I targetting boss x while waiting for the pull” or “am I in this covenant” or “who gave the top dps on the last pull”

/click macroname still works from what I can see.

Thanks, yes I was trying to get that to work and only works on what was there prior to combat starting. I was adventuring into different LUA commands but stopped trying.

I use outside macros for targeting in dungeons, use Targetrole to edit macro in groups. Would love to see that added to GSE for Tank or Healer targeting in macros!.

thanks for the reply!

It already exists - you just need to write the variable. You can also do things like boss specific changes via variables.

Eg to get a tank:

A function to find the first tank in the group - hint Augment Evokers you can use this for your tank target. This may need some refining and tweaking - its more POC.

/cast [~~TANK~~] Blistering Scales

 if GetNumGroupMembers() < 1 then
   return "@player"
 local prefix = IsInRaid() and "raid" or "party" 
 for k=1, GetNumGroupMembers() do
   local unit = prefix..tostring(k)
   if UnitGroupRolesAssigned(unit) == "TANK" then
     return "@" .. unit

works like a charm, will be nice for using on healers also etc
Aug evoker macros should be lined with this for auto targeting!
i need to login more so i actually see replys!