Guest Post: Yuki Learns you Stat Weighting (p2)June 24, 2009
As stated last week, here’s the post outlining how to determine weights to plug into lootrank to figure out your best in slot. It’s a general list written by (alas) a DPS-type, so it’s not aimed at healers specifically, but I hope you all can still find it useful. Yuki’s been my guildie, my buddy, and enabler of my anime addiction for several years now. He’s also the first person who told me that such a thing as mathcraft exists. Be warned, there’s numbers ahead.
Step 4: Methodological Chaos
At this point, there are basically three potential methodologies for settling on the final values to be used: The Quick and Dirty method, the Numerical Model method, and the Simulation method.
Whichever method you choose, at this point you’ll need to know a few things: the average non-crit heal/damage/threat/whatever for each ability you use, whether and how each ability scales with your baseline stat (so, for instance, if an ability gains extra potency per spellpower due to a talent), and whether the ability scales with any other stats (can it crit? affected in any way by haste? etc), and how frequently you use each ability. For the quick method, you can get the last one from a WWS report, but in general you’ll get better results if you determine it from your ideal usage or rotation.
4a: Quick and Dirty
The fastest way to generate values is to just do them based on a parse. First you’ll need to know how much a point of spell power adds to each ability’s net effectiveness. Look up its scaling coefficient and figure out how much 1 spellpower would actually increase that average use of the ability. You’ll be using this as a point of comparison to determine how much each ability actually scales per point of other things; I’ll henceforth be referring to it as “the baseline scaling value” of for that ability.
Second, you pull out all your averages for all your abilities, and your % usage for each. Next, figure out how much each would scale with 1% effectiveness of each rating you’re trying to calculate a weight for. Divide this value by your baseline scaling value, then multiply it by the % of usage your WWS report shows; sum these values up to get your effective spell/attack power value for 1% of each rating, from which you derive the final ESP/EAP per rating point by dividing by its conversion factor for you level.
Advantages/Disadvantages: The advantages of this method should be clear, as well as its drawbacks: it’s pretty easy, doesn’t take too long, and requires relatively little mathematical modeling, but it’s also really, really bad at things like haste on abilities with cooldowns. But if you’re just looking for a quick approximation and you don’t plan to redo your weights ever, its numbers aren’t too horribly off unless you’re very dependent on those kinds of things.
4b: Numerical Modeling
This is the “purest” methodology, and also the one that’ll be your best bet if you’re planning to really do a lot of your own stat weighting, since it’s the easiest to revise.
Essentially, you model what your ideal rotation would look like in practice. I’m going to use an offensive spell as my example, because it’ll give me a chance to show how to model hit and similar stats.
Start with the average base damage of the spell. Because you’ve already determined how your rotation works, you’ll know how many times you can cast it during that time. Therefore its total contribution of damage during your rotation is:
Damage = (Times cast) * (Average Base damage)
Now, we add in spell damage scaling:
Damage = (Times cast) * (Average Base Damage + [Baseline Scaling Value * Spellpower] )
To add crit, we’ll start with the value of a crit, which is (1 + Crit Bonus Damage Value). Now we multiply that by your chance of actually getting a crit, which is Base Crit + Crit Rating/Crit Conversion. Add all that to one and multiply it by the original value and you’ll have modeled what your damage from that ability would be with crit!
Damage = (Times cast) * (Average Base Damage + [Baseline Scaling Value * Spellpower]) * (1 + (1 + Crit Bonus Damage Value) * (Base Crit + Crit Rating/Crit Conversion)
Hit works as basically a “penalty” on damage until it’s capped. Whatever damage you could have been doing would be a miss, so it’s 1 – Miss Rate + Hit Rating/Hit Conversion in a ceiling function that can never be above one. For notational simplicity I’ll just assume we’re below the hit cap. Note that “Miss Rate” above includes everything other than hit rating that increases your chance to hit (like misery or a draenei aura), because we’re only comparing the gear stats, so those should be included in the baseline of the model.
Damage = (Times cast) * (Average Base Damage + [Baseline Scaling Value * Spellpower]) * (1 + (1 + Crit Bonus Damage Value) * (Base Crit + Crit Rating/Crit Conversion) * (1 – Miss Rate + Hit Rating/Hit Conversion)
Haste is where things get interesting. If the ability in question is not cooldown limited, you can effectively cast it “more times”, so our Times Cast actually scales with haste.
Damage = (Times cast * (1 + Haste Rating/Haste Conversion) * (Average Base Damage + [Baseline Scaling Value * Spellpower]) * (1 + (1 + Crit Bonus Damage Value) * (Base Crit + Crit Rating/Crit Conversion) * (1 – Miss Rate + Hit Rating/Hit Conversion)
What if it IS cooldown limited? Well, in this case, it basically doesn’t scale with haste even if its casting time would be reduced; you can never cast any more of them than the cooldown allows. But because you’re casting it faster, you have more room for casting other things in your rotation, so those can actually generally be modeled as scaling normally with haste unless you’re trying for complete precision, because they can fill in the extra time left open even though you’re squeezing them between cooldown casts.
This example should show you basically how to handle all the various ways to scale when modeling. Your final equation will be the sum of all these terms. Run through it first for only the baseline stats you selected earlier, then once for spell damage; the difference between these two becomes your baseline scaling value for the whole rotation. Now just add a point to a rating and solve through and divide by the baseline scaling value for the ESP/EAP value of that stat.
Advantages/Disadvantages: If your eyes glazed over reading this section you will probably hate this method. It’s very math intensive, and requires you to think like a numerical modeler, which can be hard if you’re not a numbers person. Also, an error in the model can lead to grossly inaccurate results; this can occur as a math error, or just in terms of how you model your ideal rotation, so there’s a lot of points of potential fail.
On the other hand, if you get it right, you have a comparatively easy way to change your baseline (just change the values), and you’re ahead of the game if your rotation changes (since you can just fiddle with the numbers a bit). If done well it also produces the best numbers theoretically possible.
This method is both similar to and very different from the previous. Basically you build (or download) a simulator for your class that effectively “runs” a combat action-by-action for an arbitrarily large amount of time and reports back its results. You basically just tweak a base value, run the simulation, and compare it to a baseline simulation to determine the comparative value of each stat.
Advantages/Disadvantages: Building your own sim would, of course, require programming knowledge and a slightly less rigorous form of numerical modeling. Downloading someone else’s requires neither of these, but also requires that you trust THEIR programming knowledge and numerical modeling. You could also run in issues of RNG-fail, but a sufficiently arbitrarily large number of actions should statistically smooth those out.
The biggest advantage that this method has is that it’s the best option for procs and other random mechanics. Trying to do a numerical model for something like Windfury (a 20% proc with a 3 second internal cooldown) will quickly make you want to throw yourself under a bus. I’ll talk about trying to model procs in the following section, but suffice to say this method produces more accurate results than that one.
Part two is done! You’ve almost made it. Stay tuned for the final bit tomorrow!