[Enhancement] Rawr.Enhance thread - Page 13

Levva · 11/16/09, 7:50 AM

Version 2.2.27.19991 - Hit Rating Fix
MAJOR breakthrough - I finally managed to identify the issue with hit rating. It was in the white damage dps section. I was inaccurately taking the total white damage (hits+crits+glances) and adjusting it for the miss rate. Crit and glancing damage shouldn't be affected. This was making hit rating appear to make a bigger influence on damage than it should have. Note its only a minor change in total dps but it's enough for hit rating to drop down below AP & Haste as has been seen in EnhSim.

This is great news as finally people can get off my back about hit rating

It's a very subtle change from

        public float NormalHitModifierMH { get { return 1 - chanceWhiteCritMH - glancingRate; } }
        public float CritHitModifierMH { get { return chanceWhiteCritMH * (2f * (1f + _stats.BonusCritMultiplier)); } }
        public float NormalHitModifierOH { get { return 1 - chanceWhiteCritOH - glancingRate; } }
        public float CritHitModifierOH { get { return chanceWhiteCritOH * (2f * (1f + _stats.BonusCritMultiplier)); } }
        public float GlancingHitModifier { get { return glancingRate * 0.7f; } }


            //1: Melee DPS
            float APDPS = (attackPower / 14f);
            float adjustedMHDPS = (wdpsMH + APDPS);
            float adjustedOHDPS = 0f;
            float dpsOHMeleeTotal = 0f;

            float dpsMHMeleeNormal = adjustedMHDPS * cs.NormalHitModifierMH;
            float dpsMHMeleeCrits = adjustedMHDPS * cs.CritHitModifierMH;
            float dpsMHMeleeGlances = adjustedMHDPS * cs.GlancingHitModifier;

            float meleeMultipliers = weaponMastery * cs.DamageReduction * bonusPhysicalDamage;
            float dpsMHMeleeTotal = ((dpsMHMeleeNormal + dpsMHMeleeCrits + dpsMHMeleeGlances) * cs.UnhastedMHSpeed / cs.HastedMHSpeed) * meleeMultipliers * cs.ChanceWhiteHitMH;

            if (character.ShamanTalents.DualWield == 1 && cs.HastedOHSpeed != 0)
            {
                adjustedOHDPS = (wdpsOH + APDPS) * .5f;
                float dpsOHMeleeNormal = adjustedOHDPS * cs.NormalHitModifierOH;
                float dpsOHMeleeCrits = adjustedOHDPS * cs.CritHitModifierOH;
                float dpsOHMeleeGlances = adjustedOHDPS * cs.GlancingHitModifier;
                dpsOHMeleeTotal = ((dpsOHMeleeNormal + dpsOHMeleeCrits + dpsOHMeleeGlances) * cs.UnhastedOHSpeed / cs.HastedOHSpeed) * meleeMultipliers * cs.ChanceWhiteHitOH;
            }
            float dpsMelee = dpsMHMeleeTotal + dpsOHMeleeTotal;

        public float NormalHitModifierMH { get { return ChanceWhiteHitMH - chanceWhiteCritMH - glancingRate; } }
        public float CritHitModifierMH { get { return chanceWhiteCritMH * (2f * (1f + _stats.BonusCritMultiplier)); } }
        public float NormalHitModifierOH { get { return ChanceWhiteHitOH - chanceWhiteCritOH - glancingRate; } }
        public float CritHitModifierOH { get { return chanceWhiteCritOH * (2f * (1f + _stats.BonusCritMultiplier)); } }
        public float GlancingHitModifier { get { return glancingRate * 0.7f; } }


            //1: Melee DPS
            float APDPS = (attackPower / 14f);
            float adjustedMHDPS = (wdpsMH + APDPS);
            float adjustedOHDPS = 0f;
            float dpsOHMeleeTotal = 0f;

            float dpsMHMeleeNormal = adjustedMHDPS * cs.NormalHitModifierMH;
            float dpsMHMeleeCrits = adjustedMHDPS * cs.CritHitModifierMH;
            float dpsMHMeleeGlances = adjustedMHDPS * cs.GlancingHitModifier;

            float meleeMultipliers = weaponMastery * cs.DamageReduction * bonusPhysicalDamage;
            float dpsMHMeleeTotal = ((dpsMHMeleeNormal + dpsMHMeleeCrits + dpsMHMeleeGlances) * cs.UnhastedMHSpeed / cs.HastedMHSpeed) * meleeMultipliers;

            if (character.ShamanTalents.DualWield == 1 && cs.HastedOHSpeed != 0)
            {
                adjustedOHDPS = (wdpsOH + APDPS) * .5f;
                float dpsOHMeleeNormal = adjustedOHDPS * cs.NormalHitModifierOH;
                float dpsOHMeleeCrits = adjustedOHDPS * cs.CritHitModifierOH;
                float dpsOHMeleeGlances = adjustedOHDPS * cs.GlancingHitModifier;
                dpsOHMeleeTotal = ((dpsOHMeleeNormal + dpsOHMeleeCrits + dpsOHMeleeGlances) * cs.UnhastedOHSpeed / cs.HastedOHSpeed) * meleeMultipliers;
            }
            float dpsMelee = dpsMHMeleeTotal + dpsOHMeleeTotal;

However as it no longer affects crits and glancing white damage it means that the effect of hit rating is reduced. This effect was more marked on people who had high crit ratings and so smaller hit changes made bigger dps changes. Now that its identified and fixed there should be a dramatic change in the effectiveness of the Sim.

Download Links

Main Rawr Website for instructions and usage. Download of Rawr main application : v2.2.27 release

Rawr.Enhance.zip - extract to Rawr directory overwriting existing files

For clarity - Download the main application, then download the zip file and extract the files to your Rawr directory overwriting the existing files with the newer versions. Then and only then run the application and confirm the version number on the splash screen and on the Enhancement module page (see graphic below) matches the latest version.

NB. If you wish to report any issues please scroll down the stats window until you see the version number, you MUST quote this on any reports you give.

Picture shows how to find the version number.

Rouncer · 11/16/09, 11:46 AM

Levva, I am beyond impressed. I tried the optimizer routine in that update with all the gear I currently have available and it found 15 dps when run through EnhSim (swapping to offset shoulders instead of helm and changing my gemming to exactly hit the spell hit cap). Not sure I am going to make those changes since I like being spell hit capped without the debuff but I am very impressed with it even so.

One thing to check on though, the hyperaccelerators and pyro-rocket glove enchants put a 10 second cooldown on activated trinkets. This decreases those types of trinkets uptimes slightly and normally ends up making them a bit worse then expected. Looking at the list of recommended upgrades it doesn't seem like Rawr is taking that into account.

Gbits · 11/16/09, 12:10 PM

Removed, because I apparently lack the ability to read on Monday mornings.

Rouncer · 11/16/09, 12:21 PM

Originally Posted by Gbits

I killed off any remains of the previous Rawr, loaded it into a new folder, loaded up my current profile and available gear, and sicced it on optimizing (DPS rating only)... and was suggested a profile with 683 hit, including two 100+ hit rating trinkets and pure hit JC gems. If anything, this is higher than ever before. Perhaps this is an anomaly based on my particular set of gear (maybe for me, hit really is THAT good?) or some mistake I made in using Rawr? EnhSim has not typically simmed high-hit sets as higher DPS for me, but I haven't run it with this particular setup yet.

Re-read Levva's post and then download the Data file linked in the post and merge it with the Data file in the latest version of Rawr. He just figured out the issue and is giving people a way to fix it in the current version of Rawr before the next version is released.

Levva · 11/16/09, 12:25 PM

Originally Posted by Rouncer

Levva, I am beyond impressed. I tried the optimizer routine in that update with all the gear I currently have available and it found 15 dps when run through EnhSim (swapping to offset shoulders instead of helm and changing my gemming to exactly hit the spell hit cap). Not sure I am going to make those changes since I like being spell hit capped without the debuff but I am very impressed with it even so.

One thing to check on though, the hyperaccelerators and pyro-rocket glove enchants put a 10 second cooldown on activated trinkets. This decreases those types of trinkets uptimes slightly and normally ends up making them a bit worse then expected. Looking at the list of recommended upgrades it doesn't seem like Rawr is taking that into account.

It gets better than that Rouncer. When you load the optimiser in the top left section you can add conditionals. So if you want to be spell capped regardless of buff you can click the Add button and select Hit Rating from the drop down now make sure the >= is selected and set the value to 446 which is the horde 17% cap. ie: it will now take the additional condition into play to optimise hit rating to be 446 or more.

So now it will optimise your gear based on the hit rating you specify as well as the default which is get DPS rating as high as possible. Let me know if that helps.

Levva · 11/16/09, 9:24 PM

Originally Posted by Rouncer

One thing to check on though, the hyperaccelerators and pyro-rocket glove enchants put a 10 second cooldown on activated trinkets. This decreases those types of trinkets uptimes slightly and normally ends up making them a bit worse then expected. Looking at the list of recommended upgrades it doesn't seem like Rawr is taking that into account.

There is no such handling in Rawr at present. What exactly is the conditions? What exactly happens? Is this catered for in EnhSim? I've raised an issue on Rawr Issue Tracker but other developers are unsure what you are on about.

Rouncer · 11/16/09, 9:54 PM

When you activate the hyperaccelerators it puts a 10 second cooldown on activatable trinkets and if you activate a trinket it puts a 10 second cooldown on the hyperaccelerators. EnhSim has been set up to take this into account.

Stopokingme · 11/17/09, 4:11 AM

10 seconds sounds odd, sure it's not 12 seconds for the Hyperspeed Accelerators and 20 seconds or whatever the duration is for the trinkets? As far as I'm aware the cooldown imposed was related to the duration of the buff.

Levva · 11/17/09, 5:40 AM

Originally Posted by Rouncer

When you activate the hyperaccelerators it puts a 10 second cooldown on activatable trinkets and if you activate a trinket it puts a 10 second cooldown on the hyperaccelerators. EnhSim has been set up to take this into account.

Is this the same sort of cooldown implemented when you equip a trinket? All trinkets go on a longish cooldown for a while?

Specifically what is the effect if a trinket is already on cooldown? None I'd guess? Or does it extend the CD of the trinket by 10 seconds??

If its none then I can't see how there is any affect on the uptime of the trinket. As the calculation is the average uptime over the duration of the combat. So if its a 2min cooldown and a 10 min fight then the trinket is usable 5 times, and so its contribution is measured that way.

If there is no change to the duration of the trinket whilst its on CD how would that change it being used 5 times in 10 mins?

Stopokingme · 11/17/09, 6:21 AM

There's no effect on a trinket already on cooldown, the cooldown was first implemented in 1.0 some time after ZG, to prevent mages/locks blowing people up with high spellpower values from two clicky trinkets active at the same time.

It should have no effect on uptime whatsoever. Might have some minor effect on damage, from having multiple effects from trinkets and whatnot active at the same time, I'm not sure how RAWR calculates that, so that might be worth a look.

Xieon · 11/17/09, 10:00 AM

It may generate some wonky numbers if timed right with Potion of Speed or Heroism, allowing for a substantial amount of impossible DPS for a short duration.

As stated, it was to remove the casters from insta-gibbing people in PvP with [Zandalarian Hero Charm] and [Talisman of Ephemeral Power] back in the day.

I'm sure that Rawr has the trinket stacking disabled, Rounce is just pointing out that the accelerators work on the same principle.

Rouncer · 11/17/09, 10:25 AM

Originally Posted by Levva

Is this the same sort of cooldown implemented when you equip a trinket? All trinkets go on a longish cooldown for a while?

Specifically what is the effect if a trinket is already on cooldown? None I'd guess? Or does it extend the CD of the trinket by 10 seconds??

If its none then I can't see how there is any affect on the uptime of the trinket. As the calculation is the average uptime over the duration of the combat. So if its a 2min cooldown and a 10 min fight then the trinket is usable 5 times, and so its contribution is measured that way.

If there is no change to the duration of the trinket whilst its on CD how would that change it being used 5 times in 10 mins?

It just puts it on a cooldown while the other is active if it is not already on cooldown. Not sure why the hyperaccelerators are 10 seconds while the effect lasts 12 seconds but the pyro-rockets also activate a 10 second cooldown and they have no duration of action.

If the trinkets "Use" lasts 20 seconds and the hyperaccelerators are not on cooldown then using the trinket puts them on cooldown for 20 seconds.

I haven't played around with an activatable trinket in EnhSim for a long time but back when we were in Ulduar I looked at the Wrathstone and the interaction definitely made it sim out as a worse option for an engineer then for people with other professions. That could have been caused by the static combat durations of the previous versions of EnhSim but it seemed worth bringing up as Rawr was recommending certain activatable trinkets as upgrades and that conflicted with what I had previously seen.

Levva · 11/17/09, 11:59 AM

Originally Posted by Rouncer

It just puts it on a cooldown while the other is active if it is not already on cooldown. Not sure why the hyperaccelerators are 10 seconds while the effect lasts 12 seconds but the pyro-rockets also activate a 10 second cooldown and they have no duration of action.

If the trinkets "Use" lasts 20 seconds and the hyperaccelerators are not on cooldown then using the trinket puts them on cooldown for 20 seconds.

I haven't played around with an activatable trinket in EnhSim for a long time but back when we were in Ulduar I looked at the Wrathstone and the interaction definitely made it sim out as a worse option for an engineer then for people with other professions. That could have been caused by the static combat durations of the previous versions of EnhSim but it seemed worth bringing up as Rawr was recommending certain activatable trinkets as upgrades and that conflicted with what I had previously seen.

Remember that Rawr is a closed form solution and so averages out proc rates over the entire combat duration it does not and never will attempt to work out WHEN a proc happens just that in the course of the fight you could get off X procs which add Y dps.

ebs2002 · 11/17/09, 1:36 PM

It sounds like the loss of DPS isn't that you use your procs less frequently, but that you can't stack them together. If there is any problem with how Rawr as a whole deals with this situation, it's that Rawr wasn't trying to stack your special effects together in the first place. Rather, Rawr calculates your stats the way most non-sim theorycrafting does: by averaging the stats contribution over time.

As for the Enhancement model specifically, my understanding is that haste for enhance is very non-linear. Ideally, you want to calculate your DPS with the haste proc, and then again without the haste proc, and then compute dps as follows:
dpsWithoutProc * (1 - proc.uptime) + dpsWithProc * proc.uptime

I'm not sure how your doing your calculations, but you may be able to pull out everything that is non-linearly affected by haste (WF procs, white swings in general) and calculate them separately, and then use the simple average for the linear effects of haste.

You could look at how cat or dpswarr do armor pen trinkets for an example of what I'm talking about.

Levva · 11/17/09, 8:17 PM

Originally Posted by ebs2002

It sounds like the loss of DPS isn't that you use your procs less frequently, but that you can't stack them together. If there is any problem with how Rawr as a whole deals with this situation, it's that Rawr wasn't trying to stack your special effects together in the first place. Rather, Rawr calculates your stats the way most non-sim theorycrafting does: by averaging the stats contribution over time.

As for the Enhancement model specifically, my understanding is that haste for enhance is very non-linear. Ideally, you want to calculate your DPS with the haste proc, and then again without the haste proc, and then compute dps as follows:
dpsWithoutProc * (1 - proc.uptime) + dpsWithProc * proc.uptime

I'm not sure how your doing your calculations, but you may be able to pull out everything that is non-linearly affected by haste (WF procs, white swings in general) and calculate them separately, and then use the simple average for the linear effects of haste.

You could look at how cat or dpswarr do armor pen trinkets for an example of what I'm talking about.

Hi ebs. I've been trying to use Kavan's stationary distributions!!! He'd never forgive you for suggesting that it was as simple as averaging non hasted with hasted. If you have a look at the developer thread on Rawr site where he was advising Jothay about the DPSWarrior bits you'll see what I mean

Edit: I've closed the issue as you said it isn't really an issue with the way Rawr calculates.

ebs2002 · 11/18/09, 1:58 AM

Markov Processes and the weighted averages aren't mutually exclusive. A stationary distribution is used for something like flurry, but not for something like a haste use effect. Weighted averaging is just fine for that.

Note that there's a difference between
TotalDPS = CalculateDPS(baseHaste + effect.Haste*effect.Uptime)
and
TotalDPS = CalculateDPS(baseHaste + effect.Haste)*effect.Uptime + CalculateDPS(baseHaste)*(1-effect.Uptime)

Levva · 11/18/09, 8:18 AM

True but at present I'm using an iterative loop as I need to model Windfury with its 3sec CD, flurry, Maelstrom weapon stacks and Elemental devastation.

The big problem with those is that flurry grants extra haste on crit, which means more MW stacks, which means more ED uptime which means more flurry procs from the extra ED crit bonus. So at no point in the cycle is there anything that's independent of the others, they are all intertwined.

So as you can see its perhaps not quite as easy as having an effect.uptime.

I'm sure a Markov chain could be constructed to give a definitive answer particularly for the flurry & WF procs however the ED giving more crit is the annoyance and provides feedback into the equation. Is it possible perhaps, can I do it without my head exploding from the pain of the maths involved nope.

I'd be absolutely delighted if I could have a definitive mathematical model that accurately catered for all the conditionals, at present the iterative approach works fairly well and settles down to an answer in 5 iterations, so I'm currently happy with that.

ebs2002 · 11/18/09, 11:28 AM

You're still not hearing me :P. None of those have to do with a haste USE effect. You run your iterative loop twice, once with the haste effect on, and once with the haste effect off. Inside the iterative loop, you can do all your flurry/MW stacks/ED/Flurry. Your iterative loop is inside CalculateDPS(), your handling of the engineering haste on-use effect is outside of that loop.

Levva · 11/18/09, 7:36 PM

Originally Posted by ebs2002

You're still not hearing me :P. None of those have to do with a haste USE effect. You run your iterative loop twice, once with the haste effect on, and once with the haste effect off. Inside the iterative loop, you can do all your flurry/MW stacks/ED/Flurry. Your iterative loop is inside CalculateDPS(), your handling of the engineering haste on-use effect is outside of that loop.

Ah ok. That's not how I handle special effects at all. I get the base stats, accumulate the special effects procs into the base stats to get a combined stats total then do all the calculations of hit rates, crit rates, uptimes etc etc based on the combined stats. I'm only interested in the average uptimes etc anyway I'm not trying to model when a use effect is used. That goes closer to simulation than formulae.

I don't try to individually apply each and every special effect, wasn't that the entire reason a SpecialEffect class was created so that it did the work?? The results are matching up with EnhSim output so it seems ok.

I did try to have a look at how DPSWarr is doing it but still struggling to read it as its not the clearest of code at the current time, no doubt when you & Jothay have had time to do your re-factoring it will be clearer.

Schwolop · 11/19/09, 1:06 AM

Originally Posted by Levva

When you load the optimiser in the top left section you can add conditionals. So if you want to be spell capped regardless of buff you can click the Add button and select Hit Rating from the drop down now make sure the >= is selected and set the value to 446 which is the horde 17% cap. ie: it will now take the additional condition into play to optimise hit rating to be 446 or more.

So now it will optimise your gear based on the hit rating you specify as well as the default which is get DPS rating as high as possible. Let me know if that helps.

Wow. How had I not noticed that before? Thanks for pointing that out, and even more thanks for taking the time to track down the bug with hit rating. Rawr.Enhance is really getting to the stage where I'm almost prepared to just blindly follow its advice - at the very least it's at the point where I can suggest to new enhancers that they do so for a while!

Makke · 11/20/09, 3:27 AM

I am getting some strange DPS Falls in Rawr.

When i load my char into Rawr (Makkezor of Al'Akir EU) i get 8073,18 DPS Points and 529,80 Surv Points. When i click etc. Misery off because i have 16,2 % Spell hit and then apply Misery again my Surv Points fall to 484,80.

Another thing. Is Rawr.Enhance set up to automaticly use Unleashed Rage in its DPS Calc ? It is not selected pr. auto when you load a char into Rawr but when you put it on you see the same odd behaviour as above.

I am confused but it is a little over 6 in the morning here in Denmark and my coffee isent ready yet !

Bellante · 11/20/09, 4:39 AM

I don't pay attention to the survival rating so can't answer you there. However, Unleashed Rage is accounted for if it's in your spec, which you can easily check by removing a point in your talents; your dps will fall. Whether or not it's of the right proportion I do not know. I noticed that it wasn't ticked yesterday as well, which caused me to inspect it myself.

Makke · 11/20/09, 6:56 AM

Originally Posted by Bellante

I don't pay attention to the survival rating so can't answer you there. However, Unleashed Rage is accounted for if it's in your spec, which you can easily check by removing a point in your talents; your dps will fall. Whether or not it's of the right proportion I do not know. I noticed that it wasn't ticked yesterday as well, which caused me to inspect it myself.

The DPS will fall because of the talent also gives 3 Exp pr. point. Exp is the most valuable stat until capped and without the 9 from this talent your dps will drop dramaticly

Rouncer · 11/20/09, 9:38 AM

Originally Posted by Makke

The DPS will fall because of the talent also gives 3 Exp pr. point. Exp is the most valuable stat until capped and without the 9 from this talent your dps will drop dramaticly

Actually spell hit is the most valuable stat until capped but your point is still valid.

Levva · 11/20/09, 9:52 AM

Unleashed Rage is factored into the calculations according to your uptime, these days that's almost always 100% uptime. Ticking the buff should therefore make no difference. I might just tick it by default to save the questions in future.

The Survivability thing wasn't anything to do with Misery buff exactly the same effect happens regardless of which buff you change and this is due to "health" not being treated as a buffable stat. It was a minor bug which I've fixed for the next version.

Originally Posted by Rouncer

Actually spell hit is the most valuable stat until capped but your point is still valid.

Err no Rouncer, melee hit is the most valuable until you are specials capped, then expertise and THEN spell hit. These days it doesn't make much difference as someone who isn't capped is just regarded as clueless.

However if you cast your mind back to starting Naxx, we were all focused on getting expertise capped and spell capped. These days there is so much expertise and hit available its sometimes difficult not to be capped.