Archived

This topic is now archived and is closed to further replies.

Adoriele

WrathCalcs - Moonkin DPS Spreadsheet

94 posts in this topic

Actually, now that I think about it, Wrath's cast time should always be the GCD or less, which means it should never be queueable. I'm going to look into this, because that doesn't sound right, as I'm sure I've been queueing it.

As I understand it, the global cooldown is calculated only by the client. If that is true, then one should be able to send another spell request right after the GCD wears off. That would make spellqueueing of spells with casttime at the GCD possible without any problems.

That's more or less what Erdluf states in his post about this topic (at least when the GCD is well above 1sec).

In theory there should be no problem with a GCD of 1sec, because i think, that one cannot send a spell request during the GCD anyway, regardless of it's duration.

I don't claim to understand Erdluf's data, but it seems, that his sample size was exceptionally small:

NG Wrath results are ugly. Out of eight casts, only 2 were "on time."
8 wrath casts under the effect of NG, is insufficient in my opinion.

That's why I did tests myself.

I used the "/combatlog"-command to get precise data, which I then manually transferred into an excel-sheet for analysis. In 4 tests i did a total amount of 218 wrath casts (76 without and 142 with NG). To get the duration of the global cooldown i used "/script local start, duration, enable = GetActionCooldown(4);DEFAULT_CHAT_FRAME:AddMessage(duration)".

The GCD values where: 1,183sec without NG - 1,000 with NG.

My latency was around 100-150ms.

Here you can take a look at my data and calculations.

These are the results of my testing (in ms).

[TABLE=head] |ideal|actual|offset

cast time|1183|1263|80

NG cast time|1000|1108|108

average cast time|1066|1164|98[/TABLE]

I think the offset results from the time difference between the end of the GCD and the next key press. This would explain the larger offset of NG casts. Casting under the effect of NG, you sometimes get Not-Ready messages, which can delay the next spell request a little bit.

Latency seems to have no effect on (chain)casting at a 1sec-GCD just like above it.

I would really like to see some more data from other people, especially with higher latency, to verify my results.

A very nice project like this (thanks Adoriele) should be supported with the best numbers we can get.

Share this post


Link to post
Share on other sites

Skjaven's numbers "feel" reasonable to me. It is a nice large sample. NG has more uptime than before, so it is less of a surprise when it happens (particularly on a target dummy where I had a very low crit rate at the time).

Also, the gap in "ideal" cast times is smaller than mine was, meaning smaller adjustments to your timing.

Higher latency might not be a problem if it were consistent. The problem would be if it is variable. You press your keys at times 0.0 1.0 2.0, but they arrive at the server at 0.3, 1.6, 2.3. Your second cast begins late, and your third cast fails entirely because it is too early.

Even before 3.1 we were seeing WWS where people's "idle" time was smaller than implied by my tests, so they had better connections and/or more skill.

For you, it looks like cast times should be modeled as max(1.108, ideal+0.08).

Share this post


Link to post
Share on other sites

I ran the same kind of test as Skjaven, but included some more spells.

Filtered out the non-NG casts in OO so was looking only at casts with NG active.

For wrath, effect was pretty much identical to what Skjaven has, around 100ms added to each cast(I also did the test with moonfirespam and it was identical to wrath, so it doesn't look like wrath is getting queued at all). Wrath casttime was 1.025 ingame, 1.115 combatlog.

I also tested it with nourish as well and again, it was identical to the wrath results.

For starfire however, my latency seemed to have no effect at all on the casttime, ng-d starfire had 2.05 casttime ingame and 2.06 average from the combatlog results. What was interesting though was that according to combatlog some starfire casts were faster than 2.05, which should be impossible. Lowest was 2.01 I think, probably a combatlog error in this case?

Also, I remember running the test before wotlk and testing out wrath under bloodlust. For normal wraths and wraths with totem, results were the same as the current ones. For bloodlusted wrath however, combatlog gave a 1.01 average casttime which would indicate that they did get queued. By this time it's pretty much anecdotal data, but it does suggest that there is something weird going on with gcd-length spell queuing. Also, since the bloodlust test was pre-wotlk so before NG change, it couldn't just have been the fact that wrath casttime dropped far below gcd that made the difference under bloodlust.

Share this post


Link to post
Share on other sites
IWhat was interesting though was that according to combatlog some starfire casts were faster than 2.05, which should be impossible. Lowest was 2.01 I think, probably a combatlog error in this case?

I believe combatlog timestamps are client-side, and thus subject to variations in latency. That is one reason you need many trials to get reliable results.

I also believe that Blizz places different priorities on messages. Changes in buff status seem to have a higher priority than damage-done messages. I'll often see buff changes (like Eclipse) a couple of hundred milliseconds before I see the hit that proc'd it.

Share this post


Link to post
Share on other sites

In WC 1.3.1, the NG uptime for Wrath is wrong.

Cell with label "Wrath NG Uptime" on the "Wrath Calcs" sheet has formula

"=1-POWER(WNGProcChance,(FLOOR(3/WrathCast,1)+1))"

which should be changed to

"=1-POWER(1-WNGProcChance,(FLOOR(3/WrathCast,1)+1))"

It doesn't make a difference with the default character sheet numbers, but if you adjust Reaction and Latency to match Skjaven's numbers (.08 Reaction and .03 Latency) it makes a difference.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

WrathCalcsv1.3.1 Hamlet.xls

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

WrathCalcs Hamlet 090519.xls

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.