Basically M6 macros seem to work in ABP, but the icon is missing ("green box"). Example:

If you are not familiar with M6, it is by the same author as OPie and uses the same macro "engine". It's basically OPie without the rings, allowing you to use the engine with normal action buttons.

As for the icon info, it can be of two different types:

With explicit icon info

Automatically

Any M6 macro that is active generates a macro "stub" in the standard Blizz macro interface. Example:

Having full support for M6 would be absolutely great, as 90% of my macros are M6 macros ;)

Thanks for the details. This is great. I will take a look and thanks for using ActionbarPlus.

Just from initial investigation, it appears that M6 is the one that is changing the icon to these "blank" ones. The GetMacroInfo() API is returning the blank icon 1074161826.

When the icon is changed through the M6 UI, two events occur also

• an event to update the placeholder macro with the new icon
• another update to reset the icon back to the blank icon 1074161826.

This is fairly strange behavior in M6. I will see if I can compensate in the ActionbarPlus handling of macro events.

I just implemented a preliminary solution. I will play around with it some more and soak on the changes.

There's just one quirky when changing icons because ActionbarPlus doesn't know about the icon change until the following happens:

• Starting a drag and drop action from M6 will also force this UPDATE_MACROS event

Also, ActionbarPlus still has issues receiving macro events with dynamic macros (with sequential spells). If you have one of these macros, i.e. castsequence, the icons won't change. This behavior seems to be a blizzard internal code and I am not able to see how the blizz actionbar does this.

I will take a look

Glad to hear that!

I used to use ABP some time ago, but I dropped it in the end. Today I saw it again while browsing CurseForge and couldn't remember why I stopped using it. Well, after dragging the first macro onto a bar, I remembered ;)

But this time I thought, let's see if he's interested in adding compatibility, and it seems it was a good thought :)

it appears that M6 is the one that is changing the icon to these "blank" ones

Hm, on Blizz action bars, I never had blank (green) M6 icons. Maybe it does that because the icon info gets pulled afterwards via the #showtooltip in the stub macro? But actually I don't have much idea about the macro API (beyond what is needed to write macros)...

There may be some glitches in the current version of M6, as they released a pretty significant update this week (preprocessing macros and recognizing if a spell is known). As a result, I sometimes get the question mark icon after creating a new macro (with known spells), but this usually normalizes either after a few clicks or saving a second time.
Probably not related, but who knows.

I will let you know when they release another update.

Thanks again for looking into that, really appreciated!

For the ActionbarPlus macro issues
There is an event for macros that seems to be only known to the actionbars. If I drag a macro that contains a castsequence to ActionbarPlus slot, the icon doesn't change (no spell events are received). If I drag that same macro to an actionbar, the spell events starts firing and the icons are updated on actionbarplus action slot. I'm SMH and I need to get back in figuring it out.

I'm actually starting to use M6 now. Cool addon 👍 .
I will push to a branch shortly

https://github.com/kapresoft/wow-addon-actionbar-plus/compare/m6-256?expand=1

I tried the new MacroEventsHandler.lua, and it seems to work fine. Only tested very briefly, but the macro icon is there and the macro works!

🥰

I'm actually starting to use M6 now. Cool addon

Yes, IMO, the best macro interpretation by a huge margin. Couldn't play without it ;)

I just pushed a release. 2023.4.6
https://www.curseforge.com/wow/addons/actionbarplus/files/4492328

Thank you!

I will try and spend some time and resolve those macro event issues.

Thanks to you!

Hi There, Some good news: I found the solution to the macro castsequence issue not updating the icon.

The icon via GetMacroSpell() & GetSpellInfo() does not contain an updated spell info. I have to call GetMacroInfo() instead.

I will release in a couple days or so. I'll tag you on the issue of you don't mind.

Cheers,

This sounds like it could solve also the issues with Select.

The flyouts are working with ABP, you can also select or use an item from the flyout, but the main icon doesn't get updated.

I just glanced at the Select addon seems like an addon I would use 😆.

/select Battle Shout, Commanding Shout

Hi There,

I'll put priority on this and the macro issues. It'll be interesting to look at the Select addon for sure.
If I create an issue for tracking, I'll just reference this thread.

Cheers,

Interesting: Today I get the question mark icon as main icon of a Select macro on an ABP bar:

Yesterday, the main icon showed one of the flyout items, although not updated correctly when changing the selection, but it was there. No environmental changes I'm aware of, except new game client session and a new day.

(I know, the Select issue is probably OT, just mentioning it because I thought it may be related to the icon-not-updating-with-castsequence thingy. If it persists through your next release, I'll open another ticket.)

OK, while writing this and tabbing back to the game, the icon came back:

So, the question mark might have been "normal", as I remember to have seen it also with simple item buttons on ABP after login.

[…] Select addon seems like an addon I would use 😆.

Did you think I would use pointless or crappy addons? 🥹

/select type:drink,type:food

BTW, as you mentioned that you would going to use also the M6 addon, don't forget to check the docs: Additional Commands, Extended Conditionals, and —especially— Flags.

[edit:] Added an emoticon to line 3 to make the implicit more explicit.

Back to M6:

With the new ABP version, the example from the OP now shows the correct icon, but the labels are still missing:

Also the tooltip does not show the label (it just shows the macro text from the stub, e.g. _M6+s07)

The label is constructed with #label <labeltext> in M6. See the screenshot in the first spoiler of the OP.

The labels are not super-hyper-important, but, as you can see in the example, they can be pretty helpful to identify the content of the macros. (In this case they set the posting quantity in Auctionator to a predefined number.)

I noticed the same last night and I created an epic story to track (#258). Thanks.

Getting this error now:

208x ...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:93: attempt to compare nil with number
[string "@ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua"]:93: in function <...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:85>
[string "@ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua"]:133: in function <...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:101>
[string "@ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua"]:175: in function <...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:171>
[string "@ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua"]:191: in function <...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:182>

I first saw this error when I removed the #label … from an M6 macro, in order to see if ABP displays the macro name as fallback.

But then I noticed that I get the error each time I open the M6 GUI.

Correction: Got it also directly after a reload (with the M6 #label … back in place).

Getting this error now:

208x ...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:93: attempt to compare nil with number
[string "@ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua"]:93: in function <...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:85>
[string "@ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua"]:133: in function <...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:101>
[string "@ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua"]:175: in function <...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:171>
[string "@ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua"]:191: in function <...ActionbarPlus/Core/Lib/Widget/MacroEventsHandler.lua:182>

I first saw this error when I removed the #label … from an M6 macro, in order to see if ABP displays the macro name as fallback.

But then I noticed that I get the error each time I open the M6 GUI.

Correction: Got it also directly after a reload (with the M6 #label … back in place).

Hi There,

This is fixed in 2023.4.7

By the way, and just a heads up, since you said you'd be using one or both of the addons mentioned (M6, Select):

I have found that having M6 and Select installed causes severe interference, i.e. frame rate stuttering.

The problem seems to have arisen with one of the patches after 10.0 and the changes it forced on many addons. In this case, the cvar that determines whether you cast on keydown or keyup.

M6 changes this cvar with every macro execution (and resets it afterwards). Select reacts to this cvar change by performing CPU-intensive actions that aren't meant to be executed frequently.

This can be efficiently fixed by modifying Select to filter out events that are not registered in the CVarCallbackRegistry (see M6/Libs/ActionBook/Ten.lua, line 6).

But: also any macro edit (which happens automatically, e.g. on every zone change, due to M6's zone conditionals) triggers Select to do its macro-update payload. The only way out of this cycle is to add timers and lockouts to Select, which works – somehow –, but in the end I decided to drop Select.

I've sent the info above to both authors.

M6 changes this cvar with every macro execution (and resets it afterwards). Select reacts to this cvar change by performing CPU-intensive actions that aren't meant to be executed frequently.

It does the same with the icons :-). It puzzled me, but I was able to hook into that change logic easily.

The problem seems to have arisen with one of the patches after 10.0 and the changes it forced on many addons. In this case, the cvar that determines whether you cast on keydown or keyup.

I am totally not a big fan of this change. I think it had to do with the new dragonflight "press for intensity" action button feature. It was a pain and I'm not sure ABP even works right if it's "key-up".

For performance for ABP, I need to run through and optimize some things. It has a high mem and high CPU reported by the "Addon Usage" addon when my character is in a big city. ABP goes garbage collection just fine though.

It has a high mem and high CPU reported by the "Addon Usage" addon when my character is in a big city

The first time I used your addon (a few months ago) I was also shocked by this. But then I learned that addons that are first in the alphabet tend to get blamed for memory and CPU usage of the AceLibs they contain, which should actually be distributed to all addons.

In case you haven't, download and install the Ace Library separately and activate it in your addon manager. This should save some addons from being falsely accused, ABP being one of them:

CPU

Memory

The samples are a bit bad, because they were taken without much action, spellcasting, moving etc. But the general picture is OK. ABP goes a bit higher when really doing some fighting or such, but not that much.

Thanks. This is very helpful.