Hamlet

[Balance] WrathCalcs

969 posts in this topic

Hello, I have a question about WrathCalcs, I just downloaded it, and was about to put in the gear my druid has and all that stuff, but when I got to the reforges, I noticed that the  stats isn't correct. My helm, "Circlet of the Panser" WF 1/2 upgraded. In-game it says it took 545 off mast to reforge into haste, but wrath calcs only does 524 spi -> haste. if this is the case all the time, my caps/breakpoints won't be correct, and I won't be able to get the most out of WC. So I wondered if I can go and change the numbers myself, or will that mess up everything?.

On forehand thanks

Share this post


Link to post
Share on other sites

---EDIT---

Hamlet and Celestalon clarified this for me on Twitter and Hamlet wrote a post on his blog explaining how these partial tics actually work. In short, using the example below, the total duration of the dot will stay fixed at 14 seconds. After each tic, the time until the next tic is calculated based on current haste. If the buff is allowed to fall off, at 14 seconds it gives a final partial tic. The dot can be refreshed any time in the last 30% of its duration (4.2 seconds) using a Pandemic-like mechanic. If it is refreshed, there are no partial tics.

 

This alleviates the concerns that I had below. DOT DPS and DPC both scale evenly with haste. My error below was assuming that partial tics would extend the duration of the DOT by the same amount as a normal tic. Instead, the partial tics only occur at the end of 14 seconds when the DOT falls off without being refreshed.

---EDIT---

 

 

I was messing around in WrathCalcs trying to model different ways that Blizzard might implement the partial dot tics that they mentioned at BlizzCon. However, I can't think of a way they could remove the damage per cast breakpoints that we have now without adding new damage per second breakpoints. I haven't been following the theorycrafting community's response to the dot changes, so maybe someone has already addressed this issue? I would appreciate any input.

I'll try to lay out my reasoning in a non Moonkin-specific way.

The current state of DOTs
Let's consider a dot with a base duration of 14 seconds, a base time between tics of 2 seconds, and 10 damage per tic.

If the dot is reapplied between its second-to-last and its last tic, the last tic is not lost. Instead the dot is 'refreshed', i.e. the 14th tic of the previous application does its damage and then the first tic of the new application begins.

We can measure the damage that this dot does in two ways:

  • DPS, the average damage per second that the dot does if it is continually refreshed (the damage per tic / the time between tics)
  • DPC, the average damage per cast of the dot (the damage per tic * the number of tics)

With the current system of dot tics, the DPS of a continually refreshed dot scales linearly with haste (the time between tics = the base time between tics / (1 + haste)).

The DPC of a dot is a step function because certain values of haste give an extra dot tic (the number of tics = the base duration of the dot / the time between tics, rounded to the nearest integer).

2nEzcAx.jpg
(For ease of viewing, the above plot and all following plots were scaled to actually show damage per 14 seconds instead of damage per second.)

In situations where we can keep up our dots with 100% uptimes, these DPC haste breakpoints do not matter at all. The overall DPS of our dots will scale linearly with our haste. However in situations where dots occasionally fall off without being refreshed (multi-target fights, fights where we don't have 100% uptime on the boss), it can be a nontrivial overall DPS increase to meet these breakpoints.

 

The solution to DPC breakpoints? Partial tics
In an effort to eliminate these DPC haste breakpoints, Blizzard announced that dots will have partial final tics. Let's work an example with haste at 20%.

 

Under the current system:
time between tics = 2 / 1.2 = 1.667 seconds
number of tics = round(14 / 1.667) = round(8.4) = 8 tics
The dot will do 10 damage per tic for 8 tics. This yields 80 DPC and 6 DPS.

Under the partial tic system:
time between tics = 2 / 1.2 = 1.667 seconds
number of tics = 14 / 1.667 = 8.4 tics
 

8.4 tics? What does that mean?

 

A few potential options:

  1. A weak extra final tic. 8 tics for 10 damage and 1 tic for 4 damage. 84 DPC and 5.6 DPS.
  2. A strong final tic. 7 tics for 10 damage and 1 tic for 14 damage. 84 DPC and 6.3 DPS.
  3. Another way of implementing option 2. 8 tics for 10 damage and 1 tic for 4 damage. However, if the dot is refreshed the first tic of the next dot gets added to the last tic of the current dot, so when continually refreshed each dot has 7 tics for 10 damage and 1 tic for 14 damage. 84 DPC and 6.3 DPS.
  4. Weak or strong. The number of tics is calculated the same as it is currently, but the final tic is scaled up if the fractional tic is less than 0.5 or down if the fractional tic is greater than 0.5. 84 DPC and 6.27 DPS.

Let's take a look at how the DPS and DPC of each of these possibilities scales with haste:

J5QUmKq.jpg
h1aLK1H.jpg
yFcQYig.jpg

So, these options for a system of partial tics remove the DPC breakpoints but add DPS breakpoints. We can think of it like this: as our haste rises, our final dot tic becomes stronger and stronger until we hit a haste breakpoint and get an extra tic. However, that extra tic is weaker than the average tic from before we hit the breakpoint, so our average DPS goes down.

This would give us a set of inverted dot DPS breakpoints. We would want to get as close as possible to a certain haste value without going over.

These DPS breakpoints would be especially important in fights in which we have 100% uptime on our dots. They would have less of an impact in fights in which dots often fall off without being refreshed since the DPC of the dots scales linearly with haste.

Some thoughts on merits and downsides of the different options:

  • Option 4 has the advantage of making the haste DPS breakpoints at the same haste levels that the DPC breakpoints are currently at (though we would want to be just under these breakpoints instead of just over).
  • Options 1 and 4 present a clunky way to game the system. A skilled player could improve her dot DPS at suboptimal haste values by clipping her final tic if it is going to be weaker than the average tic.
  • Option 2 doesn't have this clipping issue since the final tic is stronger than or equal to the average tic at all haste values.

Final thoughts

I'm going to work on trying these options out in WrathCalcs to get a sense for how important these dot DPS breakpoints would be relative to the dot DPC breakpoints that we currently deal with. My guess is that they will be  significant to our overall dps (especially in the single target, nearly 100% dot uptime situation that WrathCalcs is modeling in current gear). However, I don't think they'll end up being as important as the current DPC breakpoints are, especially when we level to 100 and haste and crit levels drop off dramatically and we end up in a regime where our optimal single target rotation could have less than 100% dot uptime. In such a rotation, or any situation in which dots are often either overwritten or allowed to fall off these DPS breakpoints will be much less important.

Any thoughts for ways that Blizz might try to implement dots that could remove DPC breakpoints without adding DPS breakpoints? I'll feel really silly if someone points out a simple solution after I spent so much time writing this...

 

Edit:

  • I guess one option could be to stop adding extra tics altogether. Just let the total dot duration get shorter and shorter the more haste we have... but that introduces bigger problems than it solves.
  • Another option could be to make dots much finer grained. Same overall dot length but more tics and less damage per tic. This would not remove breakpoints, but would make them less important.
  • Another thought: maybe use the weak extra final dot option, but make the final tic happen faster in some way that's inversely proportional to its power?
Edited by Tarm

Share this post


Link to post
Share on other sites

Updated for 4-level VP upgrades. Let me know if anything still doesn't work, I might have missed something. Also if anything else is worth updating in 5.0; I'll mostly be looking at 6.0 now.

 

 

WrathCalcs 140526.xls

Edited by Hamlet

Share this post


Link to post
Share on other sites

Not sure where the discrepancy is, I checked each item, but it is showing my haste about 500 over what it should be and crit about 900 over what it should be. It is also showing my mastery over what it should be but I tracked that down to it not taking away mastery when I reforged my cloak. Please tell me what you will need from me to help track down what is going on with the latest wrathcalcs.

Edited by Latas

Share this post


Link to post
Share on other sites

Can you link your profile, and a copy of the sheet with matching gear input? I'll see whether the discrepancy is (or, you might be able to easily see which item isn't showing the same stats).

Share this post


Link to post
Share on other sites

See if this looks better. I think it has everything right up to rounding errors, except for around 20 missing Int/Spirit due to maybe the racial base stats being off.

 

Comparing is a little weird since the pink column on "main" doesn't correctly include Amp. The bottom row on the Gear setup tab does, but its Int is different since it doesn't include HotW/LeatherSpec. (Part of the reason I'm trying to simplify all this for 6.0).

WrathCalcs 140526 Latas.xls

Edited by Hamlet

Share this post


Link to post
Share on other sites

There seems to be a bug regarding Signet of the Dinomancers. Stats dont match (not just a rounding error since its more than 1 stat off) and socket bonus is wrong (currently 60 spirit in WC while it should be 60 haste)

Share this post


Link to post
Share on other sites

Fixed socket bonus. The haste being off by 5 is rounding--it's just gotten bad with 4 levels of upgrades (we didn't store 5 upgrade levels of 6 versions of each item in the sheet; it estimates based on ilvl). Another reason why in the future it's better to get stats from somewhere else that's better at handling exact stats (like the Wowhead profiler), and have the sheet just be for modeling. Probably unlikely to fix it with upgrades being gone in 6.0.

WrathCalcs 140528.xls

Share this post


Link to post
Share on other sites

when i try to import says:

error runtime here... can u help me?

 

this line here:

 

Range("G1") = Application.WorksheetFunction.VLookup(Char.race, Range("racelookup"), 2, False)

Edited by Dkgonas

Share this post


Link to post
Share on other sites

How does the SS waste parameter work now?

 

I remember before it was done in percentage we got from WoL  e.g for 30% wastage we would input 0.3. But now I don't know what to put in it :S

Share this post


Link to post
Share on other sites

yes im 32-bit excel

can u show how to put the server aggra (português)?

and the name is name:character name or character name?

Range("G1") = Application.WorksheetFunction.VLookup(Char.race, Range("racelookup"), 2, False)

this is what show me on debug about the error

Share this post


Link to post
Share on other sites

Just enter your character's name in the name box, Aggra in the server box and choose your region on the righthand side.

If it still doesn't work, please post your character's armory and I'll have a look when I get home. Normally you'll only see that if it can't find your character on the Armory.

Share this post


Link to post
Share on other sites

Ahh, Blizzard don't refer to your realm as Aggra, they refer to it as Aggra-Portugues. If you use that for your server it should resolve your issue.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.