Another thing, is rage=min([rage 120]); (line 275) missing an ;?
The values I'm getting now match expectations though. For 66.7% SB uptime and 19.31% avoidance, 17.94% block, I'm getting about 22% unblocked hits. (1-0.1931)*(1-0.667)*(1-0.1794)=0.2205.
I'm not going to try and quote everyone that's given feedback, but to address most of the points:
kopcap: the "rage cushion" factor is why hit/exp doesn't drop off to 0 in value at 66.7%. Stochastic variations make it valuable for exactly the reason you've given. However, the sim is giving us pure TDR stat weights, and what you're talking about gets into the "control" scheme. Guaranteeing that you have access to it by generating more rage than necessary at other times is sacrificing TDR (in the form of better TDR stats) for reliability. That doesn't make it wrong (for example, I think it's the far superior route for paladins), but it isn't something that the sim can readily generate stat weights for. At least, not without looking at some moving average DTPS statistics. Those stats can be generated by the sim, but I haven't touched on them yet because I want to do the paladin versions first (partly because I'm certain that sim is correct, and this one is still being improved through this discussion).
Airo: Regarding SBarr prioritization, I don't track health at all in the sim (because then you have to start assuming a healing profile, and that gets even less certain). For the purpose of the sim, we can assume any value for the boss's physical DPS and assume we're getting healed through it. For dynamic SBarr priorities, we're limited to choosing based on resource, cooldowns on abilities, and SBlock details (i.e. is it up, what's the cooldown on charges, etc.). It seems like that gives us the following scenarios:
1) Prioritize based on Rage capping (use SBarr if rage>100ish)
2) Use SBarr only (low HP situation, weak physical DPS, magical boss)
The "big attack" scenario is not something we can easily model stochastically, because it requires a lot more fight-specific detail (how often does the big attack happen? how much warning do we have? do we have to plan and pool rage to handle it? etc.)
Once I get SBarr implemented, we can definitely look at both of those cases, though.
It seems like the consensus is that the block meta gem is much stronger than I assumed for warriors. As such, I'll implement it as the default choice, though I'll make it toggle-able to see how much benefit it gives.
Another thing, is rage=min([rage 120]); (line 275) missing an ;?
It is, but it doesn't matter. rage is stored as a scalar, so min([rage;120]) and min([rage 120]) give the same result. It's just taking the minimum element of the array, and since it's a singleton array it doesn't matter if it's a row or column vector.
As an aside, I think I've found an error in Airo's spreadsheet. On the stats sheet, the AP is hardcoded to 15000 rather than being 2*strength (14752). I stumbled across this while I was working on SBarr absorbs, the value on the spreadsheet was a little higher than what I was getting by using just 2*strength values. Unless you guys get some free AP I'm not aware of.
The net equation for SBarr absorb should be ~2*[1.1*VAP + 0.2*BS], where VAP is vengeance AP and BS is buffed strength. The strength component is about 6% of the total SBarr absorb (this is assuming boss damage is such that the stamina-based minimum is not being invoked).
I'm going to assume a boss swing value of 250k for my sims, which turns that into about 3% of the SBarr absorb total. This regime is such that the average SBlock mitigation is still larger than the average SBarr absorb (though they're close, SBlock is only about 20k ahead).
Ok, I think I have Shield Block implemented. I've updated the code and changed the tracking mechanism to account for partial and full absorbs. Anyone with programming experience can look over it here: http://code.google.com/p/matlabadin/...blog/warr_mc.m
Using a simple priority of (SBarr if rage>110)>(SBock if rage>60 and available) and an attack priority of SS>Rev>BS>BR>TC>Dev gives me a plot that looks like this:
Anything look fishy?
If DTPS is damage taken per second, how did you get to 53.09%?
Also, shouldn't your vengeance calculation use preMitigationBossSwingDamage, instead of BossSwingDamage (/e and shouldn't the pre-mitigation damage also include weakened blows, so a additional /0.9)?
(If I've correctly implemented it in my sim, I'll - maybe - have to say more. :>)
Last edited by Quietsch; 09-12-2012 at 09:03 AM.
So that block of code should really look like:
Does that sound correct?Code:armorMit=1-0.45; specMit=1-0.25; wbMit=0.9; %% Define constants/variables bossSwingTimer=1.5; bossRawSwingDamage=250000; %Vengeance info bossSwingDamage=bossRawSwingDamage.*armorMit.*specMit.*wbMit; avgVengAP=0.02*(bossRawSwingDamage./bossSwingTimer).*(20./bossSwingTimer); shieldBarrierAbsorb=2*(1.1.*avgVengAP+0.2.*buffedStr)./bossSwingDamage;
(By the way, Weakened Blows doesn't affect Vengeance, it's calculated before WB is accounted for).
So that's giving me bossSwingDamage = 92.8k and shieldBarrierAbsorb=1.0932 (or around 101.5k damage absorbed).
I guess I'll have to update the tracking to follow fullly-absorbed hits too.
Last edited by theckhd; 09-12-2012 at 09:29 AM.
Assuming only Vengeance granting AP and the raid buff, the SBar absorb formula is roughly correct, as you still need to add the base AP, minus the 20 your first 10 Strength never provided, but the formula still reduces.
It's not uncommon for SB to only be 20k above SBar, but as both are >90% dependant on the incoming DPS, the relative value of both remains roughly the same untill you either hit the lower stam cap on SBar, change out a decent amount of Mastery, or get large spikes, where SB only helps against the spike itself, while SBar has the most effect afterwards (see Impale).
Edit: Yeah, the Vengeance stuff seems to be modeled out fine now.
PS: I would also be interested in how your stats shift if e.g. the boss does 10% additional damage as magic (heavy AoE damage model).
The part with weakened blows was meant for your premitigation calculation, as it should have been included in the mitigated damage -> premitigation damage calculation.
So now, it should be included in postMitigationBossSwingDamage, so postMitigationBossSwingDamage=preMitigationBossSwi ngDamage.*armorMit.*specMit.*0.9;
Also your avgVengAP calculation is off, as it's half as high as it'd have to be. (It's either 40% DPS or (with a 2.0 swingspeed) 20% Swingdamage - you're taking 20% DPS)
And I can't see, why you'd want to include postMitigationBSD in the shieldBarrierAbsorb.
Yeah, I think you posted while I was editing mine. WB is included in the post-mitigation value.
You're right about the Vengeance AP calculation as well. It's 2% of the unmitigated damage you've taken over 20 seconds, which is:
0.02*(unmitigated boss swing damage)*(number of swings in 20 seconds) or
0.02*(unmitigated boss DPS)*(20 seconds)
Either way, it should be 0.4*(bossRawSwingDamage./bossSwingTimer). It's also in error in Airo's spreadsheet (which is where I stole the formula). Cell F19 should be =0.4*(H8/H9), not =0.02*(H8/H9)*(20/H9).
The post-mitigation value is in the shield barrier absorb for normalization purposes. I'm tracking everything in normalized damage (i.e. a full hit is 1, a full absorb or avoid is 0, a block is 0.69, crit block is 0.38). To keep consistent with that, I need to represent the shield barrier absorb value in units of post-mitigation hit sizes.
The values I'm getting now look like:
shieldBarrierAbsorb=1.6199 (or 150k absorb shields).
And the plot looks like this:
<edit>Also, I should probably explain the statistics a bit.
For full hits, blocks, and crit blocks, the first stat is the total number of each event type divided by the number of boss attacks. So they should accurately represent exactly what you'd expect them to.
Beneath that, I give the percentage of partial and full absorbs for each type, in absolute percentage. In other words, 22.6% of all attacks were full hits, 0.98% of all attacks were full hits that were also partial absorbs, 0.98% of all attacks were full hits that were also full absorbs.
Similarly, 33.3% of all attacks were blocks (but not crit blocks), 0% of all attacks were blocks that were partially absorbed, 0.53% were blocks that were fully absorbed.
For the avoidance line, it's showing all of the avoids and ALL of the full absorbs. So for example, 19.8% of all attacks were avoided and 1.86% of all attacks were full absorbs (of any type), giving us a total of 21.66% of all attacks dealing no damage.
Last edited by theckhd; 09-12-2012 at 10:07 AM.
And here are the stat weight values I'm getting:
Code:N=50, \tau=10000, stat=1500 | | dodge | parry | hit | exp | mastery | | mean | 0.0078 | 0.0078 | 0.0057 | 0.0058 | 0.0102 | | std | 0.0006 | 0.0005 | 0.0005 | 0.0006 | 0.0006 | | std_mean | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | | | | | | | | | mean | 0.7594 | 0.7589 | 0.5568 | 0.5668 | 1.0000 | | std | 0.0553 | 0.0447 | 0.0445 | 0.0538 | 0.0598 | | std_mean | 0.0078 | 0.0063 | 0.0063 | 0.0076 | 0.0085 |
That seems about right for SB-weighted hit/exp values (as well as the rest)
Considering the mechanics for magic vs melee stay the same, the ratio really isn't important, I just thought 10% extra would be a nice amount for a constant ticking aura as well as showing an easy comparison as 1:10 magic:melee ratio.
I've updated the analysis based on the feedback in this thread, let me know if you see any obvious errors with the updated version:
Note that I haven't dealt with magical damage here, just because at that point you need to be very specific about the encounter. An encounter with 10% of each melee attack done as magical damage is very different from one that mixes melee and magic attacks in 9:1 ratios, and so on. I think at that point, it makes more sense to consider specific encounters or mechanics rather than trying to come up with a blanket analysis that doesn't practically apply to any encounters.
I don't think it is needed to model specific fights as the results will be mostly dictated by things you can not sim for, ie raid composition and cooldown usage. What I'd rather see if the effect that a passive magic ticking aura has on our stats.
The problem is that at that point, your cast priority would change. A smart player is going to be using more Shield Barriers in that situation, which makes the cast logic more complicated. I'm not really interested in spending a lot of time trying to model how players would react to changes in damage intake and turn that into logic, but if someone wants to do the legwork, I can implement it.
Absolutely. Hence the question, how much passive magic dmg is needed to make exp ~ parry. If the answer is 0.1, it is safe to put hit/exp > avoidance on virtually every fight, if the answer is closer to 0.5 - then its not.