Why is your addon the most downloaded?
It makes me doubt. (It's easy to increase your downloads.)

The point of this comment is that their addon doesn't do the simple thing.
#showtooltip. It does not work in your addon.
It only shows the current icon of the ability that has taken that reference, no matter how much that "macro" has other abilities with modifiers, it will never be shown.

Instead of leaving the "?" with the question mark and depending on which modifier is pressed, the icon will vary. In its complement it cannot be done, because the icon takes it statically.

With the #showtooltip just leaving the "?" icon already interprets what ability it will be when a modifier is pressed.

If you put more than one skill in your macro, only the one that "is the first to detect" will be shown and it will be static.

Something so simple ... It would also be nice to increase the size of the editor.

If for this I have to put images, they make it clear to me that they do not know the game and I already know where the downloads come from, so I already know which addon I will have to download.

We are not understanding each other. You tell me not to listen to you and I tell you that there is a solution. You tell me that blizzard has blocked this.

Well, I have done tests "in-game" without touching the code:
I can say:
#Important.
1 - The icon changes in combat (without modifiers), this gives me the solution to "your big" problem
2 - There is a way to do it

I do not know if it is that part of the code that you show that makes the spell not change.

I do not know whether to tell you what steps I take, if you are going to think that I do not listen to you and you are going to continue in your line, I think that I will not even have to fork the project. Your toy your problems.

I would record a video, so you can see that in combat and out of combat they work, but we would be in the same, you would not listen to me.

You know, there really is a solution. You have a bad approach, because you are only seeing the "This function is explicitly blocked within the Macro sandbox".

At this point, "it would be recommended that I help you or contribute how to do it." But you would repeat me with links and documentation that it is blocked. (It's easy to patch something with a different approach)

• You see that there is a blockage from the envirorment.
• I see in "in-game" that it can be changed in combat / non-combat (the icon), and this gives me the solution to the problem. In other words, I know where it eradicates the problem (I would only have to see how to apply the logic in the code).

If you only see what the code shows without testing it yourself, I have nothing more to say. Good luck. You keep thinking it's blocked by Blizzard.

The important thing is that you believe that I am wrong. I'll be happy to think about it. When someone on your team solves this, you will think of me. I have seldom been wrong. Time will prove me right.

It's better that way. I do not like people who do not listen to reasons and this denotes a bad omen. Good luck with the project and I hope you find the right one and by the way, it is not difficult to solve it.

I upload the gif so you can see that I am not bluffing (I see your argument). I always go with a royal flush and you?

URL GIF :)

There has to be some way.

I am aware of some of the blizzard restrictions, for example the one you mention "castspellbyid".

With "castspellbyid", 3 years ago it could be solved with:
(in game)
For these cases if I remember correctly, I use a variable "script" and then call it. There should be no problem.
(Out of the game)
Surely there is some API that helps the LUA plugin return it, or if not, build an API with references from all the skills (it's long, I know).

I also realized some time ago that if more than 255 characters are exceeded, then the icon is not displayed. That is, it does the same operation as GSE.
However I saw that there was an addon called "Mega macro" that you could write many more lines 1023, and it works correctly.

If I have time, in a few weeks, I'll fork your repository. I'll see if with the code I can save macros outside of the WOW macro manager by default. Contal to make the macro dynamic.

This isn't a bug. It's a limitation on what can be done within the confines of what WoW allows. Also bear in mind that you need to put each "action" in its own box. When you hit "Compiled Template" this will show you the exact macro that is being sent to wow. If you have all the abilities in one box, only the first one found will be processed by WoW.

I felt nice and have been looking at the code for 1h.
First, I don't know where you started the structure, who helped you or what guide you got, but the events section, the most important thing is wrong, I don't care if you like it or not, I'm just telling you the truth. I understand that this is where all your code is based and I know that you are going to "fight" to say that it is correct or that you got it from even the best engineer at Blizzard. It is wrong and this is a "fact".

We are going to shed some light after this hour.

The main problem is why the icons do not change with the modifiers "Shift, Alt, Ctrl" (Current by Blizzard). At this point we are not talking about combat yet. (But as you saw in my gif, it can be changed in combat, even if it is blocked, because we are making a new request, not treating the current one in combat time).

The problem comes from above where you tell me.

We are going by points, we are going to try to specify with the greatest precision. forgive the redundancy.

The first point where your code is based and where it eradicates the vast majority of the problem.
function GSE: ProcessOOCQueue ()

The function of this type (update icon), should not go in a process of type queue first point.
What the function does is queue the data (UpdateSequence, Save, Replace or add, openviewer, CheckMacroCreated, MergeSequence, FinishReload). It's crazy to have all of this in one main process.
Because you have a loop of type queue, which what it does is fetch the queued elements, but this loop in turn is inside the GSE in a main process / thread: ProcessOOCQueue
"for k, v in ipairs (GSE.OOCQueue) do"

This apparently works thanks to the "GSE.OOCQueue [k] = nil" which is the one that frees the memory. Otherwise, it would destroy the ram memory.

You can try to comment

• GSE.OOCQueue [k] = nil
  and you will see that if it changes with the modifiers.
  

If you comment "GSE.OOCQueue [k] = nil", you will see how the modifiers work and you will see the icons of the abilities change in real time (this point is no longer a limitation of Blizzard but a bad start of GSE), but as we said you will fill the memory to an exponential loop. If you remember the algorithmic complexity is going to be exponential to infinity. Making your ram memory crash, we could call it stackoverflow.

At this point there are 2 options.
1 - The first and least recommended is to put that every time the user presses a key type "Shift, Alt, Ctrl" the code is executed with this commented GSE.OOCQueue [k] = nil.

I did, but like I said there is still overflow. I deleted the code because logically it did not have rational logic and otherwise it did not work as expected. But it was like this:

Don't try it, I already tried it. If you hold down the "shift" key, the loop will always run, because it is inside a loop (GSE: ProcessOOCQueue) and the ram will collapse in no time.

I have tried to do this step and also put a conditional on it so that it only executes "1" time, but I have seen things that I did not like. It is better to take it out of the main thread.

2 - You have to redo the initial structure to make it more robust and especially outside the main thread, so that the code for that function is called when the user presses a modifier type key and not always. The most important thing is that you only call once. It is the most recommended.

3 - You can ignore the message and continue with your toy.

4 - You can tell me that it is not possible. (Although we both know that is not true).

The 3 seems quite appetizing.

I've tried it with debugging and using keys (step 1) and it looks good, but it has to go outside the ProcessOOCQueue / thread loop.

Otherwise, that's what I was telling you. Everything is encapsulated "1" time and will not be called again, until the screen is reloaded, the icon is clicked (without modifiers) ... Many problems.

If you're wondering why I didn't do it, that's why you'd have to do step 2 - redo the entire complement of the initial event. It is one thing to fix something that is not working and the other is to redo a plugin/addon.

If you want an example you can look at M6.
In case you do not know where to look in M6, I am already ahead of you.
In the Repaint.Lua file, look at the functions:

• variable with listeners: queueSingle (important Only 1 time).
• function: updateOne
• function: skipNonIconUpdates
• function: handleQueue
• ...

It will give you an idea.
If you try, good luck remaking the addon.

The choice is yours.

As a reminder.
It is not always pleasant to accept reality and it is important to always listen :)

Just now that I have time and it's "Saturday" I was going to play or take advantage of my free time, with hobbies (no, I don't play golf) at WoW.

I thought you had already fixed it... but it seems that you chose the best option, option 3. Congratulations, I guess your working life has to go to 120.47%, in that case I understand. Hey don't blame me for having time and being sarcastic! I have earned it.

By the way, something I didn't tell you about the queue. You do too many inserts in the table. (I guess it's because of the old and new versions of GSE and performance inserts... as well as action) But having it this way doesn't seem very recommendable. What do you think? Does your Addon work well?

I seem to recall that when it got to the loop there were too many inserts, where there were some nulls. But it's wrong anyway. Check the inserts you make. (Inserts should not be stacked like this.) I'm not saying that the inserts are wrong, I'm saying that the logic in which they are called is not. When you get to the thread, the queue has 15 insert entries. You make it work 15 - 30 or n times every second, when it would actually have to process "1" when pressed. If you don't believe me: use table.getn(GSE.OOCQueue) and check it out. You have to pay more attention to the people who commit the project ;) and review it well.

While writing this and turning on WoW to play a BG, I've been looking at the code. Why? I'm curious.
Check the Options.lua and Storage file. You do too many inserts. when really only one would have to be sent when the user clicked on a key.
Maybe if you fix the inserts "it can work as a preventive patch". But I prefer a good Band-Aid. Like I said "(I'm guessing it's because of the old and new versions of GSE and performance inserts...plus action)". You should have version control and not try to take old features and mix them with the new, because in the end everything blows up. Therefore, the best option is what I told you in "step 2". But I'm not going to lie to you, step 3 is my favorite.

Finally look at LDBProvider where you call prepareTooltipOOCLine I recommend you look at it. At first it doesn't seem to work. It may be called from another external or when you do an action (which I currently don't know about) then it may work.

I hope that one of your colleagues will help you and fix it, I'm sure he has more experience than me. I'm a newbie ;) (you can use this argument in your favor).

Forgive my English as I forgive... too many things.

I'd be happy to help you as you were too nice to me, but you're not going to believe it... seriously, not to make excuses, but I'm just typing this and it just went off... don't you hear that? "It's the sound that the BG starts." For the horde!

A couple of notes.

The OOCQueue is a series of events that can only be achieved outside of combat. A GSE macro creates a 1px button and a macro stub. The macro stub clicks the 1px button which has a series of commands attached to it per click. The commands on this button can only be changed outside of combat hence the if not InCombatLockdown().

By commenting this out when you then start combat and save a macro you will get a big massive crash. GSE.OOCUpdateSequence performs this update. This is placed in a queue that checks that you are not in combat and leaves it in the queue if you are to perform later. Now when have created that macro stub and initial button, the initial icon is a ?. An initial call to initialise the icon happens here. After that while in combat the same GSE.UpdateIcon() method is called IN COMBAT each click. Each click of a GSE macro contains all the functionality of an entire wow macro. The update icon looks at the macro code for this step and from that extrapolates what the icon will be. At the end of combat, there is a process that resets the macro to the initial state (if that macro has been configured to do so) which also resets the icon.

I have read through what you have and while it may allow the showtooltip to work outside of combat it breaks the incombat functionality (which is the point of this mod) and causes things to crash. M6 is nice but it cant do its fancy stuff INCOMBAT which is where GSE operates.

The LDB code you referenced works exactly as its designed to - its called by any UI mod that handles LibDataBroker data feeds (Elvui, titan Bar etc). The tooltip is also attached to the minimap icon if you have that visible. This isn't a macro tooltip but a tooltip relating to how GSE is running as a whole when you hover over the GSE LDB text feed or minimap icon.

I have the mythical question. Has this been solved at least?

I have the mythical question. Has this been solved at least?

Yes There is no icon on the toolbar to update anymore so #showtooltip is completely irrelevant for GSE.

Perfect👍, I'll try it when I have time.

Now that I think about it, that wouldn't be the expected result right?

If I'm in form and I want to cast something out of form I would have to press shift and the other skills would appear. Is it like this or do you really just rely on what wow gives you?
If it's the second way, I think it's not fixed then.

I'm not saying to change form and have the skills change.
I'm saying to change the skills without changing yourself.
There's a big difference.

You don’t get it - GSE doesn’t use the actionbar there is no relationship between what’s on your bar and what GsE is doing,

It seems that we will be entering the same cat and mouse game again about me not understanding it. I have never seen someone so stubborn, honestly. Here is someone who from the beginning said that I did not understand anything. Clearly there is something wrong with one of the two.

Let's see, if the macro is created with GSE and I drag it to the toolbar and it does not have the expected effect... is it wow's fault?
But if you create the normal macro without GSE, then it works.
Whose fault is it?

Just because you don't pay attention to the #showtooltip doesn't mean that it is not used. That is the first point, besides, if you don't consider it that is another point. Not your addon's. Your addon used to do something, now I don't know what it does.

I simply asked you if it had been solved, but I see that it hasn't.
Anyway, I think that continuing this will be a waste of my time.

Summary:

Me: I'm telling you that with the #showtooltip pressing any of the modifiers you should be able to change the icon based on the rules you've given it. Nothing more, nothing less.
You: I delegate the behavior to WOW.
Me: So you haven't fixed it.
You: You don't understand.
Me: How the hell are you going to delegate the behavior to WOW when it's your addon who tells your macro what to press in that macro?

I'm not saying to change stances and have the skills change.
I'm saying to change the skills without changing yourself WITH MODIFIERS / stances and especially in combat.
There's a big difference.
MODIFIERS = alt, ctrl, shift...

I'm not going to try to steer or help any further on this. Not even if I'm asked for help. I'm out.

I'm done👋. I'd rather not understand anything if this keeps going like this.

With TWW’s changes you don’t create a macro and drag it to the actionbar. A macro (like on your actionbar) can no longer /click another macro (like a GSE Sequence). Instead you have to keybind a GSE Sequence directly. As a result there is no macro to update with #showtooltip on the action bar. It’s not about stubbornness. Its a case of what you are hung up on simply doesn’t exist anymore in game.