WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   AddOn Help/Support (https://www.wowinterface.com/forums/forumdisplay.php?f=3)
-   -   Problem getting accurate spell descriptions (https://www.wowinterface.com/forums/showthread.php?t=57331)

merlecorey 08-06-19 07:52 PM

Problem getting accurate spell descriptions
 
Here's another headscratcher I've run into.

I am trying to figure out the amount of healing or damage a spell does. In the past, I used a tooltip scanner, but that approach doesn't seem to work now... or if it does, I don't know how to code it correctly because I can no longer call GetText() on tooltip's font strings and get the actual text back (I get nil instead).

So I am trying to use Spell:CreateFromSpellID / ContinueOnSpellLoad / GetSpellDescription, which seems to be the intended way of getting spell descriptions now. So, here's the scenario:

* I get the description of a healing spell. It has the correct healing amount.
* I get a buff that increases all healing done by 15%.
* My UNIT_AURA callback is called and I get the spell description again. It has the old -- incorrect -- healing numbers.
* Several hundred milliseconds later, the string returned by GetSpellDescription() finally changes to reflect the correct healing amount. There doesn't seem to be an event associated with this description change.
* The buff expires. Several hundred milliseconds later, the text reverts to the original healing amount.

Now, the long delay itself isn't a problem. The problem is that I can't find a way to detect the moment of change via an event. Sure, I can poll for changes, but that sucks because it's much less inefficient.

So, two questions.

1. Is there a better way to handle this aside from polling?

2. Is tooltip scanning still a thing? (If so, a working code sample would have been awesome)

Thanks!

aallkkaa 08-07-19 10:42 AM

I can't give you a real answer (because I don't have the knowledge), but I can throw a hint at you:

AceTimer-3.0.lua mentions:
Code:

-- AceTimer is currently limited to firing timers at a frequency of 0.01s as this is what the WoW timer API
-- restricts us to.

So, the "several hundred milliseconds later" might actually be exactly 0.01 seconds, plust latency. Blizzard API functions (not Ace3) of interest to you here:
C_Timer.After
GetNetStats
So, my idea is that, upon UNIT_AURA firing, you'd get the world latency via GetNetStats(), add that value to 0.01 and set a one time timer, via C_Timer.After(), to execute your GetSpellDescription() routine.

I haven't tested this, but I think it should work fairly well.
Do note that the game itself updates the recorded latency only once every 30 secons, so there might be some times where the above method fails because of instant latency higher than the last recorded value. Adding some extra padding time might be a good idea.

merlecorey 08-07-19 11:36 PM

Quote:

Originally Posted by aallkkaa (Post 333070)
So, my idea is that, upon UNIT_AURA firing, you'd get the world latency via GetNetStats(), add that value to 0.01 and set a one time timer, via C_Timer.After(), to execute your GetSpellDescription() routine.

Sorry, that's a horrible idea. Worse than polling for changes.

LanceDH 08-08-19 11:14 AM

This seems to scan just fine
Lua Code:
  1. local i = 1;
  2. local line = _G["GameTooltipTextLeft"..i];
  3. while line do
  4.     print(line:GetText());
  5.     i = i + 1;  
  6.     line = _G["GameTooltipTextLeft"..i];
  7. end

merlecorey 08-08-19 05:36 PM

Quote:

Originally Posted by LanceDH (Post 333086)
This seems to scan just fine
Lua Code:
  1. local i = 1;
  2. local line = _G["GameTooltipTextLeft"..i];
  3. while line do
  4.     print(line:GetText());
  5.     i = i + 1;  
  6.     line = _G["GameTooltipTextLeft"..i];
  7. end

Interesting. This works for the standard UI tooltip, but only if it's visible. If it's not, this doesn't work. Nor does it work for my own tooltip frame.

aallkkaa 08-09-19 07:25 PM

Quote:

Originally Posted by merlecorey (Post 333071)
Sorry, that's a horrible idea. Worse than polling for changes.

Just curious - no need to answer if you don't want to... but why so?

Kanegasi 08-09-19 08:44 PM

Quote:

Originally Posted by aallkkaa (Post 333108)
Just curious - no need to answer if you don't want to... but why so?

Doing anything with UNIT_AURA, especially calling those two functions each time, is a noticeable performance hit. UNIT_AURA is ridiculously spammed, dozens a frame, in any combat situation to the point that it's almost useless to even add-ons that deal with auras. I constantly have to edit add-ons I update to disable any registrations for that event. None of the add-ons I have edited do anything useful with it anyways.

merlecorey 08-10-19 11:20 AM

Quote:

Originally Posted by Kanegasi (Post 333110)
Doing anything with UNIT_AURA, especially calling those two functions each time, is a noticeable performance hit. UNIT_AURA is ridiculously spammed, dozens a frame, in any combat situation to the point that it's almost useless to even add-ons that deal with auras. I constantly have to edit add-ons I update to disable any registrations for that event. None of the add-ons I have edited do anything useful with it anyways.

I actually find it one of the more useful events. It's fired once per unit per frame, no matter how many auras are added, updated or removed during that tick. I can use it immediately to do my processing, or I can remember the fact that there's something different about this unit's auras and do it on a reduced frequency timer at a later point. And, most importantly, it's reliable... unlike CLEU.

Quote:

Originally Posted by aallkkaa (Post 333108)
Just curious - no need to answer if you don't want to... but why so?

Why? Because your design is based on your assumptions, which is a great way to build unreliable code that's liable to break every time your assumptions turn out to be baseless -- which they always do.

aallkkaa 08-10-19 11:38 AM

Quote:

Originally Posted by Kanegasi (Post 333110)
Doing anything with UNIT_AURA, especially calling those two functions each time, is a noticeable performance hit. UNIT_AURA is ridiculously spammed, dozens a frame, in any combat situation to the point that it's almost useless to even add-ons that deal with auras. I constantly have to edit add-ons I update to disable any registrations for that event. None of the add-ons I have edited do anything useful with it anyways.

That is a good point, Kanegasi. But given that the OP had mentioned themselves that they'd gladly use UNIT_AURA (the alleged problem residing elsewhere), I never even thought about it.
And the OP (who was also who posted the comment I was inquiring about) just confirmed after your post that they're alright with listening to that event.
But indeed, Kanegasi, your point was valid (to me) and I actually had given no consideration to it before, so... :cool:

Quote:

Originally Posted by merlecorey (Post 333128)
Why? Because your design is based on your assumptions, which is a great way to build unreliable code that's liable to break every time your assumptions turn out to be baseless -- which they always do.

Well, I don't act on assumptions. But I sometimes test whether an assumption turns out to be acurate or not.
So, for example, your assumption that my untested code would be worse than polling for changes is actually baseless. Even so, it might, upon testing, prove to be true. Or not.
I asked because you seemed certain of what you were saying and I wanted to learn. Turns out you're no more certain about what you said than I was about what I proposed. Just sayin'.


All times are GMT -6. The time now is 11:23 AM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI