This project is read-only.

DKP for DotNetNuke® 0.1.9

Oct 6, 2009 at 3:31 PM

So... it's that time again... time to patch crap!

But, for the long wait, I'm also adding some features. No, filtering isn't there yet. Commence the stone throwing! However, there will be the first of hopefully many new loot system mechanics. Loot system mechanics can be selected from the Boards panel, and for now the standard item value system and a new percentage based system can be selected. For those not in the know, percentage based systems are a mid-way point between standard fixed cost systems and Suicide Kings style systems where every item costs 100% of the DKP you have at the time. Heck, I might just add Suicide Kings as a third option for this release. I'll have to see.

There's also some kinks being worked out in the syncronization tools.

Expect this update in a day or two.

Oct 7, 2009 at 8:33 AM

Forgot to add... during the next few days, the demo site will be working off and on as the new code is rolled out.

The only thing left to do is update the database triggers that calculate DKP. User interfaces are finished, existing stored procedures have been updated. I'll also be adding a third loot mechanism, Suicide Kings.

Oct 8, 2009 at 4:59 AM

Ugh...

Okay, I'm going to engage the nerd rage. The mod's going to be drastically changed. Here's what is changing...

The whole notion of the "Check if heroic" flag for Instances is a bunch of hand-waving. This "feature" is being replaced with two drop down boxes.

Now, when you create an instance, you will specify two new values: the size (10/25/both) of the raid you wish to track and the mode (heroic/normal/both) of the instance. Syncing will only work for what you specify that you wish to track.

Now for the rage... what do we do with our current system? Well, originally "check if heroic" was being applied to a post-BT era where there was a 10 man Naxx and a 25 (heroic) Naxx. The issue is that now WoWHead consider's that era of heroics as "normals" in loot tables. So that means that if you had checked an instance as "heroic" in our mod, we would essentially set the size value to "both" and the new mode value to "normal".

So since I'm a visual person... to get all the loot from the following zones you would set the following for each:

Black Temple - size = 25, mode = normal

Naxx - size = both, mode = normal

Ulduar - size = both, mode = normal

Trials of the Crusader - size = both, mode = both

Make sense?

Oct 9, 2009 at 6:50 AM

So I was out of my mind when I posted the above. We're NOT doing THAT crap.

The reason is simple. If we adopt WoWHead's raid naming convention, we'll break every raid importer on the market. I honestly don't know why WoWHead took the direction they did, but it's wrong.

There isn't one instance named Trial of the Crusader... there's two. Trial of the Crusader and the Trial of the Grand Crusader. It still fits the Naxx/Ulduar model, so for now, things will stay as is.

Oct 11, 2009 at 6:16 AM

I took another look at WoWHead and I think I have a solution. I'm not really sure why I didn't think of it earlier, and I believe it has the possibility of completely eliminating our dependancy on "check if heroic"...

The solution is that the dkp module will identify what era the raid is from, and we can do this by taking advantage of a change WoWHead made to their database with ToC.

If you look at the xml from WowHead, you can see the how we will do this:

Anything pre-WotLK identifies the drop table by the phrase "drops"....

Anything WotLK but pre-ToC identifies the drop tables by the phrases "normal-10-drops" and "normal-25-drops"

Anything ToC+ identifies the drop tables by the phrases "normal-10-drops", "normal-25-drops", "heroic-10-drops" and "heroic-25-drops"

This is how WoWHead is allowed to identify the 4 instances of ToC and ToGC as one instance, ToC.

The update is coming along fine. Multiple DKP mechanics are now support. The list currently includes Standard (item costs are fixed), Percent (item costs are based on a percentage of player's saved DKP), and Suicide Kings (items always cost 100% of a players saved DKP).

The DKP mechanism is applied as you are creating the loot. As a result, regardless of the DKP mechanism used, all "charges" to the players look the same - a raw debit of X amount of DKP. As a result, you can make a loot while using Standard... switch your board to Percentage... use percentage for a while... and then if you need to reverse that loot you created while in the Standard mechanism.. you still can. It's pretty slick. You can basically change the Board Loot System whenever you want and it works fine with DKP history created in other systems.

Oct 11, 2009 at 7:12 PM

So the above thought works, but a change is needed.

The "Check if Heroic" will still be needed, but the meaning will be changing. The reason is this...

Let's say we wanted a DKp system that was compliant with WoWHead and WoW Raid Trackers. WoW Raid Trackers are always focused on the Zone Name, so that's where we run into the Trial of the Crusader versus Trial of the Grand Crusader. WoWhead on the otherhand, doesn't care about there being two different instances. They just roll everything into Trial of the Crusader. That's fine, because we don't care what WoWHead calls the zone, but we do care about the Zone number, which happens to be 4722.

So in our system we make two instances... Trial of the Crusader and Trial of the Grand Crusader. We tie each instance to the same zone id (4722)... now you see the problem. Which mob/loot tables go with which instance? WoWHead defines 4 loot tables for this instance, so we need to someone work that out.

Fortunately, we have the heroic flag... which will be changed to read "Check if heroic loot."... now you see how we can identify which loot tables go with which instance.

The sad thing is that if WoWHead actually made two instances... or if WoW somehow named these four zones the same thing... none of this would be needed. Most unfortunate.

Oct 18, 2009 at 12:47 PM

Any possibility of more multi-game stuff making its way into 0.1.9? I had hacked 0.1.8 to work with LotRO (well, mostly—haven't converted the sync stuff over yet) but I'd rather do it right this time around, especially since I'm looking at starting to put together a SWTOR site as well (yes, I know they haven't released enough info to correctly populate a DKP system yet, I'm just thinking that Idon't want to have to hack the system even more so that I can run two different games on the same host.)

Oct 18, 2009 at 5:47 PM

As I've said before over the years, I'm interested in doing multi-game support, but as I only play WoW, I'm not familiar with other games.

There's certainly parts of the module that are fairly generic, and then there are parts that have an implied interface with WoW.

Multi-game support really just involves controlling the implied interface portions based on the game for that board.

Share some deetails of what you've done and I can see what I can do to support them more officially.

Oct 18, 2009 at 10:49 PM

As you noted, some of it is fairly generic, some…not so much. Doing a 1:1 hack is relatively easy:

  • replace any instance of World of Warcraft with Lord of the Rings Online
  • replace the classes with Burglar, Captain, Champion, Guardian, Hunter, Lore-master, Minstrel, Rune-keeper, Warden
  • replace the levels with 1-65
  • replace the races with Dwarf, Elf, Hobbit, Man
  • replace the WoWHead JavaScript reference with <script type="text/javascript" src="http://content.level3.turbine.com/sites/lorebook.lotro.com/js/onering.js"></script>
  • replace references to http://www.wowhead.com/?*= with http://lorebook.lotro.com/wiki/

Now the tricky part is in doing it in an extensible way. I tried this morning to handle the player boards correctly—replaced class names with asp:Literals, fill them on page bind—but I seem to have broken something, and I'm not sure what.

What I tried doing was using tss_DKP.GetClasses(objExistingBoard.GameID) to populate a List(Of String), .Sort() the list, then iterate through the list to populate the literals and bind the appropriate data. For some reason that's returning an index out of bounds error.

Oct 18, 2009 at 11:28 PM

D'oh, nevermind, I figured out what I broke—it wasn't the player class code, it was the WoWHead/Lorebook link alternation code, of all things. I think I've now got a working version of 0.1.8 that will work for both WoW and LotRO at the same time. Is there a way I can get the code to you to see if it'd be possible to implement officially for 0.1.9 (or 0.2.0, or…)?

Oct 19, 2009 at 4:27 AM

I think the data for supporting the game is pretty straight forward. There shouldn't be a problem adding things, but like getting WoW up and running, this would be a work in progress.

Since this issue is more related to suppoort for a new game, I'll finish up our lingering WoW related problems, publish 1.9, and then we can work on 2.0 and support for LotR Online.

Oct 19, 2009 at 10:31 AM

Sounds reasonable. And it gives me time to do stuff like implement all of the dynamic "hide/rename this if the game isn't WoW" stuff. ;)