Sep 29, 2010 at 3:06 PM
Edited Sep 29, 2010 at 3:08 PM
I think you can get a very good answer without iteration, and your answer will be smoother (iterative solutions may see the score "jump" based on when you decide to exit the loop).
A) If you know in advance what your average haste is and what your rotation (priority list) is, you can deterministically find the average time between Eclipses, and the average time between casts of any particular spell. (for example, 2.1 Eclipses/minute
and 2.8 Insect Swarm casts per minute.
B) The numbers you can compute in (A) tend to change slowly and approximately linearly with Haste. This is probably true except at haste
breakpoints where DoTs gain an extra tick (and about 2s duration). However you can compute those breakpoints in advance, so we'll do that and adjust the algorithm accordingly.
1) Do the computations for (A) assuming 0% Nature's Grace uptime, and assuming 100% Nature's Grace uptime. Assuming those two haste levels crossed one or more DoT
breakpoints, do the computations for (A) at the haste levels just on either side of those breakpoints (breakpoint + .001% haste and breakpoint - .001% haste).
2) The computations from (1) give you a continuous piecewise-linear function that gives you a very good approximation for Eclipse duration and spell mix as a function of average haste. I'll call this function
SpellMix(haste). For a given spell-mix and Eclipse duration, you can compute.
Eq1: NGUptime = 25% * min(4, Dot_Casts_Per_Minute, max(eclipse_procs_per_minute, 1))
This equation is too optimistic at very high haste levels (where NG procs might overlap), but I think it is a good starting point.
Average haste is a linear function of NGUptime. Average haste is a continuous and piecewise-linear (it bends when (Eq1) makes a different min() or max() choice) function of
3) You can now "draw" the continuous piecewise-linear function
You have feasible solutions wherever Haste' = Haste. You are certain to have at least one feasible solution. In the rare cases where you get more than one, I'd be inclined to use the one with the highest DPS (almost certainly
the one with the highest average haste), since the skilled Moonkin has an incentive to "fudge" his rotation to get there (perhaps with a well-timed haste potion).
I think the Moonkin simulator "optimization" has always been restricted to computing the total-damage from each of several fixed rotations, and choosing the rotation with the highest total damage.
In Cata it will probably make sense to look at the DPS and DPM for each rotation, and find the mix of two rotations that is optimal for the mana situation. In LK there was very little point to that. LK Eclipse caused our highest DPS rotations
to also be our highest DPM rotations. The overall optimum was to spend all your mana on the highest DPS rotation, and then melee (Rawr just calls melee "oom", and treats it as zero DPS, which isn't a bad approximation).
In Cata, Moonkin pick up a "Scorch" equivalent (Lunar Shower talent). It provides a filler that does fair dps (>85% of our normal fillers) for very little mana. It is also likely that our highest DPS rotations will burn through mana
at an unsustainable rate. In mana-limited fights, a good optimization would either add a variable-fraction of "Scorch" to normal rotations, or use a mixture of heavily-Scorched, and Scorchless rotations.