Posted 02 October 2012 - 09:43 PM
The behavior that Lilbitters has seen with Dire Beast and inconsistent use of the full attack profile is very frustrating. I've spent some time trying to codify the situations where the dropped attacks occur. Unfortunately, this is the sort of situation that is also resistant to logging; I can provide dozens of "correct" and dozens of "missed attack" logs, but they are not informative as to the real-world conditions that resulted in the difference.
I believe there are two different situations which can result in a dropped attack, although they may actually be symptoms of the same problem. The most common source of a dropped attack is a delay prior to the first attack. Under "correct" behavior, the DB should make its first attack immediately after the button is pressed, but sometimes that doesn't happen. Minimizing the range to target seems to help, although I have some evidence, below the threshold of statistical significance so far, that extreme close range may slightly increase the chances of the first hit delay. Lilbitters reported that positioning in the rear arc may also be helpful; I have not tested that to any meaningful degree.
The second situation is a delay between attacks. Frequently, this happens between the first attack and the second, but I've got at least one log showing a delay after attack #5. This often (but possibly not always?) has a visual cue: the DB pet will "twitch", either repositioning slightly or spinning to face the hunter before returning to attack. I have also seen situations where real pets will exhibit this behavior. It's most visible while pet tanking, for obvious reasons, and is pretty much impossible to log, unfortunately. The Abomination of Anger in the Crypt of Forgotten Kings scenario seems particularly prone to this, and so may be a good target for further testing.
I suspect that the latter problem is a flaw in the pet pathing AI. The former may be as well; DB appears to summon the pet into a default position that the AI believes to be the "proper place" for combat to begin. If that placement doesn't play nice with the algorithm that determines if the pet is in the correct place to attack, it adjusts, and we see an attack delay. If that's the case, and we can find a test encounter that reproduces the bug consistently, we should be able to report it. I'm off for a couple days for my anniversary, so regrettably, I won't be able to do the heavy lifting on this, at least not for a few days.
I also haven't had the chance to determine whether glyphed Stampede pets inherit changes in pet autocast profiles. If so, there may be a reasonably viable workaround to the bug reported by Repins -- leaving Rabid autocast disabled, and only firing it following Stampede (and, manually, following the subsequent cooldown). In fights that are expected to last < 5 minutes, the correct behavior would be to use it on cooldown a second time (at t = 4 minutes), but in fights that are likely to see a second Stampede, optimal dps would probably require delaying the Rabid for paired cooldowns. In a sufficiently long encounter, the pushback from delayed Rabids would eventually consume the dps gain from paired use with iterative Stampedes, but I don't think there are any extant fights long enough for that to occur (and I think it's only a reasonable concern for BM besides). Regardless, I'm pretty sure that cooldown-state inheritance is a bug, so hopefully we won't have to deal with the problem for long.