Balance Druid + Night Fae "Convoke the Spirits" bugs

I’ve been looking at the accuracy of AMR simulations for my character (Balance Druid, Night Fae), and noticed a pretty major issue with Convoke the Spirits. It looks like on AMR the ability can trigger Eclipse, and that’s definitely not happening ingame.

AMR log: https://www.askmrrobot.com/wow/simulator/report/182b95a5da4348cabf13715a5216b33d
Live log: https://www.warcraftlogs.com/reports/QXgBfH78nCw6v1hq#fight=last (putting 1 sunfire on Goroth to start the fight, then pressing Convoke – you can clearly see I never get Eclipse even though multiple wrath were cast).

Note: I was looking into this because I found it weird that the AMR rotation doesn’t adhere to the common guidance of casting Convoke only during CA or Eclipse. I would expect that fixing this bug will make it worth it to also adapt the rotation to adhere to common guidance.

Looking at the WCL log a bit further, I also don’t see Convoke Starsurges applying Starlord stacks. AMR is stacking up my Starlord proc with Convoke, it seems like.

Seems like it should be as easy as adding a not HasBuff(Convoke) in these two places. I haven’t found any other immediately wrong interactions, but I’ll keep looking.

I have tentative patches for these two issues in https://www.askmrrobot.com/wow/theory/mechanic?spec=DruidBalance&version=e6b2180805eb42bc93fedd13c274ba77 (modified Eclipse (Lunar) and Starlord).

AMR log on my patched version: https://www.askmrrobot.com/wow/simulator/report/e316f024582f41edb064f534daaea98c

Note: with how rigid the Druid rotation is in a Patchwerk style of fight, the Eclipse during Convoke change doesn’t make a huge difference in sims because usually 1. the first Convoke is followed by CA; 2. the second Convoke is already in Eclipse. So only the 3rd Convoke in a standard length ST simulation is impacted. I expect that in a more dynamic fight simulation incl. more random-ish movement this might end up having a larger impact, but I don’t have data to prove this.

A third bug: the currently documented behavior of Convoke is that it only applies Moonfire on targets that don’t already have the DoT (it is in fact recommended to apply Moonfire before casting Convoke to try and push another “free” Starsurge). Right now Convoke on AMR seems to be casting Moonfire multiple times on the same target.

I don’t have a ton of data to prove it, but in the WCL I linked above you can see there’s a single Moonfire applied by Convoke, whereas in the AMR logs you can see multiple Moonfires. Sources that claim Moonfire doesn’t get re-applied include Icy-Veins (“Have Moonfire applied to your target. If a Moonfire is on the target, it will not try to cast Moonfire and use that slot instead on a better Balance ability.”)

Unfortunately since the Convoke logic is “hardcoded” right now I can’t try to fix it and see how it impacts simulated DPS. I expect this would significantly increase the value of forcing Convoke in CA/Eclipse, by virtue of casting more Starsurges on average (-> more empowerments for eclipses).

Yeah, we really had no way to implement it other than just writing code on the back end. I guess we could try to test it a bunch of times to see if it will never cast a moonfire on a target that already has it. There are probably a lot of rules that we’re not aware of hanging around. I can add that to the logic for now until we learn differently.

In theory the code would only cast a moonfire on a target with the DoT already if it is within the 30% refresh window (but we could change it to not cast at all on a target with the DoT). I’ll look at why that logic isn’t working as intended.

I just did some training dummy testing, and I couldn’t get convoke to ever refresh a Moonfire that’s still ticking. N=5, so maybe I was just unlucky, but it seems more likely that Moonfire only gets cast in Convoke if the DoT is absent.

I updated it – shouldn’t re-cast DoTs on targets with the DoTs already.