Authors CurseForge

Wiki:
http://wowace.com/wiki/LibTalentQuery-1.0

Problems with blizzards talent query api:

• When the INSPECT_TALENT_READY event is fired, it doesn't tell you which unit it's ready for.
• Because of 1 you can not query multiple units at once.
• If two addons call NotifyInspect() at the same time, neither addon knows if the INSPECT_TALENT_READY event is "theirs".

This library attempts to fix this problem by providing:

• A callback "event" that will provide the unitid of the unit which the talents are ready for.
• A queueing system the will only do one NotifyInspect() at a time on a unit who is visible and connected.
• A secure hook on NotifyInspect that will take preventive measures to stop another addon from confusing a query.

I am using it in a Grid module called GridLayoutPlus which sorts raid unit by Role (tanks, melee, healers, ranged).

This is my first library so I might have made some mistakes, and I welcome any input to fixing and improving the library.

Storing unit is bad, don't do it. You have no way of knowing that a unit that was requested for an inspect is the same unit when it actually comes especially if you're queuing inspects, store the name/server/class/classToken (or GUID come 2.4) and use that. This is one of those things that addons should just do themselves. Setting a hook and have a flag set that we shouldn't try to inspect is only 5-6 lines and not really worth having it's own library for.


Once 2.4 hits, the usage for talents is reduced greatly because you can only inspect within 30 yards, only non hostile/non flagged players so the chance of actually seeing conflicts is going to be lessened.

Apoco (the author of aX_RaidStatus) already created a LibTalents-1.0 library. Maybe you two can get together and discuss merging these libraries so I'm not stuck running two libraries that do the same thing?

There's also TalentShow-1.0...

Edit: Ooops, looks like TalentShow is only for self-inspection.

I think querying for talents is still going to be useful -- even after 2.4.
And I like the idea of having a single lib to do this with.

-Pach

Peragor-

I've updated my buff checking module (MoBuffs) to use your lib, and it seems to work well.

I'll be uploading my buff checking module to the SVN shortly. Yes, it's yet another buff checking module, but this is one that I've been working on since TBC came out. It's heavily heuristic based -- and absolutely zero config. I've looked at other buff checkers and they were all either too complicated, or all incomplete. Hopefully others will find it useful too.

-Pach

I will rework my library to store the unit name. The only problem I'm having is getting the unitid afterwards. I see in DogTag, ckknight is basically going through all the possible unitids and seeing if there is a UnitName match. In doing that, there needs to be a preference in what gets returned. For example, in my addon GridLayoutPlus, it sorts a raid by unit roles (tank, melee, healer, ranged), and it's expecting the unitid to be a raidx unitid, not target, or mouseover.

My current thinking is that I will have a boolean argument (isStrict) that is passed to :Query(unitid, isStrict). That flag will determine if the unitid that is returned is of the same type (or maybe the exact same unitid, not sure yet) that was sent in originally.

Thoughts?

I made changes to store the unitname rather then the unitid when necessary. If a unitid cannot be returned, it will return the unitname of the unitid queried.

In CheckInspectQueue() where it's looping over the list of units to inspect... the only checks it does on the unit before attempting to inspect it are:

UnitIsVisible(unit) and UnitIsConnected(unit)

Should it also do a CheckInteractDistance() and only check those in range?

-Pach

Not until 2.4. I believe NotifyInspect currently (on the live servers) only requires that the unit is in "visible" range for friendly units.

From what people have told me, Blizzard will be limiting the range in 2.4 and removing the ability to inspect hostile units. Do I think this will kill this library, no. I think it will still be useful, but it mean you have to be more careful which units you query because they will stay in the inspectionQueue until stricter conditions are met.

When 2.4 goes live I will modify the code to reflect blizzard's new restrictions.

You might be right. But allow me to debate for the sake of allowing you to correct me because I may be missing somethings.

The LibTalentQuery library as it stands is nothing more then a wrapper for a crappy blizzard talent query api. It doesn't do anything really monumental, but it does seem like a lot of addons may need to have similar code in their addons. If we all agreed on what that code would be, why not make it a library? I mean there are a lot of libraries that people use that aren't necessary. I just thought it seemed to fit the "why rebuild the wheel" type philosophy that I assumed libraries are for.

I am a newb. I don't get on IRC that much. I don't read all the forum debates on "the best way to do things". I'm oblivious to what the current trend is with libraries. If you explain to me why this library is silly, I might go "man, I can't beleive I thought I solved something". Just let me know. I'm not one of those people who thinks everything he does is magic :)

1) Hook NotifyInspect
2) Set flag "Inspect request sent, time out at GetTime() + 3"
3) If INSPECT_TALENT_READY fires, clear flags

Now when you want to inspect, check if a request was sent, and see if it's timed out yet, if it has then you send your request if it hasn't you wait until the flag is dropped or you see if you can attempt to inspect again on ITR. It's not worth making a library for something as simple as that, reinventing the wheel is fine if you do it smartly.

Quote from ckknight »

An extra library for such a specific and small task seems like overkill.

Wait wait...

Could you repeat that, slowly?

I've been investigating spurious CPU usage in my MoBuffs mod.

It turns out it's caused by the OnUpdate handler in the LibTalentQuery library.

Even without any units queued to inspect, the OnUpdate handler is being called continuously by the main UI, and the little bit of processing being used by the handler is being wasted.

I think if no units are queued, you should unregister the OnUpdate handler, and then re-register when work comes in.

-Pach

I will change this tonight. Thanks for the heads up.

Quote from Shadowed »

1) Hook NotifyInspect
2) Set flag "Inspect request sent, time out at GetTime() + 3"
3) If INSPECT_TALENT_READY fires, clear flags

Now when you want to inspect, check if a request was sent, and see if it's timed out yet, if it has then you send your request if it hasn't you wait until the flag is dropped or you see if you can attempt to inspect again on ITR. It's not worth making a library for something as simple as that, reinventing the wheel is fine if you do it smartly.

It sounds simple enough, but the devil is in the details. For instance "time out at GetTime() + 3" means you need 1) either some event scheduling lib or 2) to hook/unhook the OnUpdate event task as needed. Either way, that's more code you need.

Suppose you have a group of people to inspect... like I don't know, say a 25 man raid? You then need queueing code to send the requests one by one to the server. Again, not rocket science, but still more code you need.

You also need to have checks in there to see if some other addon wasn't playing nice and sent a request on top of you.

Peragor's lib does all of the above, in a nice simple, re-usable package.

Just my two cents.
-Pach

Can you actually name me how many addons need to inspect the entire raid for talents? It's fairly obscure, mostly things like Scrub it's not worth making a library out of it.

You do not need a library for everything the below is 45 lines I did this in 10 minutes, and I don't even need any additional code from LibStub or CallbackHandler-1.0 that adds extra resources or complexity, it's not complicated, and not enough addons are going to actually need something like inspect the entire raid (especially now that you're limited to 30 yards on talents) to make it a worthwhile library.

local inspectSent
local inspectQueue = {}
local timeElapsed = 0
local frame = CreateFrame("Frame")
frame:Hide()

local function inspectReceived()
	if( #(inspectQueue) > 0 ) then
		NotifyInspect(table.remove(inspectQueue, 1))
	else
		frame:Hide()
	end
end

-- Reset our flag early if we get the info
frame:RegisterEvent("INSPECT_TALENT_READY")
frame:SetScript("OnEvent", inspectReceived)

-- Time out after 3 seconds
frame:SetScript("OnUpdate", function(self, elapsed)
	timeElapsed = timeElapsed + elapsed
	
	if( timeElapsed >= 3 ) then
		inspectReceived()
	end
end)

-- Hook so we don't cause issues with other inspect addons
hooksecurefunc("NotifyInspect", function(unit)
	timeElapsed = 0
	inspectSent = true
	frame:Show()
end)

-- Send the inspect if we don't have any pending, if we do queue it up for later
function sendInspect(unit)
	if( inspectSent ) then
		table.insert(inspectQueue, unit)
		return
	end
	
	NotifyInspect(unit)
end