Authors CurseForge

I haven't looked at your code so I don't know if you are doing this, but here are some things to make sure of...

Setup some sort of spec cache that lets you know when someone's spec has been found, at some point you should not need to do any more talent queries in a raid. If a warrior was found to be a tank, then you should always remember that that unit is a tank without running another query.

Also make sure you are only querying classes that need to be queried. No need to check what spec a rogue is or which spec a warlock is. You know what their role is. They usually get the same buffs no matter what. But Warriors, Priests, Druid, Paladins, and Shaman need to be queried and then cached. Again at some point no more talents need to be queried since you should already know.

As far as what LibTalentQuery does in idle if no queries are in queue... nothing. If there are units who can't be queried (because they are not in the same instance, or are really far away, then they will remain in the queue until they are in "visible" range.

I recently changed the delay time to check the inspectionQueue from 2 seconds to 1 second (which helped in my testing on unnecessary delays in sorting through the raid). The value is a "constant" variable 9called INSPECTDELAY) and you can change it in the code to see if that is what is causing unnecessary lag for you. If you find it is, let me know and I will look into permenantly changing it in the library source.

Remember, this is a new lib that has really only been tested by one person (me). So your feedback is important.

I don't think it's the lib itself, but rather like I said, the way I'm using it. I've reviewed my code, and made some tweaks. As soon as the realms are back from maintenance, I'll check this.

-Pach

Quote from Zidomo »

Its likely scanning for everyone's buffs all the time, in order to keep the results text updated (as you need to do nothing to see updated results). This is really not needed and may be why its eating CPU when idle. Change it to do a buff check only when you click the FuBar icon (or similar)? Or something else that will cut the idle usage.

I verified the CPU problem. It's using less CPU time then any other inactive module I have installed except for Proximo, at less than .100 CPU/Sec according to OptionHouse. For comparison, ItemPriceTooltip (another Ace2 module), with out any items being displayed, was using around .800 CPU/Sec more than 8 times more.

I placed a debug statement at the top of each of my functions in my MoBuffs.lua module. None of them are being called, yet it's still using close to .100 CPU/Sec -- which means it's in one of the libs I'm using:

AceAddon-2.0
AceConsole-2.0
AceDB-2.0
AceDebug-2.0
AceEvent-2.0
AceHook-2.1
AceLibrary
AceLocale-2.2
AceModuleCore-2.0
AceOO-2.0
AceTab-2.0
CallbackHandler-1.0
Dewdrop-2.0
FuBarPlugin-2.0
Gratuity-2.0
LibBabble-Spell-3.0
LibStub
LibTalentQuery-1.0
Roster-2.1
Tablet-2.0

Any thoughts on how to track this down? Any usual suspects?

-Pach

Quote from Phanx »

From a quick look at the code, it appears you're rechecking everything in OnTooltipUpdate, which is called not only when you first mouse over the icon, but repeatedly as long as the tooltip is open. It'd be much more efficient to keep the actual data cached and update it separately; as Peragor said, talents really only need to be scanned once per session (with a possible option to manually rescan in case you know someone respecced). For buff scanning, you could either scan at regular intervals, or use the UNIT_AURA event.

OnTooltipUpdate is only called when the frame is first displayed. It isn't called repeatedly. I verified this by adding a trace statement to the top of OnTooltipUpdate.

I only scan talent data once per session -- it's already cached.

I only check for roster updates when RosterLib reports a change.

I only scan tank data from oRA2 and CT_RA when they report that it's changed.

Right now, I've narrowed the culprit down to Peragor's talent lib. Without it loaded, my mod uses 0 CPU. With it loaded -- without making any calls to it -- my mod used 0.100 CPU/Sec, according to OptionHouse.

I'll dig deeper and report my findings to the thread for his mod in the Library forum.

-Pach

Quote from Phanx »

Hmm. Well, I'm not sure how the FuBar plugin I wrote a while back updated data inside the tooltip while it was open, then. I don't recall doing any kind of event scheduling...

I don't update data in the tooltip while it is open.

Quote from Phanx »

Either way, it'd still be more efficient to cache the buff data... even if you do it on tooltip generation, only do it if it hasn't been done already in the last 10 seconds. You could actually just cache all of the tooltip text; that would take care of performance issues for people who like to mouseover very frequently.

I think there'd be more overhead (and more likely something to go wrong) with code to cache the buff data and only scan it every 10 seconds. Until I find a good reason, I'd rather keep it simple.

The culprit turned out to be the OnUpdate handler in Peragor's LibTalentQuery library. Hopefully, either he can modify his lib or I can work something out in mine.

-Pach

I changed it this morning. The delay time for updates is set to 1 second. It should work a lot better now. Let me know if this fixed the issues you had.

Quote from Peragor »

I changed it this morning. The delay time for updates is set to 1 second. It should work a lot better now. Let me know if this fixed the issues you had.

I'm not able to test it at the moment, but from reviewing the code, your changes look good. Thanks for turning this around so quickly.

-Pach

I have tried several of the "buff checking" mods available. I have stopped trying out new ones since I found yours. It is so easy to use and I love it!

On issue I am having is with the WeaponBuff. I am a feral druid who uses Adamantite Weightstones. After I have completely raid buffed myself (including the weightstone), MoBuffs still indicates that I am missing a WeaponBuff.

I was going to report that it did not record weapon buffs at all (since many of my fellow raisers report the need for a waepon buff), however, there were some other raid members who MoBuffs showed the correct info for.

Please let me know if you need more info, I hope that you are able to figure out what is missing. Perhaps it is only misreporting your character while it is getting the rest of the raid correctly?

Quote from Sardrimm »

On[e] issue I am having is with the WeaponBuff. I am a feral druid who uses Adamantite Weightstones. After I have completely raid buffed myself (including the weightstone), MoBuffs still indicates that I am missing a WeaponBuff.

There was an issue with the regex matching for weightstones (and sharpening stones) in early versions. This has been correct for about a week now though.

When you open your character pane, and hover over your weapon, after you have applied the weightstone, can you tell me what is displayed? For instance, this image shows the "Sharpened" buff:



What text do you see for your "Weighted" buff?

The other possibility is that, as I understand it, you don't get the benefit of some temporary weapon buffs when you are in kitty or bear form, and that this is being fixed in patch 2.4. Could this be the culprit?

-Pach

My mace looks like yours but it says:

Weighted (+14 Crit Rating and +12 Damage) (60 min)

I just saw a new MoBuffs build, so I am trying that out. Ill let you know if there is still an issue.

Thanks

LibTalentQuery callback changed. It now returns (event, name, server). This was changed because even raid unitid change quickly, especially during the beginning of a battleground (I test in AV). The result is that the name and server should now be always acurate.

Change the following in your code:

function MoBuffs:TalentQuery_Ready(_, unitid)
	if (unitid) then
		local unit = RL:GetUnitObjectFromUnit(unitid)

to:

function MoBuffs:TalentQuery_Ready(_, name)
	if (name) then
		local unit = RL:GetUnitObjectFromName(name)

RosterLib doesn't store the server yet, so if 2 people have the same name but from different servers then RosterLib is confused. That will be fixed in next version of RosterLib.

Quote from Peragor »

LibTalentQuery callback changed. It now returns (event, name, server). This was changed because even raid unitid change quickly, especially during the beginning of a battleground (I test in AV). The result is that the name and server should now be always acurate.

Change the following in your code...

Done.

Thanks Peragor.
-Pach

Quote from Phanx »

Even though the bonuses from the temporary weapon buff aren't currently applied to druids' attacks in feral forms, the buff remains applied to the weapon, so upon inspection you'll still see the buff text in the weapon tooltip.

Thanks for the info Phanx. I believe that the fix I checked in last ~Friday fixed adamantite weightstones and sharpening stones.

-Pach

Can you have it where when i click the player it auto whispers them and i dont have to press enter since you mod only enter the data in the chat box an doenst send it.

thanks
jk

I would like to request the removal of shadow protection from the list of what MoBuffs checks for. It seems awkward to whisper a person that they're missing a buff they have no control over, especially one which is so situational.

In addition, I would also add my vote to the poster who asked for the ability to notify the raid. I'd rather not have to whisper each person individually.

just an addition mate,

The Shattrath flask of blinding light applies a buff called "Blinding light of shattrath"
I've amended the lua on my side .. but just a note for your next release ;-)

or (buffName == L["Blinding Light of Shattrath"])

Cheers,

Quote from bornhune »

just an addition mate,

The Shattrath flask of blinding light applies a buff called "Blinding light of shattrath"
I've amended the lua on my side .. but just a note for your next release ;-)

or (buffName == L["Blinding Light of Shattrath"])

Cheers,

Thanks. I've updated the module. Several of the Shattrath flask buff names got changed with the recent patches, and this broke the detection for it.

I also added the new 2.4 weapon coatings and right-click menu options to skip certain buff types (Shadow Protection, Food, Weapon).

-Pach

Quote from Pachelbel »

I also added the new 2.4 weapon coatings and right-click menu options to skip certain buff types (Shadow Protection, Food, Weapon).

-Pach

Lots of errors after the last update r74925

[2008/05/23 14:27:03-3615-x1]: AceLocale-2.2-40629 (Ace2):487: AceLocale(MoBuffs): Translation "Skip Shadow Prot Buff" does not exist.
MoBuffs-1.3 (Build $Rev: 74925 $)\MoBuffs.lua:18: in main chunk

The above error also shows for:
Skip check for priest Shadow Protection Buff
Skip Weapon Buff
Skip check for Weapon Buffs
Skip Food Buff
Skip check for Food Buffs


edit: also getting error on
Blinding Light of Shattrath
Pure Death of Shattrath

@brotherhobbes: Thanks. I didn't think missing localizations would cause a "hard" error. Regardless, I updated all the localizations when translations (or place holders) where I could.

Can you have MoBuff not indicate people need an int buff if they currently have K'iru's Song of Victory?

You may want to skip the fortitude buff as well, if there isn't a priest with the improved fort in the group/raid.