This project is read-only.

Moonkin Cast Times

Topics: Rawr.Moonkin
Oct 15, 2009 at 3:00 PM
Edited Oct 19, 2009 at 2:32 PM

Edit: Fixed simulationcraft times.

Numbers not changed here, but Rawr.Moonkin has been changed since this post.  Rawr DoTs should have a cast time very similar to Wrath in most circumstances.


Computing Moonkin Cast Times

TLDR:  Rawr charges a lot of cast time for instants, compared to other tools.  Encounter-average Moonkin casting time-costs (cast time+lag) in Rawr, WrathCalcs and SimulationCraft assuming "usual" talents, and a 52.27% Wrath crit rate, at the haste soft-cap (400 haste from gear).  I'm not saying which tool(s) are "right."  I would like the discussion to explore that issue.

It is possible that I goofed up somewhere.  Let me know.

Time-cost of casting a spell in a particular tool:


  • MF,IS=1.3s
  • Wr=1.12s
  • SFEclipse=2.0s



  • Wr,MF,IS=1.22s
  • SFEclipse=2.1s



  • Wr: 1.04s
  • MF: 1.11s
  • IS: 1.14s
  • SF: 2.02s

Since many Moonkin spells have an effective cast time of about 1.0s, a small change in cast time (say 50 ms) can make a 5% change in reported DPS.

A more detailed look:

  • WrathCalcs (WC), an Excel spreadsheet maintained by Arawethion, at EJ.  I'm looking at the 090917 version.  There is a link to it at the bottom of the first article at .
  • Rawr, at The Moonkin module "lead" is Dopefish.  I'm looking primarily at the code for release 2.2.23, changeset 37550.  The files are in the Rawr.Moonkin folder and are SpellRotation.cs, and MoonkinSolver.cs.
  • Simulationcraft (SC) at maintained by Nate Heiter (Druid module gets a lot of work by Twigele).  I'm looking at revision r3581.





WrathCalcs has two user-set "delay" parameters, QueueDelay and InstantDelay.  These default to 0.1s and 0.2s, respectively. (Edit: Assigned numbers in correct place)

Formulas {value at haste softcap, with default spec and delays, Wrath crit at 52.27%}

  • GCD = 1.5/(1+TotalHaste)  {1.2}
  • InstantCast = GCD+InstantDelay {1.4}
  • NGGCD = Max(GCD/1.2, 1) {1}
  • InstantCastNG = NGGCD+InstantDelay {1.2}
  • WrathCast = Max(1.5/(1+TotalHaste), InstantCast) {1.4}
  • WNGCast=MAX(1.5/(1+TotalHaste)/1.2+QueueDelay, InstantCastNG) {1.2}
  • WSpamCast=WNGUptime*WNGCast+(1-WNGUptime*WrathCast) {1.22}
  • ISCast=InstantCast*(1-WNGUptime)+InstantCastNG*WNGUptime {1.22}
  • MFCast=ISCast {1.22}
  • SFCast=MAX(3/(1+TotalHaste)+QueueDelay, InstantCast) {2.5}
  • SFNGCast=MAX(3/(1+TotalHaste)/1.2+QueueDelay, InstantCastNG) {2.1}
  • SFCastEclipse=(formula similar to WSpamCast) {2.1 at 100% crit}


For practical purposes, cast times are

  • Wr,MF,IS=1.22
  • SF=2.1


In WC, DoTs benefit from NG just as much as Wrath.  Both have a fairly steep latency penalty.  SF has a moderate latency penalty.






Rawr.Moonkin uses a single latency value (defaults to 0.1s).  However, in some circumstances (DoTs at high haste levels) that value is effectively doubled, and SF usually ignores it.

Formulas (simplified, and names changed from code, for clarity)

For Dots, it appears to me that Rawr never uses the NG spellHaste

  • ISCastTime=Max(1.5 / (1 + spellHaste), 1.0f + latency) + latency {1.3}
  • MFCastTime=ISCastTime {1.3}


Nukes use

  • gcd = 1.5f / (1.0f + spellHaste) {1.2}
  • instantCast = Max(gcd, 1.0f) + latency {1.3}
  • ngGCD = Max(gcd / 1.2f, 1.0f) {1}
  • instantCastNG = ngGCD + latency {1.1}
  • normalCastTime = Max(talented_base / (1 + spellHaste), instantCast); {1.3 for Wrath, 2.4 for SF}
  • NGCastTime = Max(talented_base / (1 + spellHaste) / (1.2), instantCastNG); {1.1 for Wrath, 2.0 for SF}
  • CastTime = (1 - NGUptime) * normalCastTime + NGUptime * mainNuke.NGCastTime; {1.12 for Wrath, 2.0 for SF during Eclipse}


For practical purposes, cast times are

  • MF,IS=1.3
  • Wr=1.12
  • SF=2.0

In Rawr, DoTs get no benefit from NG.  DoTs and Wrath have a moderate latency penalty, and SF has no latency penalty.  Rawr casts nukes 5-10% faster than WrathCalcs, and casts instants 7% slower than Wrathcalcs.





SimulationCraft has four parameters for lag:

  • A parameter for queue'd spells.  I believe this is used even when the cast time is less than 1.0s.  In the sample outputs it is 0.01875s.  I'll round that to 0.02s in my numbers below.
  • Two parameters for GCD spells.  One is a penalty for an instant spell.  One is a bonus (un-penalty) for casting an instant after a cast time spell.  The default penalty is 0.15s.  The default bonus is 0.075s.  Since most of our spells are not instants, in the numbers below I'll pretend SC uses a fixed penalty of 0.09s.
  • A parameter for channeled spells.  Since SC doesn't handle Hurricane, this doesn't impact Moonkin simulations.

The GCD spell testing used as a basis for the two-parameter system was done by a Mage.  I strongly suspect it did not involve cases where cast times were less than one second.


SimulationCraft models NG as it happens.  The raw cast times it uses will match the other two tools:

  • MF,IS,Wr = 1.2
  • SF=2.4
  • SFNG=2

and the Spam numbers before lag will be

  • WrSpam=1.02
  • SFSpamEclipse=2.0

How much time do DoTs cost, on average?  Consider the cast sequence

  • Wr1 Wr2 Wr3 IS Wr4 Wr5 Wr6

I'd say the time cost of IS is the time of that sequence, minus the time of 6*WrSpam.  That difference is the cast time of IS, plus the increased cast times of Wr4, Wr5, and Wr6 due to lost NG.

The time of the IS (in SC) will average 1.02 (the same as a Wrath, in WrathSpam).  The NG probablity for Wr4, Wr5, and Wr6 will all drop from 89% to 77% (a loss of 12%), and the penalty for losing NG is 0.2s.  The before-lag cost for the IS here is

  • 1.02+3*12%*.2 = 1.09s.

In the EclipseSF case (with 100% SF crit) we see


the IS is a 1s cast, and no SF ever loses NG, so the cost of IS is just 1s.  At lower crit rates the penalty can be quite substantial, since a loss of NG is a 0.4s penalty.  I'm not doing that math here.

As a rough approximation, assume half of IS occur during wrath spam, and half occur during lunar eclipse, the average cost of IS is about 1.05s.

If we plug MF into SF spam it gets the same result as IS.  The cost is 1s.  If we plug MF into Wrath spam, we have to consider the possibility of MF crits.

  • Wr1 Wr2 Wr3 MF Wr4 Wr5 Wr6

The MF cast itself, will average 1.02s.  Using capital letters for crits, the following sequences cause changes in Wr4, Wr5 or Wr6 cast times.  I'll use an MF crit rate of 48.27% (no IMF)

  • WR1 wr2 wr3 mf: the mf causes Wr4 to lose NG 6% chance
  • wr1 wr2 wr3 MF: the MF causes Wr4 to gain NG 5% chance
  • WR2 wr3 mf wr4: the mf causes Wr5 to lose NG 6% chance
  • wr2 wr3 MF wr4: the MF causes Wr5 to gain NG 5% chance
  • Wr3 mf wr4 wr5: the MF causes Wr6 to lose NG 6% chance

Note that Wr6 cannot benefit from an MF crit (In SC, with zero lag, it would benefit at >=401 haste, in cases where the MF itself was cast under NG).

On average there is an 8% chance that the sequence will take an extra 0.2s, so the penalty is about 0.02s, and the total MF cast cost is 1.02+.02 = 1.04s.  With half of MF during Wrath, and the other half during SF, the average MF cast costs about 1.02s.

SC average cast time costs are approximately (these include lag, numbers above did not):

  • Wr: 1.04s
  • MF: 1.11s
  • IS: 1.14s
  • SF: 2.02s

In SC, MF gets 100% benefit from NG, and IS gets about 75% (compared to Wrath) of the NG benefit.


Oct 15, 2009 at 4:19 PM

I had changed the cast-time model of nukes to match WC, but I hadn't noticed the cast-time model of DoT's had been changed to match.  It'll be in the next version.  This would likely explain why the DPS number of Rawr is so much lower than WC, although with the changes in 2.2.23, at least the differences between rotations are lining up.

Oct 16, 2009 at 1:23 AM

I did some quick tests and I can see a random lag getting applied between "player performs xyz" and "player schedules execute for abc" in the log.....  The lag values are pretty darn small in my view, but the hard-core raiders on the dev team get upset when I try to ninja-edit an increase.


Oct 16, 2009 at 3:37 AM


I don't have svn on my machine right now, but I went to and told it to search the trunk for "queue_lag".  It looked like it was being set in a few places, but the only place it was being used in a calculation was in sc_scaling.cpp (to compute its scale factor).

In the scale factors at the bottom of every single spec has a scale factor of 0.00.

Oct 16, 2009 at 4:45 AM

I can follow up directly with more details, but just some quick info:  The majority of lag handling is found sc_player.cpp player_t::schedule_ready().  The scale factors in that report are all zero, because I didn't ask the sim to perform the scale factor calculations for lag, not because lag isn't modeled in regular execution.  The scale factors for lag are calculated in a mind-numbingly dumb fashion: Simply at 100ms to the three types of lag values and see what happens.  I was anxious to save a bit of runtime, so turn off the lag scale factor calculation by default.  I really should remove that from the report if it is not calculated.

One very subtle handling of lag in SimulationCraft that is not very well known: Tigafin did some interesting research to show that a "queued" instant appear to start the GCD a little earlier than expected.  There is a measurable difference between Cast-Instant-Cast-Instant-Cast-Instant and Cast-Cast-Cast-Instant-Instant-Instant.  That is handled in sc_action.cpp action_t::schedule_execute().


Oct 16, 2009 at 2:18 PM


I'll take a closer look at some SC log files, and update my first post here.  I'll may have some more questions on how SC is handling timing, but I'll take those to another venue, and stop abusing Astrylan's bandwidth.