The Missing Diplomat appears before the previous quest is completed.

I think I figured out what is happening here. The requirement values are actually as they should be, this is on the one hand an issue with combination of Title and Objectives fields being a surjective but not an injective function for quest lookup, and on the other hand an issue with quest 1248 and 1250 having the same values for these fields and how Lua works.

Due to Lua tables using unique keys, the QuestieLevLookup["The Missing Diplomat"] table will only contain one value with the key ["Speak to Mikhail in the Wetlands."] at runtime, namely quest 1250. Therefore when you finish quest 1248, quest 1250 will be marked as finished instead. This means that quest 1249 won't ever show as available on the map and quest 1264 is shown immediately after 1249 is finished.

In this particular case it shouldn't really matter, because all of the quests happen in or around the tavern in Menethil and you basically can't miss anything if you look around or read the quest texts.

But this is a general problem for quests that have a non-unique combination of the Title and Objectives fields. One approach would be to check who or what the quest was acquired from and use that for the lookup. Another would be to use the Details field in the lookup, which helps but is non-injective as well and also not trivial, because that text field uses wild cards for variables like race, class, etc. (See shagu/pfQuest#29). Also it would require a DB update, while the information on who starts a quest is already present. Sadly I'm not sure if that combination (Title, Objectives and quest giver) can be used for a bijective lookup function.

Could be similar to an issue I fixed in commit a300c38 with the Beached Sea Creatures quests.

@Muehe 0_o Can the poor little uneducated people get that in English? Love you buddy...

I ran into this issue a LONG time ago and it's why I was pushing Aero and Logan to update the crawler so we could build a new database. For other folks who don't understand programming reading this... It's not that we can't lookup a quest in the database by quest giver first... we can't. The quest lookup function matches Quest Title then Quest Description to obtain the Quests unique hash. If there is a quest with tons of steps and no unique quest title then it returns the first one it happens upon - it seems random but it's not and I don't recall how its returned exactly. There are some quests in the DB that has no description to match so if it encounters a nil value it checks the distance to each objective and shows the closest one on the map. It's dirty but it works most of time.

This is a very simplified description so don't butcher me on it. :) Quest look-ups occur like this...

[Quest Title] --> [Quest Description] --> [Quest Hash]

Sometimes the Quest Title and Description are the same so again the first hash it happens upon is returned. We can't do a "reverse" look-up... :(

I wanted to build a database with real QuestID's rather than a unique Questie Hash. For example... most of all the "Vanilla Quest DB's" on the web all use the same ID:

https://vanilla-twinhead.twinstar.cz/?quest=1248
https://db.vanillagaming.org/?quest=1248
http://endb.wow-atlantida.com/?quest=1248

Then our lookup tables would be structured like this and have a unique identifier to specifically return a single hit. This would allow Questie to work on any server better then it does now and allow us to create localized versions

[QuestID] [Quest Title] [Quest Description (English), Quest Description (German)] [Faction] [Type] etc...

...again there is a technical reason why the DB is currently in it's present form, I just don't recall the detailed conversation Logan, Aero and I had last year about it.

Questie's original DB was created during Wow's Burning Crusade Retail and was built upon a culmination of DB's from different sources and user submissions. Hence the reason that there are still some references to BC quests in the DB and some of the Vanilla quests are wrong. Most have been corrected manually over the years.

I think the main reason the questie database is structured the way it is is because the world of warcraft vanilla API doesn't return the questID. The only way for us to get info about a quest in someone's quest log is by whatever information is available on the quest (title, level, tag) and its objectives (description, type).

So even if we were to store quests in the questie database as [questID] = { Title: "", RequiredQuest: } (which would certainly be beneficial), when it comes down to it, we'll still have to convert <title,description,level> into questID since the API doesn't provide it.

Yeah, that is the problem exactly. Sadly there isn't much that can be done apart from extending the server side API.

But we could increase lookup accuracy by keeping a constant "copy" of the questlog (which we already do I think) and then hooking into the quest accept button and checking which NPC/Object/Item the player is interacting with (which is the quest giver). We would have to make sure there are no random lookups between "real" quest log changes though, overwriting the information gathered this way.

Also I haven't done any in depth analysis on which values are available and if they would constitute a unique mapping, but I know guest giver would solve some cases (like the one here). By the way, NPC names are nearly unique. There are only 19 non-unique names and they are for some removed mounts IIRC.