[7.1.5] GetQuestItemInfo returns incomplete data
2 Attachment(s)
GetQuestItemInfo occasionally returns wrong or incomplete data in response to QUEST_DETAIL/QUEST_COMPLETE.
The readout in chat comes from this print probe: Lua Code:
With the data: Lua Code:
If there's something I'm missing here, such as a requirement to scrub the data before you call these functions or something to that effect, feel free to respond to this thread. |
Isn't it normal behaviour for any Get*Info function? I don't think GetQuestItemInfo is different from GetItemInfo. If item isn't cached yet, you'll get either incomplete data or a bunch of nils.
When you request info on not yet cached item, you need to register for GET_ITEM_INFO_RECEIVED event, after this event fires you need to request info again, but I'm not sure if GET_ITEM_INFO_RECEIVED fires after GetQuestItemInfo calls :confused: Alternatively you may try to call stuff recursively w/ some delay if info is missing: Lua Code:
Some checks to avoid infinite loops may be quite useful too :D |
From what I can tell reading the source code, this data should already be available once the event for the quest data fires. I've added a hacky solution for now, but this really seems to be something that's wrong internally. Notice how both the texture reference and the item count get populated properly in both cases, but the name and quality do not.
|
Item name and quality are both properties that aren't always immediately available, so it should indeed be a cache issue. I don't know if those are screenshots from the default UI, but in that case it seems like they're just missing a suitable callback for when the item has been cached. And no, from my experience GET_ITEM_INFO_RECEIVED is not triggered by functions other than GetItemInfo, even though other functions can be used to request cache info.
|
These screenshots are of an addon, but it's irrelevant. The print output is from the function used by the default UI, called with the same arguments in response to the same event. The frames show what the problem is, but the main thing to look at is the chat output.
The code that runs this is highly optimized in comparison to the quest frame / quest templates, which might account for a few milliseconds. That's the only reason I can think of why it would fail this way. The default UI does not have any callbacks and do not postpone the item updates. It seems in the default UI that they assume the item data exists on QUEST_DETAIL and/or QUEST_COMPLETE. |
All times are GMT -6. The time now is 09:26 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI