This lead to a lot of duplicated effort as we were scanning the player’s bags multiple times to track the various pieces of data which we care about.

In TSM3, the code which tracked this information was scattered across multiple places in the codebase, and the data was stored in a variety of different lua tables, each with their own structure. For each slot of a player’s bags which contains an item, there is a well-defined set of attributes which we care about:

This dataset is used for many things including calculating inventory quantities for display in tooltips and use in varying features such as restocking via Crafting and determining what items can be posted on the auction house with an Auctioning Post Scan. One of the things which TSM tracks is the exact contents of the player’s bags. Let’s dive into how our database library accomplishes these things. Another goal was to be able to connect UI elements to underlying data in a standard way which would allow the UI to update itself automatically when there are changes to the underlying data. Our main motivation for creating this database library was to make it easier to represent large datasets in a very structured way which could easily be consumed by the higher-level application logic.

This new database library is made possible by the class library which I discussed in a previous blog post. This is an internal code library which makes it easier for us to implement new features in TSM4. This is another very technical blog post which provides a look into the new database library which has been added to the TSM codebase with TSM4.

Warcraft tradeskillmaster