Thread Tools Display Modes
07-29-16, 12:42 AM   #1
VincentSDSH
Non-Canadian Luzer!
 
VincentSDSH's Avatar
AddOn Author - Click to view addons
Join Date: Jun 2006
Posts: 350
QUEST_LOG_UPDATE and GetQuestLogTitle()

THE SETUP

So, for ages I've had a little bit of code that looks for quest progress and completion and respond to certain criteria. With the drop of the new client, it triggers a 'quest complete' response upon zone/hearth/etc b/c the 'quest complete' criteria is complete.

I do this in a simple manner, tracking only changes in totals of quests/quest completed/objectives completed (i.e., it is questID agnostic)

When comparing current_complete to previously_complete, if C > P then a quest was completed. So each value of 'current' is shuttled into 'previous' when the new check begins. This works flawlessly and has for y-y-years.

I finally traced the problem to the 2nd trigger of QUEST_LOG_UPDATE after entering the world.

QUEST_LOG_UPDATE fires like mad (expected) but it seems at the FIRST trigger after zoning, GetQuestLogTitle() does not return 'IsComplete' properly and it comes back as not-complete regardless of the status.

By the next QUEST_LOG_UPDATE, GetQuestLogTitle() is returning it properly but the damage to that simple logic is done and the user (me) wondering about that 'complete hearthing' quest I just completed.

THE QUESTION

Is this 'the new normal' for this event? Or is this a bug? Or is there some new setup event I should look for before trusting GetQuestLogTitle()

I know I can work around it (I can think of a few ways off the top of my head) but I haven't seen this noted and wasn't sure if it was a known bug that's being addressed or if I should just groan and plug in a semaphore.
__________________
AddonsExecutive Assistant User Configurable To-Do ListLegible Mail Choose the Font for Your Mail
  Reply With Quote
07-29-16, 08:03 AM   #2
Nimhfree
A Frostmaul Preserver
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 267
There are torturous things surrounding Blizzard's quest system. I use UNIT_QUEST_LOG_CHANGED instead. I use QUEST_LOG_UPDATE just to indicate the quest log is ready to be used, but that is because events differ between startup and UI reload. When I use UNIT_QUEST_LOG_CHANGED I also delay its processing for 0.5 seconds, which I guess your semaphore would mimic. Remember not to believe the number of entries returned by GetNumQuestLogEntries() as closed entries makes things wonky.
  Reply With Quote
07-29-16, 11:22 AM   #3
VincentSDSH
Non-Canadian Luzer!
 
VincentSDSH's Avatar
AddOn Author - Click to view addons
Join Date: Jun 2006
Posts: 350
Trying to use events deal with it was impossible, or at least highly problematic, given that the ones that trigger before the 'tween zones' kick of QUEST_LOG_UPDATE fire damned often.

I eventually just decided to scan a table of completed IDs then compare that before and after scan of the quest log. Since the scan only ADDs quests to the table (and they're removed fro it by QUEST_REMOVED), it provides the count data that the list should provide.

I think QUEST_LOG_UPDATE now suffers from the same issue that, er, crap, WORLD_MAP_something does where it returns 0,0 as interim coordinates from the nether region between one zone and another.
__________________
AddonsExecutive Assistant User Configurable To-Do ListLegible Mail Choose the Font for Your Mail
  Reply With Quote

WoWInterface » Developer Discussions » Lua/XML Help » QUEST_LOG_UPDATE and GetQuestLogTitle()

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off