Originally Posted by Kyth
(c) it's stupid to require it even if it's a "hard" problem to solve.
|
It's not a hard problem to solve I think.
Really in some sense the reason why we have this mess is because blizz decided that the right way to handle that a hunter cannot auto-shoot while running is to give auto-shot a cast time. As running aborts cast time, auto-shots get aborted. But auto isn't a cast so on top of this we get interference of actively engaged shots with auto-shot.
This very idea is causing all the symptoms. One way to fix it is to have a separate check if a hunter is running and remove the cast time from auto-shot.
Then it would still be possible to delay auto-shot, but not to clip it. I.e. shot rotations stay still fairly involved and will incidentally still depend on weapon speed, but at least lag won't have a chance to swallow shots for you.
An even more radical idea is to decouple auto-shot. If that was in place shot selection would be a matter of shot cooldowns and mana management, much more in line with how mages and locks work.
I actually like shot rotations. But the old 9-10 second shot rotation was much better. Now we look at 2-3 second shot base skeletons. You can easily see that minor variations in 9-10 seconds have far less of an impact than in 2-3 seconds. On top of it in the old scenario when you clipped an autoshot, that was maybe 1 out of 3-4 and the way aimed used to work, you were guaranteed a chaser after cast is finished. Now we can in principle clip every single one and never see a chaser. In terms of shot fillers you have to work with 1.5+0.5 seconds and manage the relative timings of GCD time frames relative to weapon speed.
So basically you look at tight timing once or twice roughly every 3 second frame. How the timing exactly plays out depends directly on the weapon speed, and haste effects of course, which proc mid-combat and change the optimum on the fly. What exactly to weave in turn depend on shot cooldowns, which are on different length timers and don't make a periodic rotation (that is arcane and multi-shot cooldowns don't necessarily fall to where your optimal shot moment is, and their ordering drifts due to relative cooldown time).
This is a very dynamic problem and it's not even all that easy to theory-craft this with haste procs and such. Problem is that it's not like a set bonus where you change your optimal spell mix once. You are constantly adapting to dynamic proc changes. I certainly don't theorycraft new weapon speeds in great detail because it's too tough, I figure out rough outlines and the rest is practice and experimenting. In the end no matter what, due to procs it always stays a reaction game. Not pre-raid theorycraftable, even more so with latency variations that add to the weapon-speed/haste variation.
If that sounds like anything that resembles what other classes do to optimize DPS I don't know. I certainly don't do anything remotely close to this on my mage. For all other classes it's waiting for cooldowns and if you have multiple options picking the optimal one. But timing plays no tight role in this, i.e. no timing below GCD.
So to say that shadow bolt and dot timings chance don't really reflect all that hunters do here. We do the dynamic changing of cooldowns, but keeping track of timings (autoshot) that do not fall into the GCD rhythm at the same time. This last part is really crucial as a difference.
Best description I can come up with, imagine that an external metronome is ticking, your optimal performance as a lock or mage is not defined by the GCD and spell cooldowns, but by their relative placement to that external metronome. That metronome does not have constant speed, it can speed up due to talents and trinkets, and speeding up is in general good so you can't remove the variability. If you get a new haste item ("bow") the metronome changes it's core speed and the relative timing to other cooldown changes and the optimum changes, but again the metronome is variable speed. Now depending on the network connectivity of the day the metronome additionally varies, again changing the local optimal decision or if you can sensibly perform it.