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.

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.

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.