First of all, my apologies for not posting in over two months. My main focus has been working on the Six Minutes To Release website and related functions. Believe me when I say I've poured a lot of time into this.

On the heels of my LibBeImba project, I needed a more robust way to access the World of Warcraft Armory than I have been on the website. My research led me to the fact that they are using XML and XLT files to create their web pages, thus leaving the XML data exposed. In addition, using Fiddler, I have been able to find additional files behind the scenes that allow me to mine even more XML data. Serializing the XML in lieu of an XSD and then presenting the information in a developer-friendly format has led me to create the LibWowArmory project, still in development.

So today I went to take a look at the talents, figuring they were in XML as well. Well, this:



isn't exact useful data. Turns out that string is parsed via JavaScript, and the talent calculator, instead of being created by XML and XLT, is generated on the client side via JavaScript. This included all of the static data, including the names of the talent trees, the individual talents, and the actual tooltip text you get when you mouse over the talents on the page. Very unArmorylike. And very inaccessable from VB.Net. At least, initially.

A while back I had done a bit of work with compiling .Net assemblies on the fly, and had began to wonder if I could somehow take the JavaScript that Blizzard was using, convert it to some .Net-equivalent language, and mine the data through reflection. After looking into JScript.Net and doing a refresher on Reflection, it only took me a couple of hours to come up with this code:



There's a bit to talk about in here, so I'll go ahead and explain the code.

First, JScript.Net differs from JavaScript in that all variables must be defined. That's essentially what I'm doing with that big long line just after declaring lstSource. All of those variables need to be declared, otherwise the code will not compile. Interesting to note that "document" needs to be declared, since we're not running from within the scope of a web page. Fortunately, I'm not doing anything with the document object, so I'm not going to run into any runtime errors accessing the document.

Next, I download all of the necessary code from Blizzard. The second one has a lot of useless functions, but it does have a couple functions that are used in the last two. Those two files contain all of the talents for the specified class.

The next section compiles the code using the JScript CodeDomProvider. The following section actually runs the main module of the assembly, instantiating all the variables and allowing the functions to run. Most of Blizzard's code is written in the global scope, so most of that code runs. This is where the data from the data.js and donotlocalize.js files are put into memory.

Now we have to use reflection to get the type. After some debugging, I found that the type named "JScript 0" is the one with the data I'm interested in. So, using LINQ, I grab that type from the assembly.

Now we get to pull the data we want. I get the FieldInfo object from the type, again using reflection to make it easy to cherry pick the correct field. Then I can use FieldInfo.GetValue to grab my value and...

Not so fast.

Because the assembly I'm pulling from is in JScript.Net, arrays are not of type System.Array, but rather Microsoft.JScript.ArrayObject. This is a monolithic array type that really doesn't let you play around much with it. Trying to LINQ from it doesn't give you the data, you actually have to call the data through the Item property.

Fortunately, JScript.Net provides a way to change ArrayObjects to normal Arrays, via the ToNativeArray function. I packaged this all up into a recursive function called Unbox. This takes an object and spits the object back out if it's not an ArrayObject. However, if it is an ArrayObject, it converts it into a List(Of Object) using some trickery. Note that it tries to unbox each object that it inserts into the list. This is because Blizzard likes nesting arrays, so I needed to make sure that every ArrayObject inside is put into a more friendly list object.

The idea is to cache this data so I don't have to spam Blizzard for their JavaScript files every time I need to access a player's talents, something I already have a bit of a framework setup to do in LibWowArmory.

The result is I can now take that very ugly talentTree XML node, split the string up into individual characters, and assign each of those numbers to each of the character's talents to learn exactly what their build looks like in code.

All in all, I'm pretty happy with my work on this, and plan to release LibWowArmory soon with item search and lookup, as well as player search, lookup, and talent inspection. Further, I am now able to apply the power of the Armory to my own website in an easy-to-use library in what should be a write-and-forget library, much like LibBeImba turned out to be.

I would be doing this post an injustice if I didn't talk about how the guild is doing. So far, we've cleared about half of Naxxramas 10 as people are still working on leveling up. We've also taken out Sartharion 10 with no drakes, and are farming Archavon 10 when we can as well. Wrath of the Lich King brought some great content into the game, succeeding in many places where, in my opinion, Burning Crusade just failed miserably. I'm really happy with this expansion so far, as is Kathy, and it's something we continue to enjoy together, something that's more important to us than the game itself.