
Originally Posted by Aldriana
Just as a public interest point: I took some time this evening to poke through the AToL modeling to try to resolve the previously noted discrepancies between this sheet and mine. The difference is as follows: my sheet computes cycle length based off your sustainable energy regen - that is, using a Haste Pot doesn't decrease the average length of your cycle. It may make that one cycle that it occurs during shorter, but it doesn't change anything in terms of the long term average. This is, of course, not precisely true, but it struck me as a reasonable approximation. This sheet, on the other hand, gives the full average-case cycle reduction due to these. This is also a reasonable approximation, but it's not immediately clear to me whether it's superior or not. My gut is telling me that the true answer probably lies somewhere in between, but I'd have a hard time proving that.
Regardless: what this means is that with buff setups with lots of activated haste, this sheet approximates the cycle length as being significantly shorter, which leads to a corresponding increase in Ashtongue uptime, at least in longer cycles.
That said: there also seems to be some manner of glitch in the AToL uptime calculations for shorter cycles; for instance, if I set the cycle with 1s3r with the default gear + buffs, it indicates that my overall uptime is 65.89%, but only 63.71% on CP Builders. It seems unlikely to me that energy queuing actually *lowers* the number you land within the buff, which makes me suspect some manner of glitch in the calculations.
|
Actually, what's funny is that while I do apply the benefits of Haste Potions and Blade Flurry and such to the average-case cycle performance, I do
not apply the penalty of Blade Flurry's cost. This is most definitely a cause of DPS inflation. I think both approaches can be considered valid in some ways, and obviously neither is fully correct, but I would say consistency would be the best practice.
Since many other areas of my spreadsheet use the approach of "model cycles as the average case ignoring one-off cases," it is most appropriate that both Blade Flurry's energy cost and its haste contribution not be considered in terms of cycle modeling. However, at the same time, I don't want the sheet's DPS modeling to ignore these factors entirely. As it stands in version 0.2.1, the energy cost is modeled as reducing your DPS by the DPE of your primary CP builder times 25 energy per 120 seconds. While effects like Blade Flurry don't make the average-case cycle shorter, they do contribute some extra energy by virtue of Combat Potency feedback. I would still like to model this, so I used the same approach to add a calculation of the average haste contribution of one-off haste effects (like Bloodlust and Blade Flurry) times the base EPS of Combat Potency times the DPE of your primary CP builder.
The net result, given my current gear and buff setup (which is the default in the sheet) is a DPS reduction of about 0.73%. More importantly, performing several quick checks using AToL, I find that the modeled value of that trinket did not significantly reduce.
Speaking of AToL, I'm intrigued by the curious behavior you found regarding AToL uptime in 0.2.1. However, coincidentally, I was just working earlier tonight on streamlining some of the cycle calculations (removing 4 rows from each cycle model and redoing the AToL calcs a bit, final result was the removal of some 7200 cells from the sheet) and in my updated sheet I cannot find the behavior you identified. I'll simply blame the previous method of calculating AToL uptime being a bit too convoluted and allowing some edge case to slip by me. Note that after making the changes I described, my calculated AToL uptime and DPS for 4s/5r and 5s/5r did not change at all.
(edit) I've been working on the cycle calcs a bit more and managed to find that issue you identified with AToL uptime. Let's look at a 1s/1s/5r cycle, assuming 60 energy pooled for all finishers, and assuming exactly 12 energy generated per second.
First 1s component:
Entry energy: 60 pooled - 25 spent (on 5r) + 25 refunded (RS) = 60
Builder cost: 40 * 0.4 (Ruthlessness) = 16
Exit energy required: 60
Energy gain needed during component: 60 exit - 60 entry + 16 builder = 16
Cycle component time: 16 / 12 = 1.333 seconds
Second 1s component:
Entry energy: 60 pooled - 25 spent (on 1s) + 5 refunded (RS) = 40
Builder cost: 40 * 0.4 (Ruthlessness) = 16
Exit energy required: 60
Energy gain needed during component: 60 exit - 40 entry + 16 builder = 36
Cycle component time: 36 / 12 = 3.000 seconds
5r component:
Entry energy: 60 pooled - 25 spent (on 1s) + 5 refunded (RS) = 40
Builder cost: 40 * 4.4 (Ruthlessness) = 176
Exit energy required: 60
Energy gain needed during component: 60 exit - 40 entry + 176 builder = 196
Cycle component time: 196 / 12 = 16.333 seconds
Total cycle time: (16 + 36 + 196) / 12 = 20.667 seconds
Total builder energy: 16 + 16 + 176 = 208 energy
Let's look at AToL proc possibilities:
First 1s component procs AToL:
Next component: Second 1s component
Base AToL energy: 10 seconds uptime * 12 energy per second = 120 energy
Total AToL energy: 120 base + 40 entry = 160 energy
Builder cost: 16 (16 covered)
Cycle component time: 3.000 seconds
AToL time left: 7.000 seconds
Next component: 5r component
Base AToL energy: 7 seconds uptime * 12 energy per second = 84 energy
Total AToL energy: 84 base + 40 entry = 124 energy
Builder cost: 176 (124 covered)
Cycle component time: 16.333 seconds
AToL expires
Second 1s component procs AToL:
Next component: 5r component
Base AToL energy: 10 seconds uptime * 12 energy per second = 120 energy
Total AToL energy: 120 base + 40 entry = 160 energy
Builder cost: 176 (160 covered)
Cycle component time: 16.333 seconds
AToL expires
5r component procs AToL:
Next component: First 1s component
Base AToL energy: 10 seconds uptime * 12 energy per second = 120 energy
Total AToL energy: 120 base + 60 entry = 180 energy
Builder cost: 16 (16 covered)
Cycle component time: 1.333 seconds
AToL time left: 8.667 seconds
Next component: Second 1s component
Base AToL energy: 8.667 seconds uptime * 12 energy per second = 104 energy
Total AToL energy: 104 base + 40 entry = 144 energy
Builder cost: 16 (16 covered)
Cycle component time: 3.000 seconds
AToL time left: 5.667 seconds
Next component: 5r component
Base AToL energy: 5.667 seconds uptime * 12 energy per second = 68 energy
Total AToL energy: 68 base + 40 entry = 108 energy
Builder cost: 176 (108 covered)
Cycle component time: 16.333 seconds
AToL expires
So, to summarize:
- The first 1s component gets AToL uptime as follows:
--- If the 5r component procs AToL (100%), all 1.333 seconds and all 16 builder energy are covered.
- The second 1s component gets AToL uptime as follows:
--- If the first 1s component procs AtoL (20%), all 3.000 seconds and all 16 builder energy are covered.
--- If the 5r component procs AToL (100%), all 3.000 seconds and all 16 builder energy are covered.
- The 5r component gets AToL uptime as follows:
--- If the previous 5r component procs AToL (100%), 5.667 seconds and 108 builder energy are covered.
--- If the first 1s component procs AToL (20%), 7.000 seconds and 124 builder energy are covered.
--- If the second 1s component procs AToL (20%), 10.000 seconds and 160 builder energy are covered.
Trivially, the two 1s components will always have AToL up. For the 5r component, if any of the three finishers procced AToL, we get 5.667 seconds and 108 builder energy: 1-(1-100%)*(1-20%)*(1-20%) = 100% chance. If either of the two 1s components procced AToL, we get an additional 1.333 seconds and 16 builder energy: 1-(1-20%)*(1-20%) = 36% chance. If the second 1s component procced AToL, we get an additional 3.000 seconds and 36 builder energy: 20% chance. All in all, we get an average of 6.747 seconds and 120.96 builder energy on this component.
Thus, our average total AToL uptime is 1.333 + 3.000 + 6.747 = 11.08 seconds. Given a total cycle length of 20.667 seconds, our AToL uptime is 53.61%. Our average total AToL builder energy is 16 + 16 + 120.96 = 152.96 energy. Given a total builder energy expenditure over the cycle of 208, our average AToL uptime on builders is 73.54%.
For this same cycle, given 12 energy per second, my sheet is telling me 46% AToL uptime and 40% AToL uptime on builders. However, doing this whole analysis allowed me to realize that the reason this bug is occurring has to do with the fact that AToL procs are only modeled across two cycle components following the time they were procced, instead of three. This only causes problems with cycles short enough where an AToL proc can genuinely carry across three cycle components, such as the one given above, or your example of 1s/3r.
(edit 2) After correcting the formulas to account for the extra carryover, the spreadsheet gives values of 53.61% for AToL uptime and 73.54% for AToL uptime on builders for the example 1s/1s/5r cycle with 60 energy pooled per finisher and 12 energy per second, corresponding exactly with the predictions above. Seems correct and should rectify any problems with short cycles. This fix will be deployed in 0.2.2.