QUEST_DETAIL event missing information

[Gregity]

I'm working on QuestGuru and there is a section where it modifies the title to show the quest level whenever the QUEST_DETAIL event (which is the panel showing) occurs.

The problem is that the function calls to get data don't always return data.

Sometimes, the GossipAvailable functions return data (just one because there is only one on a detail), sometimes I can get the data from the NumActiveQuests (which is 1) and data thence from GetAvailableTitle(1) and GetAvailableLevel(1) and sometimes neither set returns a result. For examples that don't return anything, check out "Discover Rolf's Fate" given by the pile of bones (name="a half-eaton body") in response to a "cast" when you click on them and GoldTooth given by Billy Maclure

Is there another quest information function that I can use to get Quest information from the client based upon the Quest Name or perhaps the Quest ID? Are there other quest information functions I can use at the event?

GetTitleText() always return correctly & GetQuestID() returns the correct number for the quest (the ID, not the QLog Index) but as the quest is not in my quest log there isn't much I can do with it.

[p3lim]

GetGossipAvailableQuests

local function getGossipLevel(index)
	return not not select(index * 2, GetGossipAvailableQuests())
end

I use similar functions in my newly released add-on Monomyth.

[Gregity]

Providing GetGossipAvailableQuests() returns any data at all.

But as I said, it is returning nothing at all sometimes. GetNumGossipAvailableQuests() is returning zero.

On those QUEST_DETAIL panels which do follow a GOSSIP_SHOW, the GetGossipAvailableQuests() is fine, but when it comes from other paths, it returns nothing.

That's when I turned to the GetNumAvailableQuests() and it's cousins GetAvailableTitle() & GetAvailableLevel(). I thought I had it licked, then I ran into two (so far) questgivers that show a detail page and neither set of data is appearing. Crikey this makes HTML coding look consistent...

-g

[p3lim]

Quests are shown in two different ways.
Either directly as a quest, or through gossips.

You'd have to support both in order for this to work.

The function I showed above works only with the gossip frames, while the GetAvailableLevel only works with the other.

Try watching for QUEST_GREETING and GOSSIP_SHOW, store the data there, before proceeding into QUEST_DETAIL, where you will commence your code to change the title.

[Gregity]

I don't think I'm communicating well.

What I'm saying is that I have found cases where NEITHER of them work.

I have every event related to Quests registered and I know, via chat messages, when each is invoked. Using /etrace and /framestack (see DevTools) I can see what events pop and what panels are shown.

Currently, I'm looking at a panel opened when I clicked on Billy Maclure and it is a <1> QuestFrame -> <2> QuestFrameDetailPanel -> <3> QuestDetailScrollFrame -> <4> QuestDetailScrollChildFrame stack.

The events, immediately after reloading are:
ADDON_LOADED
QUEST_DETAIL
--set 1
{GetGossipAvailableQuests()} gives an empty table (that is nothing returned)
GetNumGossipAvailableQuests() gives 0
--set 2
GetNumAvailableQuests gives 0
GetAvailableQuestTitle(1) gives nil
GetAvailableQuestLevel(1) gives 0
--other
GetQuestID gives 87 (which is the correct QuestID for "Goldtooth"
GetQuestTitle() give "Goldtooth"

That's it. Most everything else gives results with set 1 or set 2. At least two so far have given no data for either set 1 or set 2.

[p3lim]

Just did a simple test myself

GOSSIP_SHOW: GetNumGossipAvailableQuests() returns 1
QUEST_DETAIL: GetNumGossipAvailableQuests() returns 1
QUEST_FINISHED: GetNumGossipAvailableQuests() returns 1

QUEST_GREETING: GetQuestLevel(1) returns 85
QUEST_DETAIL: GetQuestLevel(1) returns 85
QUEST_FINISHED: GetQuestLevel(1) returns 85

QUEST_DETAIL: GetQuestLevel(1) returns 0, GetNumGossipAvailableQuests() returns 0
QUEST_FINISHED: GetQuestLevel(1) returns 0, GetNumGossipAvailableQuests() returns 0

I see your issue, neither functions work if there is no QUEST_GREETING or GOSSIP_SHOW event.

[Nimhfree]

I believe you will need to handle QUEST_DETAIL, QUEST_COMPLETE (for things like the Candy Bucket quests that post this even though you have not selected to complete the quest), and QUEST_PROGRESS.

However, doesn't the API you are using for the level of the quest return the recommended level of the quest and not its actual level? Or does the "actual" level returned by GetQuestLogTitle() really return the recommended level as well? If the API you use returns different information from GetQuestLogTitle() then I believe you will not be able to provide the true level of the quest unless you actually have a database of that information, because it is not really available until you accept the quest.

[Gregity]

@p3lim, phew... At least I'm not crazy... I'm still hoping somebody has an idea of another way to get this info however....

@Nimhfree, I'm not even finished with the QUEST_DETAIL panel at the point where I'm having the trouble. Quest Finished would immediately be turning it in (a case I do handle). There are other quests that simply give you a QUEST_PROGRESS for a quest you don't have in your Quest Log.

In all cases that I've reviewed (by no means exhaustive), I've not noticed a difference between what these APIs will show for level and what the level shows once the quest it accepted. I know they aren't the earliest level the quest is available because I've picked up quests @ level 9 that were flagged 10 and 15 in both the gossip & detail screens and the quest log.

Currently when I don't get any info, I'm just leaving the panel as is - a soft fail in this case imposed by limitations in the API

Still hoping there's an answer that includes getting the correct level short of maintaining a database of all quests (something I hope to create as a library someday soon).

To me, it seems that it should be simple to ask via some API "GetAllQuestInfo(QuestID)" and have it return a table of elements with a subtable of objectives (if any). That would be so nice!

-g

[Nimhfree]

Originally Posted by Gregity Still hoping there's an answer that includes getting the correct level short of maintaining a database of all quests (something I hope to create as a library someday soon). -g

If you are interested in a quest database please look at my addon Grail which is just that. My goal for it is to be a single addon that multiple quest addons can use to supply information as how quests relate to each other, NPCs involved for acceptance and turn in, and various other bits of information that are harder to get from API (if at all possible) like reputation gained, reputation required, profession required, etc. Basically the addon should be able to tell you when you can get a quest, where you can get it, etc.

[Gregity]

Is it a library-type addon? I was (am?) thinking of doing something very similar to what you just described. Sounds like you have most, if not all, of what I was thinking about. I'll be sure to grab a copy of Grail and check it out. Thanks!

I've been putting some thought into the design of the library as I've been doing the re-write of QuestGuru and so might as well share a few thoughts since the subject is broached.

My thought was to break the library into two or three chunks based upon the type of data so that addon authors not interested in various parts wouldn't have to load them, but others that were could get the data. For example Quest Completist uses data about what quests are dependent upon one another but QuestGuru doesn't need it at this stage of it's life. The library would provide some accessor functions and be easily compatible with Ace (even though not an Ace addon).

For the library-type idea I was thinking about it wouldn't have a UI (or even options). Addon developers could reference it as a dependency and use the accessor functions to get at the data. The library would monitor the log (and a few other events / quest functions) to self maintain and place new data (and deltas) in a separate savedvariables file to make it easy to upload deltas instead of the whole thing for maintenance.

I have been mulling over talking with the Wowhead folks to get access to their data and use it for a base and then create a feedback mechanism that would allow for deltas to be discovered and sent back, perhaps via the Wowhead updater. It's just plain silly that this data isn't easily available from Blizz but there it is... Would be nice to have something that pretty much updated itself by some sort of feedback mechanism. Considering that this site and the Wowhead site are part of the ZAM network, and that Wowhead does have an updater, the main infrastructure components to the library are at hand. Just a bit of packaging to preset the Wowhead data as an Addon. Who knows?

Anyway, I'm interested in hearing folks' thoughts on something like this. Perhaps a joint project to get it going?

[Nimhfree]

Grail is an addon, but is used as a library. It is not used as a library in the sense of addon authors embedding it in their own addon since it is 2MB in data files.

There is no UI for Grail. Instead addon authors would make use of it to provide the information they need in their own UIs. The addon Wholly provides the type of UI you would expect from addons like EveryQuest, Loremaster, Quest Completist or QuestHubber for example.

The intention of Grail is to be able to be extended by others to add features not currently present so addon authors that need specific things not currently provided by Grail can add them without the need for all who use Grail to use them. I had originally intended for the reputation information to be in a separate addon (like Grail-Reputations), but I put it in Grail a little while back because I wanted to make the deployment scenario a little easier for now. Luckily, that aspect can be split out pretty easily.

The data from Grail has come from wowhead, but has been updated over time since there are problems in the wowhead data. Basically, there is a mechanism within Grail to record "real" data is gathers that differs from what it thinks things should be. People can then send this data in to have the Grail database updated.

There are some design tradeoffs that have been made in Grail that are important to note.

(1) This is not one of those addons that attempts to be as small as possible. Its main goal is to be accurate and fast. It does things like compute the status of a quest and caches that until a situation happens that makes the addon need to re-evalutate the status. Of course it only computes the status of quests it needs (based on UI requirements, prerequisites, etc.).

(2) The addon is meant to be localized, and therefore since it does not get its quest or NPC names from the server, it needs to be updated when localization changes happen. I know how to get the quest names from the server at runtime. But I choose not to do so because one does not know which quests will be needed at any time, and there would be queries made to get the names which could result in UI addons not having localized names when needed. The same techniques cannot be used reliably for getting NPC names, so one may as well get them ahead of time so they are available.

(3) As much data as possible is computed from the "runtime" instead of being recomputed. For example, the start locations for quests is computed when the addon is loaded. This is done by looking at all the possible quest givers for the quest and using their possible start locations. In other words, the addon does not contain a list of quests that start in zones until it is computed when the addon loads.

(4) Grail attempt to be "live" so its picture of what quests are available, completed, etc. changes as events happen. This means that it monitors a lot more than what people may normally expect. It needs to know when the player level changes, when reputation with factions changes, etc. It attempts to do these things as efficiently as possible. The reason this is done is because Grail is probably the most accurate quest system available currently, and strives to be the most accurate. It handles most of the strange ways that Blizzard triggers quest availability like completing requirements for a quest (but not turning it in), flag quests, etc. It can handle NPCs that have the same NPC id but phase, quests that have the same quest ID but are from different NPCs, etc.

(5) The addon is currently in beta because there are changes happening to some of its internals. For example, the system to detect the presence of specific buffs is not present yet. This is needed because, a quest may not be available until a specific buff is present on the player (think of Winterspring). Once the rest of the trigger mechanisms are in place, and the proper invalidation of quests that require other quests in their quest log (incomplete or complete) is done and the finalization of the first release of public API is done then the addon will be a release version.

(6) The quest / NPC data in the addon is not perfect. It is constantly being updated as people quest and learn more about how the quests are related, etc. I have not been taking information from other quests like Quest Completist, Loremaster, WoW-Pro, etc. at this time since Grail data is pretty accurate, and as it is updated its database seems to be better in general than the others being used for the other addons. However, it would be much better for the community in general to use a single database for all these types of addons since only one database would need to be updated and it would become more accurate more quickly. I have approached different addon developers about the use of Grail, and have had mixed receptions. Some addon authors are of the mind that they do not want it because they did not invent it. Others have seen its potential but have seen that it is young and the APIs were not as fleshed out as they are now. Others have shown interest but are having time constraint issues.

(7) Grail suffers from being too accurate and using server query to get quest status. Blizzard does some things that makes life a little more difficult. For example, the starting quests of a specific name in Elwynn are all marked complete when a player does one, even the ones that are not available to the player's class. So, a server query will see them all as complete. Grail currently does not mark these as not complete (because of class problems) but it will in the next release I believe. This is not too bad of a problem, but an annoyance. What is a problem is the fact that there are other situations where Blizzard marks a lot of quests complete when the player in fact could get more than one of a set (like the Grateful Dead quests where a player could get one of three of them (race, Aldor/Scryer, and Dalaran)). Therefore, Grail records other specific quest completed information to handle some of these situations. For example, the fact that a quest has ever been completed is needed for the Firelands quests because the availability of certain quests depends on the knowledge that a quest has ever been completed (but need not be completed now since it is a daily quest that the server resets).

Basically Grail is designed to be the ultimate quest database. It may not contain all the information people want (for example, it does not record how often a player has completed a quest or when a quest was completed), but those features can be added by other addons. It is designed to be accurate and fast and global. In its quest for accuracy it is designed to handle all the things needed to be able to tell when quests are available. It is meant to be updated from user-provided data.

I would love to have help with the addon and am getting help from the community. However, more help would be great. For example, perhaps the reputation portion of the addon should be loadable on demand for those that want that information. However, I have no experience with a loadable on demand part of an addon and have not had any time to research it yet to see if it would save space, etc. Most of the things I have done have been trial and error. Learning about the needs of the calendar system (to know whether we are currently celebrating a holiday so the holiday quests can be available) was not a fun task, but at least it functions properly now. Therefore, community knowledge is a very helpful thing. The community has been able to give me some insight into things as I have come across them, but I am sure Grail can be improved and will be over time.

Enough rambling. I hope to hear your comments.

[Gregity]

Looks like you have done pretty much what I was thinking about - and more.

Do you have an API you can publish? I was looking at your addon page here and there wasn't any info on it. I haven't downloaded the addon and probably won't get to it until next week as things are rather busy here.

The load on demand stuff wasn't too difficult -- I'm doing it in the re-write of QuestGuru so that modules that folks don't want can be disabled from the options panel. The only problem is that each piece is it's own AddOn so it has its own separate folder. Makes things look larger than they really are. You can see things like DBM and others have gone that route. I have my optional modules dependent upon my core and the core loads them if they are selected. It wasn't too hard really - just a bit of bumbling around until I got the interaction straight. I'll have at least five when I'm done: the core, the log enhancer, the tracker, a party module, and a history module. The core keeps track of Quests and notifies the other modules when things happen. Building in my own Event System so the optional modules can register for info they want notification about and the core doesn't really care which ones are loaded.

In terms of my use of the data, I would want to be able to ask for all info related to QuestID aa or QuestName 'bbb'. For me, I was thinking the top level key to the data would be the QuestID. QuestName would be an alternate-index that would provide me with the key, and from there provide me with the proper QuestData. Similarly, getting an ObjectiveName (the part without the x/y) would return the QuestID and ObjectiveID where I could then look up whatever else I wanted. Likewise an ObjectiveItem would resolve to the QuestID & ObjectiveID. The Alternate indexes would be built at initial runtime so they would have proper localizations. Perhaps only the first time the Addon is run and then stored as part of the saved variables. A Person's locale rarely changes and that info could be kept as well and re-calculate the alternate-indexes if it changes.

The addon authors that are using your database as integral to their functionality have a valid concern that you might go poof. Some of this concern could be eased if they became project members I reckon but don't know. I know I don't want to really maintain all of the data you have, but am willing to help out and provide feedback to improve the data contents.

I'm pretty busy during the days and some weekends, but perhaps we can arrange a time to party up a toon and chat.

-g

[Nimhfree]

When I first started writing Grail I had put up some documentation for the API. But I soon found I needed to do more work to maintain the documentation that I did writing the code. Therefore, I have put off putting the latest documentation up until I am much closer to release. If you have specific questions or scenarios of possible usage I can easily help with that until I get the documentation and tutorials done.

I actually started to work on the LoadOnDemand stuff as an experiment and am almost done pulling out the reputation (earned) and achievement portions. So I have three addons for Grail now.

Grail uses questId as the key for quests. It turns out that the quest name is a problem because there are multiple quests with the same name, but as it happens multiple quests with the same name from the same quest giver. The Grail questId maps directly to Blizzard quest IDs except for a very few rare "alias" quests that have an internal questId and an alias marker to the actual Blizzard questId.

Likewise Grail uses the Blizzard npcId for NPCs except for alias NPCs (which primarily handle phasing). But items and world objects are also represented internally as NPCs as well. Their Blizzard IDs are just translated into a specific range of Grail npcIds.

I am sure we can arrange a time to chat.