I’ve decided to write a series of posts outlining some of the techniques I used in creating LoLTool. These will mostly focus on explaining some of the reverse-engineering of the League of Legends client required to make stuff work. This first post will explain how I get the item data used to display items in the Recommended Items Editor (RIE).
This particular piece of code recently underwent some major changes due to Riot changing the client (thanks Rito!). For context the way I initially got the data was through reading the SQLite database file called “gameStats_en_US.sqlite” that comes with the LoL client. This contained a table with all the items and various attributes (like cost and the description). This worked great for the most part but after one of the recent patches this data was no longer included (the database file still exists and still contains a table for items but the table is simply empty).
With the previous source of data no longer available I began searching for other sources. Some item data is included in a file called “ItemDataPack.swf” in JSON format, but this was incomplete and not good enough for my purposes. I considered creating my own database file and distributing it with LoLTool but this would mean after every patch I would have to manually update this file. This would be a lot of extra work for me and if I happened to be busy at the time it might mean that item information isn’t updated for a few weeks after a patch. Not a good solution.
While stuck with this I decided to take a look to see if I could extract the data I needed using the official Riot API. I had already been looking at the this for a potential player statistics plugin for LoLTool so I had some idea of what it could do. It turned out that getting the item data was actually very easy, the only small hindrance being that it came in JSON format. I had previously decoded JSON using the .NET built-in JSON deserialization library but this requires writing a custom deserializer for every bit of JSON you want to process. It works sure, but it isn’t fun. This is when I stumbled upon the NewtonSoft Json.NET library. Wow, what a difference a good library makes! I went from being annoyed at JSON to loving it in no time. With Json.NET all it takes to decode a JSON object is creating a class with getter/setter methods for each of the JSON properties and a call to deserialize and you are done. It does all the magic work for you. You can even do a partial implementation and it will only decode those properties that you have created accessors for. So if you find yourself working with JSON in C# I wholeheartedly recommend using the Json.NET library to do so, it will make your life much easier. Seriously, after downloading the JSON code all that is required to parse it are the following lines of code:
JObject jo = JObject.Parse( json );
JToken itemData = jo["data"];
Dictionary<int, JItem> itemsDict = JsonConvert.DeserializeObject<Dictionary<int, JItem>>(itemData.ToString());
foreach( JItem ji in itemsDict.Values )
{
if( ji.Gold.Purchasable )
items.Add( ji );
}
Where JItem is just a class I created with accessor properties matching the names of the properties in the item JSON (found in the Riot API documentation). Easy.
The next thing I did was to update the category filters (the checkboxes found in the Recommended Items Editor) to be automatically generated from the tags attribute found in the items data. After this was done a problem remained: there were a bunch of items that shouldn’t be there like Attack Upgrade I, Attack Upgrade II and so on. Yeah, the Blackmarket Brawler items and brawler upgrades (though this was before this mode was released, so I was a little confused at first). While some of these were tagged correctly as Blackmarket Brawler items, most were not (thanks Rito!). So I had to manually go through and identify all of these special items and include them in a special exclusion list that is used to filter these items out. For now this is hardcoded into the program, although I might turn this into some sort of text file (XML, or maybe CSV) in the future so it can be updated without recompiling the core program.
The last problem that I had to overcome was that the image names included with the item data didn’t always match the image names of the items that I was using (extracted from “ImagePack_items.swf” – the topic of a future Inside LoLTool discussion). 80-90% of items had the correct images after using some fuzzy matching but a few were still completely wrong (once again, thanks Rito!). Pretty much all the jungling items were wrong, several boot enchants, the Doran’s items were wrong and a few others like Void Staff. To fix these I extracted the images from the SWF file and then went through manually matching each item with the correct image. For each item that needed to be changed a replacement rule was hardcoded in to use the correct image name instead of the one supplied through the Riot API. Of course this means that the next time Riot decide to make sweeping changes to itemization it is likely that I’ll have to go back in and update some of these replacement rules (again, these should probably be moved to some sort of text data file that can be easily updated without recompilation).
Hopefully this post will give you some insights into what goes into making LoLTool work under the hood.
