Jump to content


Photo

WrathCalcs - Moonkin DPS Spreadsheet


  • Please log in to reply
93 replies to this topic

#81 Hamlet

Hamlet

    Mike Tyson

  • • Guide Author
  • 11,567 posts

Posted 14 May 2009 - 07:19 AM

Ok, I gave a quick look through WC. I'll have time to explain these better and probably suggest fixes to the sheet on Fri/Sat.

--The Starfire Idol adds to base damage (and before all buffs to boot), rather than adding spellpower. I have no idea whether this is right or not, but it seems odd given the tooltip, so I figured I'd ask whether it's been verified by testing.

--You're not including the GCD's spent on Starfall/FoN. Instead of just adding their DPS to the Eclipse cycle outputs, you can first multiply the Eclipse output by (1 - (3 + SFallGlyph?)*GCD/180) before adding them. Not exact, but a good enough approximation (this is a small effect anyway). You could also deduct post-Eclipse DPS rather than average DPS, since we don't typically hit these timers during Eclipse (right?).

--My biggest skepticism right now is the accuracy of the latency/reaction modeling for Wrath/instants--it seems very conservative. I'll test soon, but can you really not spam wrath or instants faster than once every 1.4s? Doesn't seem to ring true with experience. Even if it's done purely empirically, we need some good estimate of how quickly you can actually spam Wrath so have any idea at all of how to value Solar rotations.

The rest of this is under the assumption that currently known best practice is to refresh DoT's during the Eclipse ICD and not during Eclipse itself.

--In the IS/Eclipse cycles, you're taking the GCD from one of the IS's out of Eclipse time instead of post-Eclipse time. Why?

--Same for the MF/Eclipse cycles--in a 2-MF rotation, you're deducting the second MF cast time from Eclipse. But not in the MF/IS/Eclipse cycle, for some reason. I imagine all DoT GCD's should be taken out of post-Eclipse time (but see talk of clipping below).

--In the MF/Eclipse cycles: you're computing the number of ticks as:
Min(RotationLength, UnextendedMF + ExtendedMF). But if you're clipping the first MF within the Eclipse CD, it's not actually going to be able to run for 15s, due to the room to have to leave at the end to cast the first Wrath (I posted about this earlier). Better: ExtendedMF + 12?

--Speaking of the first partial Wrath, you're taking half a Wrath cast off of pre-Eclipse time (presumably averaging over the randomness in the partially included first cast), but not deducting it from post-Eclipse time (which is when you actually start casting it).

--In the MF/IS/Eclipse cycle with 2MF's, you're not deducting the clipped IS ticks (which there will be if you're going MF-IS-IS-MF).

--In summary, you can't cram 4GCD's of DoT refreshing and half a Wrath into a 15s Eclipse cooldown without substantial clipping. We need some way to handle this. For now, just count the actual number of DoT ticks that will occur in the currently popular cast sequences, I think. If we want to, we could model the effects of refreshing DoT's at other times to see whether cutting into Eclipse or into pre-Eclipse time could be worthwhile, but for now let's make everything consistent.

--I like the idea of including that half a Wrath cast at the beginning of pre-Eclipse. We can improve accuracy by averaging out those dangling casts in other places as well. Eclipse is really shortened at the beginning by 1 SF in a Solar cycle, but in a Lunar cycle, it's often more like 1.5 Wraths (due to travel and reaction time). Eclipse is shortened at the tail end by the partial Starfire that you don't have time to fit in fully--I'd shorten Eclipse and lengthen post-Eclipse by half a Starfire (in Lunar).

--Combining these last two notes: The "real" duration of the post-Eclipse phase is 15s + half a Starfire (the one you don't cast at the end of Eclipse) - half a Wrath cast (winding up for pre-Eclipse) - 1 GCD (final DoT refresh before you start that Wrath) - Wrath travel time (let's estimate half a cast for now). This will almost always be between 12 and 14, I would think. So in MF-IS-IS-MF, the MF gets 4 ticks (as noted above). The IS is further shortened by 2 GCD's, and therefore gets 4-5 ticks. In IS-MF-MF-IS, the IS gets 6 ticks and the MF 3.

--Sliding further from WC commentary into substantive Moonkin theorycraft, note how the prior analysis makes IS-MF-MF-IS look equal to or better than MF-IS-IS-MF (which makes sense, as IS does more DPS while ticking). Note further that the DPET of a MF that only gets 3 ticks is rather low, somewhat calling into question the utility of 2MF cycles. (This is a brief summary of why I still run 1MF with Glyph of Starfire, but I wanted to get the discussion in here since it's relevant to the modeling).

#82 Hamlet

Hamlet

    Mike Tyson

  • • Guide Author
  • 11,567 posts

Posted 14 May 2009 - 06:15 PM

Here's a version of WrathCalcs with my reworked DoT rotation modeling. It basically reflects all the things I mentioned in the last post.

I should be able to post in more detail tomorrow about my current theorycraft conclusions, but I think this supports the suspicion I've been playing off of for a few weeks, that Lunar/1MF/GoStarfire has been a bit underrated. Also, GoStarfall looks a bit weaker when you account for the lost GCD.

Anyway, tell me what you think.

e: Cleaned up instant cast times. They now all point to one value in Basic Calcs (currently set to GCD+Latency).

Started doing some preliminary examination of cycles which put DoT refreshing at the highest priority. it's not in the main calculation yet, but see the bottom of the Eclipse rotation calc pages. At a first glance, cycles which simply ignore Eclipse and refresh DoT's whenever they drop are better than expected.

Attached Files



#83 Hamlet

Hamlet

    Mike Tyson

  • • Guide Author
  • 11,567 posts

Posted 18 May 2009 - 06:22 AM

Total Int and Total Spi on BasicCalcs include 37 for MotW even if you select "none" for MotW on the front page. Noticed this trying to do some naked testing.


On a more important note, you account for iMotW by multiplying Total Int and Total Spi by 1.02. But since base Int and Spi are read off of the charsheet, which already includes the bonus, you're overestimating final Int/Spi.

#84 Adoriele

Adoriele

    Happy October 19th!

  • Members
  • 10,089 posts

Posted 18 May 2009 - 07:16 AM

Total Int and Total Spi on BasicCalcs include 37 for MotW even if you select "none" for MotW on the front page. Noticed this trying to do some naked testing.


On a more important note, you account for iMotW by multiplying Total Int and Total Spi by 1.02. But since base Int and Spi are read off of the charsheet, which already includes the bonus, you're overestimating final Int/Spi.


Good point on the second. I'll see if there's any issue with just ignoring that part as relates to scaling, playing around with stuff that's already reflected in the character sheet can be a nightmare. As for the first, I assume that the raid is not composed of complete morons, and if you're not getting MotW from someone else, you're putting it up yourself. As well, think I make the check that if you have improved, and you select non-improved in the buffs section, it'll override and use improved anyway.

I'll get an eye on the last few posts' worth as soon as I can, work's been pretty busy for me lately, and Logan's taking up my non-raid times at home.

#85 Hamlet

Hamlet

    Mike Tyson

  • • Guide Author
  • 11,567 posts

Posted 18 May 2009 - 05:18 PM

Good point on the second. I'll see if there's any issue with just ignoring that part as relates to scaling, playing around with stuff that's already reflected in the character sheet can be a nightmare. As for the first, I assume that the raid is not composed of complete morons, and if you're not getting MotW from someone else, you're putting it up yourself. As well, think I make the check that if you have improved, and you select non-improved in the buffs section, it'll override and use improved anyway.

I'll get an eye on the last few posts' worth as soon as I can, work's been pretty busy for me lately, and Logan's taking up my non-raid times at home.


It's a pretty easy fix. Right now Int reads, for example, (BaseInt + ExtraInt + buffs)*Kings*Furor*iMotW. Change it to (BaseInt + (ExtraInt + buffs)*iMotW)*Kings*Furor . This should compute final Int correctly.

On the MotW thing, yeah, I just find it easier to pick whichever buffs I want to have active on the front page rather than making assumptions. It only really matters for theorycraft and experimentation though (that's in fact how I saw the iMotW thing), not for users.

---

On the last few posts--have you done much locally? I've been tinkering a lot while working on rotations, and will post another version soon, but don't want to wind up branching it too far.

#86 Adoriele

Adoriele

    Happy October 19th!

  • Members
  • 10,089 posts

Posted 18 May 2009 - 05:24 PM

It's a pretty easy fix. Right now Int reads, for example, (BaseInt + ExtraInt + buffs)*Kings*Furor*iMotW. Change it to (BaseInt + (ExtraInt + buffs)*iMotW)*Kings*Furor . This should compute final Int correctly.

On the MotW thing, yeah, I just find it easier to pick whichever buffs I want to have active on the front page rather than making assumptions. It only really matters for theorycraft and experimentation though (that's in fact how I saw the iMotW thing), not for users.

---

On the last few posts--have you done much locally? I've been tinkering a lot while working on rotations, and will post another version soon, but don't want to wind up branching it too far.


None, or at least minimal enough to be (I've done a few temporary things like making a quick look at relative stat values instead of absolutes, but I don't think I've saved any).

#87 Latas

Latas

    Don Flamenco

  • Members
  • 427 posts

Posted 19 May 2009 - 01:31 AM

Are there any plans to add in trinket modeling into wrathcalcs, for the chance on hit trinkets and such?

#88 Hamlet

Hamlet

    Mike Tyson

  • • Guide Author
  • 11,567 posts

Posted 19 May 2009 - 10:05 PM

Ok, here's my current update. There are a bunch of minor changes (which I probably should have tracked better). Also, I fixed the iMotW calculation.

The big thing is totally overhauled DoT modeling. The gist is as follows:
I adjusted the duration of each phase of the Eclipse cycle (pre, Eclipse, post) based on average dangling partial casts. See D27:D29 on each of the Eclipse rotation calc page.
There are now 4 DoT rotations modeled: 1) Refresh MF once/cycle and IS twice/cycle, 2) Refresh MF twice/cycle (clipping) and IS twice/cycle, 3) refresh any DoT whenever it drops, regardless of Eclipse, and 4) refresh any DoT whenever it drops, except during Eclipse (this one is incomplete).

1 and 2 are roughly the same as you had them before. They now hold more strictly to the current general wisdom that DoT refreshing should only occur during the post-Eclipse phase. DoT cast time is taken only from that phase, and DoT's are clipped to account for the duration of that phase (this is the big change I described in the first long post, already in the prior posted version). But now I also account for partial MF/IS uptime during Eclipse for IIS purposes. Notably, this somewhat increases the value of Glyph of Starfire in both cycles.

3 tries to model 100% DoT uptime with no clipping. It adds any DoT refreshing in the pre-Eclipse phase to the total cycle length, accounting for the Eclipse delay. In the other two phases, it deducts a proportional amount of execution time necessary to keep DoT's up.

Very notably, 3 is current returning better DPS than 1 and 2.

4 is an attempt to model DoT refreshing at all times besides Eclipse (including a cycle length extension) identical to 3. This is tricky and not finished. After I get it right, I might try to add a "only refresh during first X seconds of Eclipse" option, which I'm increasingly starting to think might be optimal.


Anyway, I tinkered with a lot of stuff, so it might be a bit annoying for you to read though, but I think I advanced the DoT refreshing model a good bit. Tell me what you think whenever you get a chance to take a look. You can ask me about anything I did too, I know I didn't comment it well. I tried not to interfere with the basic organization of anything.

Attached Files



#89 Erdluf

Erdluf

    Great Tiger

  • Members
  • 968 posts

Posted 19 May 2009 - 11:38 PM

I haven't looked at Ara's DoT models yet, but the spirit scaling is ignoring IMotW.

Change the formula in cell C55 to

=Spirit+(1+0.01*iMotW)

which is how much one spirit on gear will change your unbuffed caster-form toon. Alternatively, you could use Int's ExtraInt trick.

#90 Derrek

Derrek

    Banned

  • Banned
  • 28 posts

Posted 09 June 2009 - 08:32 PM

In the Eclipse formulas, the DPS is calculated by adding pre-Eclipse + Eclipse + Post Eclipse. On the Rotation and DPS spreadsheet, this number is added to the CooldownDPS calculation (Starfall + FoN).

The overlapping of seconds to acheive both of these objectives doesn't mesh. (Very similar arguments as the MF/ IS not being included as before.)

Regardless, the tool is extremely useful, and I'm appreciative of the work. Has anyone been able to approach their spreadsheet numbers?

#91 Hamlet

Hamlet

    Mike Tyson

  • • Guide Author
  • 11,567 posts

Posted 09 June 2009 - 08:48 PM

Are you looking at his version from the OP or my modifications from above? I deducted time for cooldown usage. It's not a big deal though, it doesn't change anything of note, except making Glyph of Starfall slightly worse.

#92 Derrek

Derrek

    Banned

  • Banned
  • 28 posts

Posted 09 June 2009 - 09:22 PM

Actually in both. Adoriele has 2 seconds included in there for IS / MF (I'm assuming that's why they're there) and your spreadhseet broke them down independantly. The Cooldown DPS is for Starfall / Force of Nature DPS to be added. Granted, it's only 3s GCD in a 180s window; but it's still 308dps for my alternative spec'd toon.

With a ~35s cycle length, it's an additional 35/180 * 3 = 0.583s added to the DPS calculation, which will lower the DPS value slightly. Even with these approximations, RL testing on my part is still ~15-20% lower than Hamlet's 5/19spreadsheet. My balance gear is still not at hit cap, which introduces even more RNG than I would like.

I'm still noodling through the MF / IS clipping of DoT damage. I like the concept, since 'reality' has my DoTs falling off quite a bit during the last bit of an Eclipse.

#93 Hamlet

Hamlet

    Mike Tyson

  • • Guide Author
  • 11,567 posts

Posted 09 June 2009 - 09:34 PM

Not sure what you're saying. In Rotations and DPS, I multiply the final Eclipse cycle DPS by (1-X*GCD/180) before adding CooldownDPS.

I never really get to benchmark against a single stationary target these days, but it's in the right ballpark.

#94 Derrek

Derrek

    Banned

  • Banned
  • 28 posts

Posted 09 June 2009 - 10:37 PM

Apologies. I was focused in on the 'IS, MF, Filler Eclipse Calcs' sheet and missed the calculation on the Rotations and DPS sheet. I see the new calculation on the 5/19 Hamlet document.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users