Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bm hunter - simmed autoshot ratio #59

Open
GeorgieTragnar opened this issue May 17, 2021 · 5 comments
Open

bm hunter - simmed autoshot ratio #59

GeorgieTragnar opened this issue May 17, 2021 · 5 comments

Comments

@GeorgieTragnar
Copy link

GeorgieTragnar commented May 17, 2021

there has to be quite major error in shot priority usage since the autoshot clipping must be pretty enormous for it just doesnt line up at all if the sim used 2 haste pots and rapid fire

Edit: when i've setup my own sim (that lines up pretty well to spreadsheets from hunter discord) for the same scenario as you (1 bloodlust, 2drums (do you have drums as perma buff?), 2haste pots, 1rapid fire with sunfury speed (2.9) then i get total these results:

118 autoshots
83 steady
12multi
13arcane

whereas your sim gets me these numbers

92.97 autoshots
90.6 steady
14.96 multi

Edit2: i use "advanced" priority shot usage that takes into account time comparisons for autoshot clipping

@secretbis
Copy link
Owner

Unless they've changed significantly since I last checked, I believe the Hunter discord sheets vastly overestimate BM potential. They were showing ~2.4k DPS in phase 1, which just isn't achievable unless the fight fits entirely within Bloodlust, and then that's still 2-3 SDs above the mean.

Drums are currently still a flat buff, as that was pre-Tinnitus announcement - created #60 to track that update. If anything, that would reduce the Auto Shot count, though.

This is the current BM rotation: https://github.com/marisa-ashkandi/tbcsim/blob/main/ui/src/presets/samples/hunter_bm_preraid.yml#L123

It currently allows up to 0.3s of auto-shot clip - in testing with this sim, a modest clip allowance produced the best results. You can edit that in the UI or via the CLI to test out some variations yourself!

I would be curious what you can find - you are likely more experienced with the finer points of Hunter tuning than I am.

Some questions I have:

  1. Does your sim account for the 0.5s cast time of Auto Shot after the last completed Steady/Multi cast?
  2. I notice Arcane Shot - is current theory to weave that opportunistically when Multi is on CD?

@GeorgieTragnar
Copy link
Author

GeorgieTragnar commented May 18, 2021

1 - yes, however the 0.5s cast time is hasted by all ranged haste that the sim currently has
2 - arcane shot can have higher dmg per use than steady on high armor bosses, but that is not why i use it, because it used instead of steady if the steady would have waited for the next autocast to finish

flat 0.3s clip is imo pretty bad, because haste cd stacking shows the best results, because "spreading" haste cds doesnt net as much benefit as was thought previously and when you have stacked all haste cds you can get at 0.9s autoshot and you definitely want different max clip parameter than 0.3

personally i use priority system based on current hasted speed when the gcd finishes and both multi and arcane are prioritized as clip prevention - with having both arcane and multi the sim automatically sinks into using french rotations (5:5:1:1) at higher than 1.8 hasted speeds

if timeLeftAutoshot < steadyCast * 0.3 and arcaneCd <= 0 then castArcane
elseif timeLeftAutoshot < steadyCast * 0.6 and multiCd <= 0 then castMulti
elseif timeLeftAutoshot < steadyCast * 0.9 then castSteady end

Edit:
try to add total time that was spent clipping autoshot as a result - this way i found out my previous priority bad - however the constants i have (0.3, 0.6, 0.9) work best for 2.9 bow speed - i did not look into it more if 2.7 speeds prefer different values for the logic to "slot" into the good rotations

@secretbis
Copy link
Owner

1 - yes, however the 0.5s cast time is hasted by all ranged haste that the sim currently has

Physical haste is accounted for in AS cast here as well.

flat 0.3s clip is imo pretty bad, because haste cd stacking shows the best results, because "spreading" haste cds doesnt net as much benefit as was thought previously and when you have stacked all haste cds you can get at 0.9s autoshot and you definitely want different max clip parameter than 0.3

I don't think that has much of an impact. It's up to 0.3s, and even fully hasted at 0.9 speed that's 1/3 of an AS. One SS is still more damage than that.

try to add total time that was spent clipping autoshot as a result - this way i found out my previous priority bad - however the constants i have (0.3, 0.6, 0.9) work best for 2.9 bow speed - i did not look into it more if 2.7 speeds prefer different values for the logic to "slot" into the good rotations

I think it's important to approach the problem from the opposite direction - instead of fitting the simulation to an "expected good" rotation, just let the machine work and test the underlying assumptions. Whether auto shots should be clipped or not is certainly worth testing.

This is why the rotation is configured for maximum SS/Multi greed, and not any particular sequence of shots. X:Y rotations aren't inherently "correct", they're just ways for humans to remember what to do. Machines have no such need, and we can discover new things by eliminating that rigid structure.

Like I mentioned, I was able to achieve higher DPS by intentionally allowing auto shot clips. This makes sense, since losing 10-30% of an AS while gaining a full Steady is a net gain. Dead time can easily be worse than clip time, depending on their relative sizes.

@GeorgieTragnar
Copy link
Author

GeorgieTragnar commented May 19, 2021

I understand your reasoning, all i'm saying that you've gotta have a problem with something - maybe it is not clipping (as i say if your collective clipping time is below 3s then it is completely fine) or you are just not stacking all haste cds together. That 20% lower autoshot count gotta come from somewhere

I definitely support human error, but it shouldnt be baked into the base scenario, but as an input variable

@GeorgieTragnar
Copy link
Author

When I've given it more thought I think that it slips into doing 2:1 rotation without quick shots

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants