Deathbringer's Will

Topics: Rawr.Base.Items
Dec 9, 2009 at 3:08 PM

We got a Deathbringer's Will last night.  That's the trinket with passive arpen and a proc that changes your form and gives you one of six procs:

  • 600str or 1200ap
  • 600arp or 600crit
  • 600haste or 600agi

It went to a MM hunter, and he only saw 3 of the procs: 600agi, 600crit, 1200ap.  Need more data to know what other classes/specs get.

Dec 9, 2009 at 3:31 PM
Edited Dec 9, 2009 at 3:32 PM

http://elitistjerks.com/f73/t36932-feral_questions/p33/#post1484662

 

Copy/paste from EJ druid forums. He's feral - http://www.wowarmory.com/character-sheet.xml?r=Bleeding%20Hollow&n=Supah

 


Got Deathbringer's Will, seems like its limited to Arp, Str, Agi (600 each). It DOES transform you as well.
Dec 9, 2009 at 3:59 PM

a DK in the unholy thread got strength, crit, and haste procs.

Dec 9, 2009 at 8:41 PM

Tentatively, it looks like the proc is split out in the following way:

Warrior - Str, ArP, Crit
Rogue - Agi, ArP, AP
Paladin - Str, Haste, Crit
Hunter - AP, Agi, Crit
Death Knight - Str, Crit, Haste
Druid - ArP, Str, Agi

If that's the case, war/rog/druid will need to handle it separately for the arp proc (you can't just say it gives 200str 200arp and 200crit every time it procs, for the same reason you can't say Mjolnir Runestone gives uptime*ArpenRating as passive).  With ICC having people seeing the crit cap, it's probably a good idea to do special math for agi/crit, and possibly haste if it's non-linear for you.

Coordinator
Dec 9, 2009 at 9:01 PM
Edited Dec 9, 2009 at 9:03 PM

God, this is going to be a bitch of a trinket to model. :)

EDIT: Still missing Shamans from that list too. I'd guess Agi/AP/Crit, but not sure.

For completeness, we probably should see what procs it gives for mages/priests/warlocks too. :)

Dec 9, 2009 at 11:34 PM

Knowing what I know about how it changes your character model, I'm going to model this trinket the easy way: If Optimizing for "Cool Factor", this trinket is BIS.  I don't care if it's 3yrs from now and you're level 100.

Editor
Dec 10, 2009 at 3:02 AM
Edited Dec 10, 2009 at 3:15 AM

Can we collectively yell at Blizz for putting a "sometimes"-ArP-proc on a trinket?  That's ridiculously stupid for those of us that are passively ArP capped, and doesn't even make sene to gear around it.  Only seems to be designed for those who don't actively go after ArP, but can use it as a free proc (some Rogues would be it, looking at the above list).

Dec 10, 2009 at 3:39 AM
Edited Dec 10, 2009 at 4:09 AM

Attempting to hand model each type led me to an interesting bug:

Open a char

Go to 264 version of trinket

Right click, edit

Add effect

30 sec

600 AGI

Exit edit screen, look at it, ok

Right click, edit again

0 AGI, 600 STR

Exit edit screen

PROGRAM CRASH

Edit: also seems to crash randomly if I try to put the ArP on it...I think it may be due to me being at or near ArP cap with needler on.  It only does it if I am on the trinket tab with my not-arp-trinket.  Like I can edit it and add arp on the same trinket tab I have Needler.  If I change to the other tab, crash.  I swapped trinkets in my slots to verify.

Edit#2: happens with MeleeHit 100% as the proc reason...I changed it to PhysicalHit 15% (like Mjol etc) and no longer crashes.

Dec 10, 2009 at 4:00 AM

As for real model, 3 different 30 second out of 6 minute procs is probably the way to go?  Having them tailor to each class is a bitch...

Editor
Dec 10, 2009 at 6:32 AM
Edited Dec 16, 2009 at 11:59 PM

[Edit] Base info, for the lazy: 105s CD (1m45s), roughly 50% chance to proc.

Dec 16, 2009 at 7:53 PM

I've noticed some models have begun to deal with this.  I thought I'd share my solution to the problem and get some feedback.  I'm breaking it up into three SpecialEffects (one for each stat), and tripling the Cooldown on each effect.

 

if (effect.Stats.DeathbringerProc > 0f)
                {
                    SpecialEffect proc1 = new SpecialEffect(effect.Trigger, new Stats { Strength = effect.Stats.DeathbringerProc }, effect.Duration, effect.Cooldown * 3f, effect.Chance, effect.MaxStack);
                    SpecialEffect proc2 = new SpecialEffect(effect.Trigger, new Stats { CritRating = effect.Stats.DeathbringerProc }, effect.Duration, effect.Cooldown * 3f, effect.Chance, effect.MaxStack);
                    SpecialEffect proc3 = new SpecialEffect(effect.Trigger, new Stats { ArmorPenetrationRating = effect.Stats.DeathbringerProc }, effect.Duration, effect.Cooldown * 3f, effect.Chance, effect.MaxStack);
                    secondPass.Add(proc1); // strength and arp go in second pass
                    firstPass.Add(proc2); // crit rating goes in first pass
                    secondPass.Add(proc3);
                }

Note that my first/second pass is just how I split up my special effects.  Crit/Haste/Hit effects are iteratively computed (because they can change other effects' triggers), while all other stats are added in one pass after my final haste/crit/hit ratings are determined.

 

Developer
Dec 16, 2009 at 7:56 PM

Shouldn't that be 1/3'g the proc chance instead?

Developer
Dec 16, 2009 at 8:33 PM
Edited Dec 16, 2009 at 9:02 PM

nvm, ebs clarified it for me. I'm creating a static function in SpecialEffects that can be called to do essentially what you see above, where-in you pass your character class and it spits out the 3 of 6 relevant procs for you.

/// <summary>
/// Special Handler for Deathbringer's Will to be call from INSIDE the model.
/// </summary>
/// <param name="Class">The class of the character</param>
/// <param name="value">The current stats.DeathBringerProc value</param>
/// <returns>List of Special Effects relevant to your class. Will be a list of 3 items or 0 if passing an invalid class.</returns>
public static List<SpecialEffect> GetDeathBringerEffects(CharacterClass Class, float value) {
List<SpecialEffect> retVal = new List<SpecialEffect>();

SpecialEffect procSTR = new SpecialEffect(Trigger.PhysicalHit, new Stats { Strength = value }, 30, 90 * 3f, 0.15f);
SpecialEffect procCrit = new SpecialEffect(Trigger.PhysicalHit, new Stats { CritRating = value }, 30, 90 * 3f, 0.15f);
SpecialEffect procArP = new SpecialEffect(Trigger.PhysicalHit, new Stats { ArmorPenetrationRating = value }, 30, 90 * 3f, 0.15f);
SpecialEffect procHaste = new SpecialEffect(Trigger.PhysicalHit, new Stats { HasteRating = value }, 30, 90 * 3f, 0.15f);
SpecialEffect procAGI = new SpecialEffect(Trigger.PhysicalHit, new Stats { Agility = value }, 30, 90 * 3f, 0.15f);
SpecialEffect procAP = new SpecialEffect(Trigger.PhysicalHit, new Stats { AttackPower = value * 2 }, 30, 90 * 3f, 0.15f);

switch (Class) {
case CharacterClass.Warrior: retVal.Add(procSTR); retVal.Add(procArP); retVal.Add(procCrit); break;
case CharacterClass.Rogue: retVal.Add(procAGI); retVal.Add(procArP); retVal.Add(procAP); break;
case CharacterClass.Paladin: retVal.Add(procSTR); retVal.Add(procHaste); retVal.Add(procCrit); break;
case CharacterClass.Hunter: retVal.Add(procAP ); retVal.Add(procAGI); retVal.Add(procCrit); break;
case CharacterClass.DeathKnight: retVal.Add(procSTR); retVal.Add(procCrit); retVal.Add(procHaste); break;
case CharacterClass.Druid: retVal.Add(procArP); retVal.Add(procSTR); retVal.Add(procAGI); break;
case CharacterClass.Shaman: retVal.Add(procAGI); retVal.Add(procAP); retVal.Add(procCrit); break;
default: break; // None
}

return retVal;
}
Coordinator
Dec 16, 2009 at 8:49 PM

As long as there's no added benefit of all 3 of them procing together at the start, as compared to procing sequentially, that should be fine. That's probably how I'll handle it in Cat too.

Developer
Dec 16, 2009 at 9:00 PM
Edited Dec 16, 2009 at 9:24 PM

So what you see above there is the code of the function that you are calling, below is how I got that to work. When displayed in the comparison pane it will state the DeathBringer Proc as it should, but this code swaps it to the actual effects. Your ArP, crit caps, etc would need to be handled after this point (and I'm assuming with most of the models, they already are). I've already verified this works in Hunter, should work for everyone else without significant changes.

Stats statsItems = GetItemStats(character, additionalItem);
if(statsItems._rawSpecialEffectData != null){
foreach (SpecialEffect effect in statsItems._rawSpecialEffectData) {
if (effect != null && effect.Stats != null && effect.Stats.DeathbringerProc > 0)
{
statsItems.RemoveSpecialEffect(effect);
List<SpecialEffect> new2add = SpecialEffects.GetDeathBringerEffects(character.Class, effect.Stats.DeathbringerProc);
            foreach (SpecialEffect e in new2add) {
             e.Stats.DeathbringerProc = 1;
             statsItems.AddSpecialEffect(e);
            }
 }
}
}

Dec 16, 2009 at 9:17 PM

There was one problem with the method that I've uncovered, and it comes with passing the fight duration to the various SpecialEffect methods (ie AccumulateAverageStats).

If you set the fight duration as something a little over 270secs, it will assume you can get 6 procs off instead of only 4 (two of each instead of 1.33 of each).  I couldn't come up with a way to add 1.33 of each proc easily, so instead I opted to always pass 0 for these effects.  This gets around the issue of getting 6 procs (it instead will give you 3 plus a small amount, depending on the duration you put in).

I'm achieving this by setting DeathbringerProc=1 in those three special effects, and then when I process my effect I check for DeathbringerProc==1 and pass 0 for the fight duration instead of 1.  Using Jothay's code, you can change it to:

 

foreach (SpecialEffect e in new2add) {
                e.Stats.DeathbringerProc = 1;
                statsItems.AddSpecialEffect(e);
}

 

 

Developer
Dec 16, 2009 at 9:24 PM

Updated the post to include this change

Coordinator
Dec 16, 2009 at 9:48 PM

Err, that duration=0 workaround doesn't work when combining special effects. :(

Dec 16, 2009 at 9:51 PM

What do you mean combining special effects?  Like, I can't have duration=0 for some SEs but not others?  Or you mean when doing funky things with SEs like computing when SEs stack together?

Coordinator
Dec 17, 2009 at 1:52 AM

Isn't this a single special effect that just has one of 3 random stats when it procs? I would strongly suggest that you use a single SpecialEffect with actual cooldown for this. Compute the uptime of the effect and then your average uptime for each of 3 stats is a third of that.

Also if you're making static functions in SpecialEffect make sure you use thread synchronization and if you're creating SpecialEffect objects try to cache them if possible.

Coordinator
Dec 17, 2009 at 2:19 AM

(Working with Kavan on this now, to build an actually correct model for it)

Coordinator
Dec 17, 2009 at 9:45 AM
Edited Dec 17, 2009 at 9:45 AM

Here's how it finally ends up working.

1) Item is parsed with the following special effect:

stats.AddSpecialEffect(new SpecialEffect(Trigger.PhysicalHit, new Stats() { DeathbringerProc = ilvl == 277 ? 700 : 600 }, 30f, 105f, 0.15f));

2) Don't split it into 3 procs, or anything of the sort. Proceed with special effect handling as normal.

3) When accumulating average stats from procs, pass the weight value to the proc of (effect.Stats.DeathbringerProc > 0 ? 1f/3f : 1f), such as:

statsProcs.Accumulate(effect.GetAverageStats(triggerIntervals[effect.Trigger], triggerChances[effect.Trigger], 1f, calcOpts.Duration), effect.Stats.DeathbringerProc > 0 ? 1f/3f : 1f);

4) When summing up the value of the procs, count DeathbringerProc as all 3 stats that your class/spec gets (just str/agi shown here):

statsProcs.Agility += statsProcs.HighestStat + statsProcs.Paragon + statsProcs.DeathbringerProc;
statsProcs.Strength += statsProcs.DeathbringerProc;

5) For stats which you combine multiple procs to form the chance of each value of that stat, continue on.

6) When building the list of special effects to pass to SpecialEffect.GetAverageCombinedUptimeCombinations(), count DeathbringProc as the same stat as you're combining for (ie ArPen):

foreach (SpecialEffect effect in statsTotal.SpecialEffects(se => triggerIntervals.ContainsKey(se.Trigger) && se.Stats.ArmorPenetrationRating + se.Stats.DeathbringerProc > 0))

7) Also, build a list of scales along with each SpecialEffect:

tempArPenEffectScales.Add(effect.Stats.DeathbringerProc > 0 ? 1f / 3f : 1f);

8) If you've only got a single SpecialEffect, and just use effect.GetAverageUptime, be sure to add the DeathbringerProc to your total value:

float uptime = effect.GetAverageUptime(triggerIntervals[effect.Trigger], triggerChances[effect.Trigger], 1f, calcOpts.Duration) * tempArPenEffectScales[0];
armorPenetrationUptimes = new WeightedStat[] { new WeightedStat() { Chance = uptime, Value = effect.Stats.ArmorPenetrationRating + effect.Stats.DeathbringerProc },

9) For multiple SpecialEffect, just before calling SpecialEffect.GetAverageCombinedUptimeCombinations, create a new List<SpecialEffect> to hold adjusted copies of the SpecialEffects that you were going to calculate for. Add to this list the same SpecialEffects, except where DeathbringerProc>0. There, add a new SpecialEffect with ArmorPenetration=DeathbringerProc:

List<SpecialEffect> tempArPenEffectsAdjusted = new List<SpecialEffect>();
foreach (SpecialEffect effect in tempArPenEffects)
{
	SpecialEffect adjustedEffect = effect;
	float totalArPen = effect.Stats.ArmorPenetrationRating + effect.Stats.DeathbringerProc;
	if (effect.Stats.DeathbringerProc > 0)
	{
		adjustedEffect = new SpecialEffect(effect.Trigger,
			new Stats() { ArmorPenetrationRating = totalArPen },
			effect.Duration, effect.Cooldown, effect.Chance, effect.MaxStack);
	}
	tempArPenEffectsAdjusted.Add(adjustedEffect);
}

10) Call SpecialEffect.GetAverageCombinedUptimeCombinations() with the adjusted list of SpecialEffects, and the list of scales:

WeightedStat[] arPenWeights = SpecialEffect.GetAverageCombinedUptimeCombinations(tempArPenEffectsAdjusted.ToArray(), intervals, chances, offset, tempArPenEffectScales.ToArray(), 1f, calcOpts.Duration, AdditiveStat.ArmorPenetrationRating);

11) Poof, accurate modeling of Deathbringer's Will.

 

Dec 18, 2009 at 12:20 PM
Edited Dec 18, 2009 at 12:22 PM

Is this working correctly? For my druid, ive created a set that has 73% crit, and 1400 arpen. So the agility proc of DW will be partially wasted (since it pushes me way over the white crit cap) and the arpen proc is 100% wasted. Yet Rawr still ranks it at 800 DPS (compared to Herkuml War Toen and 258 Death's Choice at 590 dps)

Dec 18, 2009 at 4:54 PM
Mihirr wrote:

Is this working correctly? For my druid, ive created a set that has 73% crit, and 1400 arpen. So the agility proc of DW will be partially wasted (since it pushes me way over the white crit cap) and the arpen proc is 100% wasted. Yet Rawr still ranks it at 800 DPS (compared to Herkuml War Toen and 258 Death's Choice at 590 dps)

Even in my current set at 74% crit agility is still worth just as much as str (ok a TINY bit less but still).

 

Coordinator
Dec 18, 2009 at 5:58 PM

Send me the character file, but yeah, it likely is that good (heavily depends upon fight length too).

Dec 18, 2009 at 8:46 PM

It sounds absolutely right.  As ArP gets closer to cap, it gets exponentially worthwhile.  so the 155 or 167 static ArP starts getting in the 2.5-3 DPS-per-point range by itself in endgame gear. 

And then, you get 10% uptime on each of the procs (Str and Agi).  

In other words: when going after the hard cap, the static ArP on the item itself makes up for the lack of benefit from the ArP proc. 

Coordinator
Dec 18, 2009 at 9:00 PM

I think Khan is more refering to the fact that at 74% Crit, he is just a hair shy of white crit cap (75% crit against a lvl 83 boss [79.8% according to your live character sheet]). There is currently a discussion going on over at EJ discussing this 4.8% crit reduction on hit. Even Landsoul is able to verify that 4.8% of his hits on I belive it was shield slam (I could be seriously wrong on the ability). But needless to say talented, he had 54.8% crit and used an ability that has an extra 50% chance to crit. After 1600 attempts (or something like that) about 4.8% of those attempts "hit"

Coordinator
Dec 18, 2009 at 9:13 PM

Yes, there is a 4.8% reduction on yellow attacks against bosses, which can be bypassed with 4.8% more crit.

There is a conversion of 4.8% of crits to hits on why attacks against bosses, which cannot be bypassed.

Rawr is already calculating this accurately (and has been for a while); the crit chance you see on the stats tab is your yellow crit, after the 4.8% reduction.

Regardless, just because you hit the white crit cap, doesn't mean Agi is worthless; it's certainly not. It's about a 35% reduction in value of crit (white+FB; you cap FB crit at almost the same time).

Editor
Dec 18, 2009 at 9:26 PM

http://elitistjerks.com/f31/t76785-crit_depression_combat_table/

http://forums.worldofwarcraft.com/thread.html?topicId=21724987878&sid=1

Dec 19, 2009 at 1:34 AM

Okay, I've gotten the crit capping in now, but I'm seeing a HUGE perf hit whenever I'm passing in a combat duration.

I did some instrumentation, and it LOOKS like the problem is in Rawr.SpecialFunction.Ibeta.  Specifically, that I'm creating a new temporary effect with a stats object with Stats.CritRating = (effect.Stats.DeathbringerProc + effect.Stats.CritRating).  I have to do this because there's no way for the combinations method to combine additive stats.

The perf hit doesn't occur when not passing in a combat duration, and it doesn't happen if I'm not using DeathbringerProc (ie if I'm not creating a new special effect every iteration of calcing special effects).

So, I have two questions:

1) Astry, are you also noticing a huge performance hit?  I'm noticing a cycle taking 10x longer

2) Kavan, is there another way we can do this?

Coordinator
Dec 19, 2009 at 1:51 AM

1) Yes. Don't think it's that bad, but yes.

2) Kavan, could we perhaps pass in an AdditiveStat[] instead of an AdditiveStat[], and all of those stats would just be summed up? Err, now that I think further on that, that wouldn't work, because I need to not only combine DeathbringerProc and ArPen, but also convert Agility to CritRating, and combine all the CritRating... Hmm... Perhaps pass in some lamba function to create the WeightedStat Value from the Stats object? SpecialEffects already has the uptime graph of the special effect, it's just the summing up of stats that needs to be done.

Coordinator
Dec 19, 2009 at 2:21 AM

Ebs, make sure you go to general settings in options and set Effect Combinations Calculation Mode to cubic interpolation (suggested and default) or linear interpolation. It sounds like you're using the high precision one which is the cause for (HUGE instead of huge) perf hit you're seeing.

Dec 19, 2009 at 5:00 AM

I'm using Cubic (but I wasn't using combinations at all).  FOr Proc Effect Calculation Mode, I have Advanced - Interpolation.

Just a little more data: DPSWarr has a "Calculation Time" stat at the bottom that uses a Diagnostics.Stopwatch to count how long it takes to do the "DisplayValues = true" calc.  With Deathbringer's Will equipped and passing FightDuration=0, I have ~13k on my dev box.  When I pass FightDuration=300, my calc time is 1198k.  It's 100 times slower.  Instrumentation puts this to UpdateGrid, which was only called on that specialeffect (although its caller, Interpolator.get_Item(float,float) was called 6x).

If you want to reproduce it in DPSWarr right now, just load up my character (Ebs @ US-Sisters of Elune), equip the DBW trinket, and go to Options>Misc>Use Duration for Special Effects.  I recommend you change the Comparisons Pane to Slot: Gear>Projectile, or you may be waiting a while :P

 

The only workaround I've been able to come up with is caching that effect so I don't re-create it (I only need two, one for each Deathbringer proc).

Coordinator
Dec 19, 2009 at 5:12 AM
Edited Dec 19, 2009 at 5:21 AM

Yes, if you're using the noncombination GetAverage functions you need to cache the SpecialEffect, because they create an internal cache for interpolating the data which has a large one time initialization cost. My suggestion would be to just use the GetAverageUptime, that way you don't have to create a new SpecialEffect, but if you want to simplify your workflow by always using Accumulate functions that is ok also.

Actually correcting myself, you should not create a new effect and you can still use the Accumulate. The result Stats will have the value of DeathbringerProc equal to its uptime * actual value. You just need to convert this into the appropriate value of other stats.

Coordinator
Dec 19, 2009 at 5:14 AM
Edited Dec 19, 2009 at 5:24 AM

Where's the best place for us to do that?

EDIT: Nevermind, yeah, see your edit.

Editor
Jan 6, 2010 at 12:44 AM

The procced stats are very likely to change soon.  Thank GOD.

Jan 6, 2010 at 5:24 AM

Great, after all that time modelling it..

Editor
Jan 6, 2010 at 5:27 AM

xD

Jan 6, 2010 at 4:39 PM
Edited Jan 6, 2010 at 4:40 PM
BrWarner wrote:

The procced stats are very likely to change soon.  Thank GOD.

Hopefully they don't change for feral :(.

The modeling time isn't wasted though.  The effect will remain the same.  Just which classes get which stats may change.

Jan 6, 2010 at 9:26 PM

Not sure if this has been talked about yet but DBW now procs haste instead of ArP. WOOT

Jan 6, 2010 at 9:27 PM

For feral btw.

Jan 6, 2010 at 9:33 PM

Source?

Jan 6, 2010 at 9:40 PM

First noticed in 5 man this morning.  Spent last hour autoattacking dummy and saw a high procrate for "Speed of the Vrykul" which is the 600 haste buff.  This is on live.  If you know of a good proc monitor i will run autoattacks for the next few hours to see what the procrate looks like, for some reason i seem to get mostly haste, followed by strength with agi the least often.  I assume this is RNG but its very strange how little the agi procs in relation to the other 2.

Jan 6, 2010 at 9:59 PM

http://img341.imageshack.us/img341/1985/wowscrnshot010610143208.jpg

http://elitistjerks.com/f81/t37462-warrior_dps_calculation_spreadsheet/p95/#post1513460

Confirmed that warriors get haste instead of arp, at least.

Coordinator
Jan 7, 2010 at 1:45 AM
Edited Jan 7, 2010 at 1:49 AM

Changed also for kitties

http://elitistjerks.com/f73/t63774-cat_dps_guide_dummies/p21/#post1513634

 

DBW procs Str Agi and Haste now, WOOT

Just throwing it out there ;)

 

Jan 7, 2010 at 4:26 AM

Nifty :).

Too bad it's hard coded, can't adjust my proc really to see what it does for me :(.

Jan 7, 2010 at 5:12 AM

Warriors should be able to see the new version (with haste) if they can run the unreleased code

Editor
Jan 7, 2010 at 5:28 AM

The Warrior one looks to be about where I expect it to be, as Fury.  It looks to be severely undervalued (or maybe just underpowered?) for Arms, if you don't mind taking a look at it.

Developer
Jan 7, 2010 at 4:25 PM

Given that haste is more or less terrible for an Arms Warrior, I'm not too surprised to see it be a lot less valuable than for Fury--which actually sees some tangible value from Haste.

Jan 7, 2010 at 4:33 PM

Arm doesn't already ArP cap?

I would have thought the change would net positive for Arms since they would already cap and then the ArP proc would be nothing....though haste would be something even if it's not that great of a something.

Jan 7, 2010 at 4:33 PM

Not to mention the crit proc is more or less wasted on Overpower.  I will double check that everything works for Arms but if it's working for fury, there's no reason why it wouldn't be for arms (that I can come up with)

Jan 7, 2010 at 6:37 PM

DBW changes worth a release?

Too bad we don't have Tiny Abom data yet :(.

 

Jan 7, 2010 at 7:48 PM

Khanthal, DBW wasn't as strong for Arms at the arp cap in general.  Yes, adding a 600 haste proc here is an improvement, but if you weren't using any of the arp proc at all then it wasn't nearly as strong as, say, Whisper Fanged Skull and Death's Choice.  The value in it for arms was when you were close to the arp cap, but not at it yet (ie, passive arp was past the soft-cap and you're working towards the hard cap).

And I did confirm that there was a bug in the DBW handling -- the crit still wasn't done correctly for the final DPS calculation.  Weird that it wasn't caught earlier, but thanks BrWarner for the heads up :)  Take another look when you get a chance, if you could :)

Editor
Jan 7, 2010 at 8:04 PM

Looks pretty good, now.  I'll keep playing with it, and let you know if I can break it again.  xD