LibQuestItem-1.0
There are various ways to tell if a item is a quest item or not. This library will attempt to combine all different ways.
The library will only be able to tell a addon if a item is a quest item if the user have the item equipped, in a bag, on keyring or in bank when visiting.
Implemented so far:
-Scan for quest items in bags, keyring and equipped. Scanning using GetContainerItemQuestInfo() and looking at item type and subtype using GetItemInfo.
-Scan for quest items using the questlog using GetQuestLogSpecialItemInfo().
-Detects if items starts a quest and/or if the user is already on the quest the item belongs to.
API (so far):
GetQuestItems(forceRescan) -returns a table with itemIds and their properties.
IsQuestItem(itemId) -return true if quest item.
IsUsable(itemId) -return true if usable quest item.
StartsQuestId(itemId) -return the questId if item starts a quest.
IsQuestActive(itemId) -return true if user is on quest.
NOTE:
This is my first library so any constructive feedback is very welcome.
Another patch for Legion as I discover now item link is compressed (zeros between : are omited) now. I did make dirty hack, because actual links are in Legion more complicated with far more fields.
local PATTERN_itemid = "item:(%-?%d+).+"
at line 42. Actually this works on 6.2.4 as well, because this library needs only itemID parsed and rest arguments can be safely dropped off.
Patch for Legion. Function GetAuctionItemClasses() was removed, new function is introduced.
local LOCALE_QUEST = ((_G.GetItemClassInfo == nil) and select(10, GetAuctionItemClasses())) or _G.GetItemClassInfo(LE_ITEM_CLASS_QUESTITEM) or "Quest"
above patch works in curent live 6.2.x version as well in 7.0.x version. BTW in actual release is error, because category in GetAuctionItemClasses() should not be 12, but 10 for "Quest". This library actually in 6.2.x works only on US and GB clients. After this fix it works on any client as well.
I would like to see extend this library to handle event QUEST_ACCEPTED. Reason behind it. Item starting quest after accepting it change his state, and this isn't reflected by events updating bags.
Here is an update: http://filepost.com/files/abe93e7a/LibQuestItem-1.0.zip/
I was looking at using this library for AutoPicker to identify quest items in the loot window. Would it be able to do that?
That's the same error from the same library version I posted about 3 months prior below. It was fixed in r18.
You maintaining this post cataclysm? If so:
1x LibQuestItem-1.0-17:139: table index is nil LibQuestItem-1.0-17:194: in function `Scan' LibQuestItem-1.0-17:263: in function <...mKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:258>
Locals: self = <table> { activeQuestItems = <table> {} callbacks = <table> {} PLAYER_ENTERING_WORLD = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:276: StartsQuestId = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:225: PLAYER_REGEN_ENABLED = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:285: IsQuestActive = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:229: UnregisterAllCallbacks = <function> @ Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:202: PLAYER_LEAVING_WORLD = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:281: PLAYER_REGEN_DISABLED = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:289: ITEMS_UPDATED = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:271: startsQuestItems = <table> {} GetItemString = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:213: Scan = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:180: IsUsable = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:221: questItems = <table> {} UnregisterCallback = <function> @ Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:181: RegisterCallback = <function> @ Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:118: usableQuestItems = <table> {} frame = LibQuestItem10Frame {} IsQuestItem = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:217: questItemSpells = <table> {} } questItems = <table> { 57755 = true 1357 = true } usableQuestItems = <table> { 1357 = true } startsQuestItems = <table> { } activeQuestItems = <table> { } questItemSpells = <table> { } ScanInventory = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:149: ScanBags = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:125: ScanQuestLog = <function> @ QuestItemKeybound\Libs\LibQuestItem-1.0\LibQuestItem-1.0.lua:159: callbacks = <table> { recurse = 0 events = <table> {} Fire = <function> @ Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:87: }
-Solid...but just experienced the first bug/error with r17.
LibQuestItem-1.0 r17 (upgraded from r14), QuestItemBar v0.6, USEnglish client/server, WoW 3.3.5a live, Ace3 disembedded, all other libraries (including LibQuestItem) embedded. Sometime when doing quests in Colderra, the following error occurred:
There was a span of about 10 minutes between when the error happened (and repeated 7 times) and when I noticed the BugSack LDB display, so can't be certain what triggered the error.
May have occurred when picking up quest item drops off mobs for a certain quest...you get up to 5 copies of the same item (shows them stacked in QuestItemBar) to be "used on" other items. Or it came from a quest item that could "summon" a friendly NPC when used (its only usage). Will link the quests later if it will help debug.
As to CPU usage, in addition to r45 of QuestItemBar using 0 CPU/second when idle, the following similar mod also uses 0 on idle: QuestClicks.
Thanks very much for replies and hope you get this working perfectly soon :D.
The lib should be pretty solid now. It spikes a bit when scanning for items but it's not that bad i think. It should never ever make a scan during combat. It is listening to the BAG_UPDATE event which fires if you loot during combat, but it will only set a var to true to indicate a update is needed. Then on PLAYER_REGEN_ENABLED the OnUpdate frame is shown and will initiate a update if needed, then it will be hidden again.
Parties should not be a problem, BAG_UPDATE is only firing for the player itself as far as i know.
Revision number is fixed.
Mmm yeah I have to dissect QuestItemBar as it seems to be using CPU for me unknown reasons. Though it should not do anything except when the lib fires its its item update callback and some cooldown updates on the buttons when a ACTIONBAR_UPDATE_COOLDOWN fires.
(Removes all bridges from surrounding area) :D
Finally, with r14 this library uses 0 CPU when idle. Nice work. Had to switch to testing with the following mods to see what CPU was used on looting, as OptionHouse closes when you loot: AddonProfiler & AddonManager (both more inconvenient to see ongoing CPU, though).
It does spike a bit when you loot, but nomoreso than other mods that update on bag content changes. And appears to spike to substantially lower heights than QuestItemBar r45 does itself + through Ace3 when you loot something.
The big thing will be to see if it actually causes lag when looting in parties. Which is a potential hazard when doing OnUpdates non-optimally (and I've seen testing another mod called Broker Garbage before it was recoded).
Looking better so far, though.
EDIT: one small thing, the library revision number (14 currently) isn't seen in its LUA file as it should be, even though you have a revision line at the top.
EDIT#2: one bigger thing: tested QuestItemBar v0.6-beta1 with this library embedded (Ace3 still disembedded). For some reason, the mod appears to use a small amount of CPU in combat (0.01 in AddonProfiler when not looting) with a larger than expected spike immediately after the end of combat for 2 ticks/seconds (0.15-0.25 in AddonProfiler and again, not looting). No quest items were on the bar or being used.
The mod should shut totally off (in effect) during combat, other than letting you click quest items that may be on the bar. That increased use immediately after combat is over for 2 seconds seems odd if nothing in your packs or the bar has changed.
Thanks for being so persistent Zidomo. I actually don't understand why LQI was showing absolute zero CPU when QIB was loaded. But you were right, LQI was bugged because of my stupidity. It wasn't doing any item scans but the OnUpdate was constantly running.
Please try r14, if it isn't fixed I will jump off a bridge or something :-D
No, not with items showing. That's a different circumstance unrelated to what LibQuestItem-1.0 is doing on its own with QuestItemBar. Whether or not your secure action buttons use CPU or not, the issue here is what LibQuestItem-1.0 is doing on its own when no items are shown on the bar.
QuestItemBar r45 - - with Ace3 disembedded, other libraries embedded (CallbackHandler-1.0, LibAboutPanel, LibGratuity-3.0, LibStub) - - uses 0.0 CPU/second when idle with no items showing as show in this screenshot. QuestItemBar's anchor button is shown immediately below the OptionHouse frame. Ace3 uses the same 0.775 CPU/second median that it does on its own with no mods that use it are loaded; QuestItemBar doesn't go through it.
Thanks for the screenshot. I will try with only these three addons loaded ASAP. I really want to fix this. :-)
Hmm is old revisions of QuestItemBar really using 0 CPU when idle (with items showing)? As far as I can see a SecureActionButton is using about 0.4-0.7 CPU/s. For example Bartender4 is using like 130 CPU/s for me displaying about 60 buttons. Hide half of the buttons and the CPU usage drops with about 50%.
Odd. Well, here is a screenshot of OptionHouse with LibQuestItem-1.0 r13 standalone active with CPU profiling enabled so you can see what's happening here. I cut that section out of the original WoW screenshot with IrfanView.
r13 is using identical CPU as r11 was. That CPU usage is continual, not occasional spiking. It never drops below 0.275 and never goes above 0.350. If wondering, the OptionHouse frame display has been distorted since WoW 3.3.3 (see comments on its WoWI page).
QuestItemBar r45 using LibGratuity-3.0 (which you've eliminated in the latest alphas & added LibQuestItem-1.0) uses 0.0 CPU on idle. Still hope you can do something to improve this library. If not, GL with it & the mod.
Nope sorry, OptionHouse is telling me 0.000 CPU/Sec for LibQuestItem running standalone.
That is really weird. Using AddonProfiler I see no CPU usage at all except after a BAG_UPDATE. I will try OptionHouse tonight.
Unfortunately no, its not better. r11 is using much more CPU time than r10 did.
Right now with just OptionHouse & LibQuestItem-1.0 (loaded via LOD through Option House) active, the library uses between 0.225-0.310 CPU/second on idle (averaging around 0.275).
Yeah I thought it could be helpful. Just need to set the APIs so it could be useful to any addon.
I know what is causing the CPU usage.
I've changed the code to have the frame hidden until a BAG_UPDATE event occurs. Then hide it again after the item scan. Please let me know if it is better now.
Nice idea. Various quest mods (other than yours) moving from their own methods to perhaps this library might take some effort, but still, nice idea :).
One thing noticed so far that could use some improvement, though. Loading this alone (LOD), it uses 0.100-0.110 CPU/second when a character is idle. Not much, but its still the only library/library system I've seen lately besides Ace3 that uses CPU when idle.