by Ludovicus_MaiorSo there are two problems to be solved. Lets take a quest: Missing in the Ghostlands, given by “Magistrix Landra Dawnstrider” and turned into “Courier Dawnstrider”.
Now each of these NPC’s has a unique ID (16210 and 16183) just like the quest is uniquely identified by its ID (9144).
Now in German, the quest is called Verschollen in den Geisterlanden and the NPCs are “Magistrix Landra Morgenwandler” and “Kurier Morgenwandler” respectively.
Now if you know a little bit of English, you might be able to guess that Dawnstrider and Morgenwandler are direct transliterations, but let me assure you that some of the names do not have such a direct mapping.
So what to do? Well, we could try Just In Time Localization. What the heck is that? Well, Blizzard does not supply an API that maps NPC ids to the localized names. However, when you select a NPC as a target, the function UnitGUID(“target”) can be used to get the GUID for the target. Buried inside the GUID is the NPC id. We can also get the name of the target with UnitName(“target”). So by adding a NPC tag to the guide steps, we can dynamically build a database of NPC/Locale mappings to names once you select a target.
Similarly, the Blizzard API’s let us ask what quests are available from an NPC via GetGossipAvailableQuests() (which returns the localized quest names) and then we can do SelectAvailableQuest(index) which fires off a QUEST_DETAIL event, which then can be used to do a GetQuestID() to get the actual ID. Now we can build the map between the quest ID and the localized names.
This, by the way, means that it may be possible to do automatic quest selection, accepting and turnin (when there are no choices to be made) and avoid most of the NPC dialogues.
So what would this new guide line look like?
A ;Missing in the Ghostlands |QID|9144|M|44.06,70.73|NPC|16210;Magistrix Landra Dawnstrider|Z|Eversong Woods|
The first semicolon in the title says “Use this quest name unless you have a better one”. The NPC id gives the desired NPC, and the string after the semicolon gives the name to use until you know better. Since no N text was given, we would automatically generate “Von Magistrix Landra Morgenwandler” and “Um Magistrix Landra Morgenwandler” and basically just keep a short “To/From” dictionary for the client languages.
A step with objectives would look like:
C ;Investigate the Amani Catacombs|QID|9193|S|NC|U|22755|QO|1;Mummified Troll Remains Burned: 10/10|M|62.92,32.46|Z|Amani Catacombs|N|Burn the Troll remains as you go.|
Again, the title would be substituted with the name gathered from the A step. The two part objective says: look up the first objective and use the completion from GetQuestLogLeaderBoard() instead of the literal string. The text is really more documentation and a check in the english client to catch Blizzard if they change the objective order.
¿What do folks think?
We should chat …I sent you a PM, tepes. Lets chat offline.
Grail will be converted toGrail will be converted to using map IDs once I get the last four dungeon ones I am missing. I have been converting the map coordinates to two digits as well. In fact, I use the fact that NPCs have one digit or less to mean that I personally have not checked that NPC yet. Those that have two digits have had one of my players stand on them. Instead of radii I actually pick points along their path. For a simple path back and forth I usually pick the two end points if the path is short enough, more for longer paths. More complex paths get more points. I had imagined that you could pull back the entire table of points for an NPC and have TomTom display them all or you can choose to display just one. I had never considered floor information. I would imagine I would just add another key for an NPC to indicate its floor as so few NPCs would have this.Yes, it would be a big change. I had imagined initially not changing any of the guide files, but instead changing the addon to use Grail when it encounters an A line for example. It could detect the QID and pull the quest name, NPC name and NPC location from Grail (ignoring that information specified in the guide file). At first as an experiment it would ignore the information in the N but it could also be coded to look for a new note code so any notes that were really important could be changed from N to this new code to ensure they would display. As grail’s names are meant to be localized the addon code would never need to know what language was being used except for using “von”, etc. as appropriate.
Hmm, Looking at GrailHmm, Grail does have all of the information I was whining about, and more. It looks like the conversion to start using map ids has started. I do not see floors in the coordinates, which nice for some NPCs in Orgrimmar’s Cleft of Shadow or in Dalaran. We had also started to push two digits of precision for all the coordinates. I literally went and stood on top of the various NPCs as I worked through the guides to get the better info. I was also thinking of including radii in the NPC locations to account for wanderers.But, just like I have been working with the chap that does TomTom since January to make our interaction cleaner, I could imagine that we could work together and carve out our niches. But that is a bigger project than I was contemplating for my “simple” localization project. However, it is something to consider after we clean up our multiple parsers.We would never convert down to an “AQ9144” notation as we have human beings editing these files, and nominally we are all English speakers. It helps us to edit these files to have redundant information so we can make sense of editing the quest sequences. However, using something like Grail would let us default much of the information. So in the new world:=A;Missing in the Ghostlands|QID=9144|N=She is up in the treehouse.|Grail could supply the map coords (id,floor,x,y) for the NPC, check class/race/rep/profession eligibility as part of the DB. If we could trim the quest line to that, and display “Verschollen in den Geisterlanden” as the quest name and have the note say “Von Magistrix Landra Morgenwandler. She is up in the treehouse.“, I would be a happy camper.But I could not make this decision alone. Big change!
Yes, the concept of unifyingYes, the concept of unifying a lot of functionality is what things like the Ace libraries is all about. And that was my motivation with Grail…to provide the needed functionality for a lot of quest information for other addons to use. In developing it, I have discovered ways to handle things like quests that are completed without ever appearing in the quest log, like the Elder quests, and I have tried to unify things simply so addons that use it can not worry about processing Blizzard events associated with quests, but can register with Grail to be notified when things of interest happen. Of course Grail does not provide all quest information like the leader board stuff, but I imagine either addons that need to make use of more information or another addon library can extend the concept of Grail to include things like this.
Just my 2 centsI Love the addon and I’ve tried making a guide witht he recorder without much luck. Anyhow I’ve used Lightheaded forever it seems. The localations for some quest givers an turn in are not correct and using something like grail or LH isn’t terrible for correcting NPC locales. I already use a ton of addons and often wonder how many of my addons are pulling some of the same functions as others. Would be nice to cut those out streamlining everything.
The value of the addon isThe value of the addon is definitely sequencing, locating quest items and hints. The downfall of the addon is the database you have implicitly encoded in your guide files. There are quest giver locations that are incorrect, etc. The purpose of Grail is to provide the data that is inaccurate in your addon, and remove the redundancies.The data in Grail was initially scraped from wowhead, but is being constantly updated based on real world testing. One really good thing about it is that it can handle quest givers that change locations. For example, asking for a quest giver associated with the Darkmoon Faire will give the location of the quest giver based on where the Faire currently is. Or, those quest givers that change location based on their phase, but still have the same Blizzard ID, are handled properly in Grail so you do not get pointed back to where the NPC used to be in a previous phase. Another good thing is its prerequisites actually exist and are being updated constantly. This allows you to conceptually come into the middle of a guide and actually know what quests cannot be completed, etc. based on the player’s quest completion history and prerequisites. For example, I have found that coming into the middle of the Nagrand guide was a bit offputting because I had not done some quests from Terrokar/Shattrath to lead into Nagrand.One of the benefits I can see is guides can be created that are still zone specific but are not specific to faction or other choices made like Aldor or Frenzyheart. With a little coding detection can be made that a quest cannot be taken because it is for Horde or Scryer or whatever, and not even be presented to the user as an option. With a database of quests this is quite easily done. The same goes for gender specific quests, class specific, profession, etc. All can be in one guide per zone (if you still want to differentiate that way), and quests can automatically be eliminated from the list based on the player’s information. You already to that in a way by checking completed quests, but with the proper database you can unify your guides, and provide more comprehensive ones.Using the JIT approach is perfectly valid and will get you to the OP’s goal quite quickly. The only issue is that you need to play a little game with communicating with the server to get the information. I have found that doing so for quests works quite well. For NPCs it is a little more hit and miss. I had thought that for Grail this would not work because the design goal is to have all the data available immediately, and not rely on interacting with the server to update itself. This means that the initial load of data is larger, but I believe the tradeoff is a good one. If one were to ask for all the quest information over the lifetime of a playing session, the information would have to be retrieved from the server and stored in memory as well, which means you would still be occupying 4 MB of RAM.Originally I started working on Grail because I saw the flaws in this addon and I wanted to improve them. As test cases I have started porting other quest addons to use Grail instead of their own internal databases. This is to ensure the API and data provide what they need. My initial API design was to satisfy the needs of this addon. Eventually, once I have tested a couple more quest addons against Grail I will most likely make a limited port of this addon to use Grail as an example. However, I want to make sure the API I have covers things pretty well before I go down that path.Enjoy.
The UnHoly GrailYeah, there are addons with information, but Grail is like 4.3 MB in size and you don’t know what the quality of the infromation is. Just perusing some of the files seems to indicate that the data is manually entered, as the support for Chineese or Korean is nonexistent.We certainly find errors in WowHeads information quite regularly.The JIT approach would work day 1, and if we stuck away the data where users could give it back to us, we could choose to build our own and work from day 0 for some locales.Furthermore, we could use it to track changes or deviations from what we expected.I think the value in our addon is the sequencing of the quests, the locations associated with each step and the occasional hint.
Yes, that is a problem. IfYes, that is a problem. If the goal is to move away from requiring another addon, the whole concept of Grail is not going to help. However, I find that the amount of data that is reproduced across multiple addons with regard to a quest/NPC database is ridiculous and wastes people’s time updating. So, having one central source that has more accurate data as time goes on would allow more addons to concentrate on what they are good at instead of wasting time updating an NPC location or a quest dependency, etc.
I took a look at Grail, itI took a look at [url=http://wow.curse.com/downloads/wow-addons/details/grail.aspx]Grail[/url], it has a good database for the NPCs, but would that addon be required to use it? I thought we were trying to move away from dependency on other addons, like Lightheaded and eventually TomTom?
This is exactly what Grail isThis is exactly what Grail is for. However, the real purpose would be to change the whole line in the file to be something like AQ9144 which would mean acquire quest 9144. Grail would provide the data of the quest name and the NPC name and its location. The C step would still have more information in it, but the turn in would be something like TQ9144. All the repeated information that Grail provides can be eliminated from the quest files. What gets really interesting is Grail can provide enough information that should allow a single file to handle both Aldor and Scryer for example.
It’s been awhile since I’veIt’s been awhile since I’ve actually used it, but doesn’t Lightheaded have an NPC listing? Plus it seems that Wowhead.com uses the NPC id as the link, such as Magistrix Landra Dawnstrider = http://www.wowhead.com/npc=16210
EDIT: Ok, just looked, and Lightheaded does in fact have all the NPCs and their respective ids. The LH_NPCData.lua contains all the IDs and waypoints for them. While the LH_Data_A-E contains both the name and the ID. In the following format, npcUSOverlord Mor’ghorUS23139 (The US is something that is showing up on my Notepad++.)