first post in this thread, but been following it quite a while. I've recently specced balance with my druid, currently working on m'uru in SW. Was just wondering if druids that are stacking haste are still using an idol swapping macro. I used one before i had any haste and it worked wonders, but i'm starting to notice more problems with it now that i'm on around 200 haste without drums up.

I tried doing an idol swap macro last week on Gorefiend, and had some real issues. The problem I've noticed is that you lose the spell haste improvement on your GCD. Switching idols gives you a 1.5 GCD regardless of your spell haste, so you actually lose some of the advantages of spell haste over the course of the fight (Assuming that you use the macro which switches the moonfire idol in with the moonfire cast).

I'm not sure how that mod works off hand, and whether it can get around that limitation. It seems to me that the more haste you have, the more you have to lose from idol switching in that manner.

Also, if you switch at your last cast before your next moonfire, you're then losing one starfires' worth of the Starfire idol. That really minimizes the benefit you gain from the idol switching in the first place.

The optimal idol usage is starfire idol on all but the starfire before moonfire. Equip the unseen moon idol during your final starfire then equip the starfire idol on your first starfire after the moonfire.

If you equip the unseen moon idol in a macro with the moonfire spell you get 1.5 sec PLUS YOUR LATENCY in cooldown. This is due to a bug introduced when the /stopcasting system was removed.

You lose more by the bugged duplicate cooldown than you gain by having the starfire idol equipped for the final cast. This is presuming 0 haste. The more haste you get the worse this problem gets.

The problem with this system of equipping the unseen moon on the previous starfire is paying enough attention mid battle to know your next cast will be a moonfire. This is impossible for a mod to know as far as I can figure out. The documentation on the mod that was linked says it equips the idols based on the spell you cast. So it would equip the unseen moon idol on the moonfire cast and the starfire idol on the starfire cast, causing the duplicate cooldown bug and lowering your dps.

Personally I don't keep good enough track of my moonfire duration so I use the unseen moon all the time when I'm soloing and idol of the raven goddess when raiding.

So I finally got my Moonkin dps simulator to the point where I'm happy to let other people play with it and point out all the stuff that I need to fix and add.

Please read the readme!

You may need to install the .NET 2.0 Redistributable to get it to run:
Download details: .NET Framework Version 2.0 Redistributable Package (x86)

Download it here:
DrBoom_v10a.zip - FileFront.com

Interesting concept but what about crit? say you wish to maintain the 1:1 ratio after you're above 1077 spell damage and swap out some crit/dmg gems to do so. Whats the baseline crit you want to aim for? Is it like destruction locks and 25 percent?

My only qualm with this simulator is that it somehow doesn't follow with ado's gemming methodology. I am currently incorrectly gemmed with "too much" haste according to the math above, so the current stats are 1560dmg / 262 haste. Had I gemmed with epic hybrid gems mostly it would be 1614dmg/217haste, if I gemmed with mostly +12dmg, it would be 1632dmg/202haste. All of these stats gave basically exact same dps value even with drums of battles and heroisms when according to the math it should give quite a bit more dps as I made the stat changes.

What's funny is, the new version of Rawr was released with newly updated Moonkin support. I fully realize that the code isn't perfect yet, but I was wondering if any of you guys wanted to try it out and see if it gave results anything like you'd expect.

In other news, has anyone done any work on finding a closed-form solution to modeling haste? Currently Rawr tries to implement a second-order approximation for trinket haste effects, and while it should be "good enough" for the moment (I hope), it definitely makes things internally much more ugly than they should be. If it's already been done, though, I don't want to be duplicating someone else's work.

I haven't finished writing up the numbers and formulae yet, but from a very general standpoint, crit is never as good as any other stat you could be adding, even with Nature's Grace. You're going to get a bunch of incidental crit on your gear, and I wouldn't suggest actively avoiding it, but you'd never want to use crit gems. Given Hit-cap and the normal crit talents, you'd need almost 2000 spell damage before Crit's effective spell damage ratio hits 1. Everything else becomes useful soooo much more quickly.

I've picked up Rawr14 (using the optimizer right now), I'll let you know how things turn out. So far the number seem a bit more agreeable than they were before.

What do you mean about the closed-form model? Defining its affects on casting rotations?

[edit] Okay, wow. Rawr reeeeeally speeded up. Used to take upwards of an hour for a full-optimization run with the amount of gear I usually select. This was on the order of a couple minutes. Results: Before, Rawr would overvalue Crit, especially if I had lightning capacitor selected as available. It seemed to choose randomly between Potent and Reckless orange gems. Now, however, it seems to come up with very believable numbers. All gems are the same, it's not gearing me for Crit, etc. Seems a lot more correct. Only thing I'm worried about is that, given a selection of gear available (or soon-to-be) to my guild (3/4, 6/6, 1/5, 1/9), it doesn't select 4T5, and that seems odd. Might just be that the badge cloth is just that good, though/

Sure, that'd be easy to add. I'll put it on the list.

Yeah, I noticed I wasn't seeing the returns I was expecting out of haste, but obviously it's not based on Adorele's calculations at all, it's just simulating things as I believe them to be. So either something's impacting the value of haste, or I have a bug somewhere. I'll probably just release the source code after I clean it up a bit so people can "check my math".

Essentially, yes. What I would like to do is make it so that instead of going through an ugly implementation of a second-order approximation for haste trinkets and for Nature's Grace procs, as it is now, I can implement an equation that is essentially a lim(x->inf) f(x), where f(x) is some function that defines the behavior of haste procs in relation to cast time. It is my belief, though not yet demonstrated through rigorous math, that the iterative formula of proc-based haste effects is convergent.

I know that 1392 is the theoretical point where gemming for haste is better than gemming for damage, but do we know exactly how much better it is?