This project is read-only.

Immediate Efforts after 0.0.5 [Beta]

Feb 14, 2008 at 7:36 PM
Edited Feb 14, 2008 at 7:37 PM
I've been trying to keep up with these post-release activity discussions... I have failed.

The next release will incorporate a few short-term efforts with long term goals.

Database Stuff

For starters, each table in the database that is information lookup or library related is going to start their incremental seed at 1 million. I'm doing this so that if DKP manager choose to maintain their own libraries of instances, mobs, items, and drops, this can be done without conflicting with a public library I am about to make available.

The public library starts at seed 1, and consists of a bunch of insert statements which load the database. Since the identity column is a primary key, and the name columns are uniqueness constrained, the seed difference is needed to allow people to swing both ways.

For instance, let's say the next expansion comes out and some DKP manager goes to town making items. Other managers may not be as ambitious, so they're going to wait for me to make a library update. If the seeds start at the same number, eventually my ItemID's will conflict with the ambitious DKP manager's ItemID's. However, if his or her seed starts at 1 million and mine starts at 1, the ItemID's won't conflict for a very, very long time.

So what happens if the ambitious DKP manager makes an item that I eventually make in the library, and the DKP manager wants to use the library update? Not a problem! Every table is also constrained on name. So if the manager has created "Boots of One-Legged Butt Kicking" and I've made the same item, but they're at different ItemID's, the library's "INSERT" for that item will fail because a record already exists that uses that item name. Likewise for Mobs and Instances. Drops are dependent, so if the item or mob doesn't make it in using the Library's ID's, the drops won't be added.

In this way, stuff in the library missed by the DKP manager will be added to their system. Stuff already in the DKP manager's system will remain intact.

User Interface

I've never really been happy with the user interface for the data grids, so I'm taking a different approach. The release will use a style that's more in line with the website I use for demonstrations:

Eventually, I hope to have some style guides. For the artists using this module, please let me know what you find constraining, so we can make a module with better curb appeal.

Public Library

I have tested the next release's data library. This will be the first release that comes with a library and contains boss drops from Karazhan, Zul'Aman, and Grull's Lair. I forgot about the trash drops, so I'll hopefully have those added soon. The library right now contains no DKP values, just the rest of the stuff.

Armory Parsing

I know there are some nice armory parsers out there, but I'm not really happy about making this project dependent on other projects. Adding an XML parser is old-hat anyways, so I'm hoping to get a parser working for player names that will help extract most of the player information. Till then, manually add it.
Feb 25, 2008 at 5:16 PM
User Interface
I have to agree on the data grids - they've been giving me nasty nasty heartburn on my project. I'm starting to lean more towards using all-Javascript on the client and JSON-based web services in the middle, but I'm quite interested in where you're thinking of taking this.

Armory Parsing
You're not too far off waiting on this. The Armory is in flux and is as much down as it is up at the moment. I have been playing with LINQ for XML to parse the Armory and really like it -- but it introduces a dependency of .NET v3.5 on the web server. I think that is the cleanest route, personally - in terms of lines of code, performance, and over all elegance.

Database Stuff
Ultimately, I think your ItemIDs should try to match the WoW ItemIDs, and ideally try to drive back to that. I would think that the identity column ID should be immaterial/meaningless, and that updates from you could be passed either as an XML file or LUA or something, be downloadable (as opposed to waiting for a new version of the module), and have some loading logic in your code that does a lookup based on the WowItemId or name, then does an update (or some form of synchronization or conflict management) off of that. If you have uniqueness enforcements, sync logic should handle it perfectly.

Using the above, folks could potentially also use some sort of 'export' mechanism to bring out their custom objects for sharing with the DNN DKP community...which could be pretty cool.
Feb 27, 2008 at 5:44 AM
In the next version, I'm adding a section to the top level menu called "tools". There will be some different calculators and other things. Certainly importing and exporting the database data could be part of that.

I'm currently looking at taking the Item DKP calulator out of HoB DKP and using that to generate base DKP values for items.

As far as the data grid goes, I managed to fix everything I wanted to address, although I'm still not happy with the final code.