[Warrior] DPS Spreadsheet 2.3 and beyond - Page 11

Gruntle · 10/30/07, 6:46 PM

Originally Posted by Rhaeti

I was playing around with weapons in the latest version of the spreadsheet, and going from Blade of Infamy to Rising Tide in the MH gives about a 10 DPS increase @ the following stats (before MH is added): 3924AP, 36% crit, 178 hit rating, 103 haste. This makes no sense to me since the hit should not be as valuable as the high agi on the Blade which gives nearly 1% crit with kings--not to mention the 12 more AP. Maybe I have hit some magical boundary hit wise where ~20 more hit rating is going to increase DPS more than the extra AP and crit, but that makes no sense to me. It seems like it's some mystical point where hit rating is more valuable than it should be. This is weird.

I've gotten similar results occasionally at lower gear levels. I think it has something to do with the effect of extra procs/WF triggered by +hit giving rise to some kind of threshold effect. The extra rage income from this effect gives enough rage to give you an extra HS in the cycle and bam, you get +10 dps. Check the buffed dps sheet for the number of HS done with the different weapons.

There might be some bug, the effect seems to be very sensitive to the gear lvl, I could make it go away by adding 2 str or something (which then gave me the higher dps but with the earlier lowdps setup). It's indeed a bit weird.

Rhaeti · 10/31/07, 5:42 AM

Cool, thanks. It's nice to know it's just not some weird anomaly on my end. The gear level I was using was mid BT/MH level with the stat levels I said earlier. I haven't looked into the formulas behind the spreadsheet in that much detail, but I'll play around with it to try to find out the exact cause of those type of anomalies. Obviously when the dps makes those huge jumps in the model by just a few key stat points it's not going to be that way in the actual mechanics--just something to keep in mind if others run into a similar issue.

Graul · 10/31/07, 6:00 AM

Eh, nvm. I'll just donwload the Rogue spreadsheet.

Caesar · 10/31/07, 6:12 AM

the flurry uptime seems wrong imo.

according to the spreadsheet it should be about 65%, but I have much higher uptime according to my logs.

This is using slamcycles.

I havent checked so much how the number 65 is derived, but afaik, slam, bt, ww, hamstring, swordspec (?), WF(?) can all proc flurry but do not consume charges. Maybe this is where it went wrong?

theoretically the chance of renewing flurry if it's up in 3 autoswings is about (1-(1-0.35)^9) ~= 98%. note this is not the actual uptime, but it do backs up that flurry uptime should be higher than 65%. Maybe I'm just misstaken and my logs are lucky, but I think it should get a second look at.

Caesar · 10/31/07, 7:09 AM

I did a little more thinking on it and decided to write a quick simulator for it, since a few more things factor in. In the start you don't have flurry so you have to count in the time it takes for first flurry to hit etc. And is the number of hits flurried or uptime most interestnig? Flurried attacks go faster so the % of flurried attacks is not equal to the flurry uptime.

This simulator has perfect cyles (no rage starvation, no lag, no reactiontime, always an instant after the slam). but it should give a decent estimation.

    public void simulate() {
        Double critchance = 0.35;
        Double combatduration = 600.0;
        Double swingtime = 3.8;
        
        Double timeflurried = 0.0;
        Double timenotflurried = 0.0;
        int attacksflurried = 0;
        int attacksnotflurried = 0;
        int flurrycharges = 0;
 
        while (combatduration > 0) {
            if (flurrycharges > 0) {
                timeflurried += (swingtime/1.25) + 0.5;
                combatduration -= (swingtime/1.25) + 0.5;
                attacksflurried += 1;
                flurrycharges--;
            } else {
                timenotflurried += (swingtime) + 0.5;
                combatduration -= (swingtime) + 0.5;
                attacksnotflurried += 1;
            }
            
            if (Math.random() <= critchance) flurrycharges = 3; //the autoattack
            if (Math.random() <= critchance) flurrycharges = 3; //the slam
            if (Math.random() <= critchance) flurrycharges = 3; //the instantatack
        }
        
        System.out.println("Attacks flurried: " + attacksflurried + "/" + (attacksnotflurried+attacksflurried) + " uptime: " + (attacksflurried / (attacksflurried + attacksnotflurried)) + "%");
        System.out.println("Time flurried:    " + Math.round(timeflurried) + "/" + Math.round(timeflurried + timenotflurried) + " uptime: " + timeflurried / (timeflurried + timenotflurried) + "%");
    }

I made 100 simulations and averaged out the flurry uptime:

TOTAL AVERAGE: 0.9634029460643592% (uptime)
TOTAL AVERAGE: 0.9792841666382484% (uptime with 40% crit)

(total number of attacks uptime is slightly higher)

As a sidenote it can be mentioned that only doing autoattack + slam will give a Flurry uptime of about 0.9006430692263361% (uptime, 35% crit). And only autoattacking gives a uptime of about 0.67417420689065% (uptime, 35% crit). As combat duration goes very high, the number of flurried attacks become 0.9901557927099655% with 40% crit rate.

In reality it's not that high, because of rage starvation. non perfect cycles, etc etc, but it's at least above 90% I think, which is consistent with my logs.

Gruntle · 10/31/07, 8:37 AM

Cool, nice flurry uptimes you get with 2h slam cycles.

I thought the slam cycle was 4 autoattacks long though, making the flurry calculations a bit more complicated? The last attack has no instant so the true n number is not 9 but (not sure I've done this the right way though) 3 + 3 +3/4*3 = 8.25 on average.

edit I'm guessing that the spreadsheet does not include the slams in the flurry uptime calculations (if I remember correctly it's modeled as 1 - (1-crit)^(3 + n), where n is the number of instants per 3 * weapon speed. Can't check for sure atm.

Gruntle · 10/31/07, 8:38 AM

edit: stupid mispost, please delete

Caesar · 10/31/07, 8:43 AM

Originally Posted by Gruntle

Cool, nice flurry uptimes you get with 2h slam cycles.

I thought the slam cycle was 4 autoattacks long though, making the flurry calculations a bit more complicated? The last attack has no instant so the true n number is not 9 but (not sure I've done this the right way though) 3 + 3 +3/4*3 = 8.25 on average.

it is yes, but you could use hamstring as the 4th instant (to get better uptime and proc swordprocs). It's all theorycrafting, and I don't think it's a good idea to do, but it made my calculations and simulation easier. I also don't calculate WF procs or swordprocs in the simulation. My main goal was just to test the theory that flurry uptime is significantly higher than 65%.

dr_AllCOM3 · 11/01/07, 1:24 PM

Unfortunately I don't fully understand the Flurry calculations in the sheet. I don't like it either. In raids with a 2h I have more like 100% uptime.
It gets way more complicated when you have two weapons

.

Caesar · 11/01/07, 6:51 PM

Originally Posted by dr_AllCOM3

Unfortunately I don't fully understand the Flurry calculations in the sheet.

Did't you write the sheet? O.o

And yes I think setting it to a static 100% (or maybe 95-96 something) would give a better dps cycle time than the current 65% for slam cycles.

dr_AllCOM3 · 11/01/07, 10:27 PM

Originally Posted by Caesar

Did't you write the sheet? O.o

I re-wrote it.

Caesar · 11/02/07, 6:07 AM

ok I think this will be a better formulae. It includes a lot of circular references though. If someone took a look it would be great.

Basically I took the probability to renew the flurry if you have it as flurry uptime. it is NOT the actual uptime, but it's very close to it it seems.

MH = Mainhand speed
OH = Offhand speed
CRIT = critchance
IPS = Instants per second (including slam)
RESET = 0.5 if you are using slam cycles, 0 if not. The forumale does not accomodate dualwield slamming (but I dont think this is a common spec). In this forumlae I ussume no instants consume flurry, and both MH and offhand do, and both OH and MH can proc flurry. OH and MH do not have individual Flurry charges. Double flurry because of sametime attacks are not accounted for (ie the getting extra flurry charges fenomena).

if you do not use an offhand: (1/OH) = 0

Flurry uptime ~= 1-((1-CRIT)^(((3/((1/(MH+RESET))+(1/OH)))*IPS)+3))

Ok this is th logic behind it:
first calculate the average time it takes to get 3 white hits. not that the MH and OH values should be adjusted by flurry uptime, so it's a circular ref on those. If you use slam, add 0.5 to the attackspeed of the hasted weapon: 3/((1/(MH+RESET))+(1/OH))

Then take the number of instant attacks per second (simply divide the number of instant attacks by the cycle length for the different cycles. not that the cycle length will be a variant of the attackspeed on some (slam) cycles: (...)*IPS (addition, WW should be counted twice after 2.3 if dualwielding)

Add three becayse the three white attacks can proc flurry too. (...)+3

That is the number of attacks you will do in the time it takes to consume 3 flurry charges. so what is the probability you will renew it in this time? 1-(probability for it not to happen)^(number of shots you have at it) ie: 1-(1-CRIT)^(...)

That should give total formulae:
Flurry uptime ~= 1-((1-CRIT)^(((3/((1/(MH+RESET))+(1/OH)))*IPS)+3))

Gruntle · 11/02/07, 9:58 AM

Nice Caesar.

The spreadsheet version does already use circular references, I'm not sure how your version is different from the one in place, the Slam correction is not in there at least.

The general formula looks ok to me, just some comments:
- The MH and OH speeds could possibly also be updated for Mongoose procs?
- The IPS value for 2.3 should get +2 per whirlwind when DWing (if that's how WW will be implemented).

Caesar · 11/02/07, 11:12 AM

Originally Posted by Gruntle

Nice Caesar.

The spreadsheet version does already use circular references, I'm not sure how your version is different from the one in place, the Slam correction is not in there at least.

The general formula looks ok to me, just some comments:
- The MH and OH speeds could possibly also be updated for Mongoose procs?
- The IPS value for 2.3 should get +2 per whirlwind when DWing (if that's how WW will be implemented).

MH/OH should be updated from all things that update haste, haste pots and ofc hasterating procs too
the IPS should not be +2, but WW should be counted double (if dualwielding) when deriving the IPS number (number if instants/cycle length). I guess thats what you ment though, and good notice!

Did some test calculations to see if the formulae seem correct:

Slamcycles (3.8 speed weapon)

MH = 3.06 (3.8 spd weapon flurried 97% of the time)
CRIT = 0.36
IPS = 7/14.25 = 0.491 (4 slams, 2 BT, 1 WW)

Flurry uptime ~= 1-((1-0,36)^(((3/((1/(3,06+0,5))+(0)))*0,491)+3)) = 0.97 = 97%

for Dualwielding (2 x 2.8 speed weapon)

MH = 2,352 (2.8 spd weapon flurried 80% of the time)
OH = 2,352 (2.8 spd weapon flurried 80% of the time)
IPS = 7/18 = 0.389 (3 BT, 2 WW (counted double))
CRIT = 0.31

Flurry uptime ~= 1-((1-0,31)^(((3/((1/(2,352+0))+(1/2,352)))*0,389)+3)) = 0.80 = 80%

for Dualwielding (2.8 + 1.5 speed weapon)

MH = 2,369 (2.8 spd weapon flurried 77% of the time)
OH = 1,269 (1.5 spd weapon flurried 77% of the time)
IPS = 7/18 = 0.389 (3 BT, 2 WW (counted double))
CRIT = 0.31

Flurry uptime ~= 1-((1-0,31)^(((3/((1/(2,369+0))+(1/1,269)))*0,389)+3)) = 0.77 = 77%

Gruntle · 11/02/07, 12:03 PM

You beat me to it

, was going to plugin some numbers as well.

Yeah, that's what I meant about the IPS.

On a sidenote, using one hamstring per 18 sec DW cycle will give you a Flurry uptime of about 81.5% in the 2.8 matched case.