Leafkiller's 5.04 Feral/Guardian Ovale Script

[Mihir]

This is starting to remind me of FeralbyNight's addon, calculating the damage of every attack before deciding what to recommend :p

[Jeshu]

I don't think we're there yet. I'm just trying to present enough information in Ovale scripts to allow some of the trickier SimC action list statements to be translated over.

Ovale does do lazy evaluation of conditions, so it's possible to optimize the order of conditions so that cheap ones come early and expensive ones come later, e.g.,

Code: Select all

if CheapCondition() and ExpensiveCondition()
    Spell(id)

In this example, if CheapCondition() evaluates to "false" then Ovale doesn't bother evaluating ExpensiveCondition().

[Leafkiller]

Small fix to the first post in this thread (the one with the rotation...). The Ovale script assumes Glyph of Savagery, but it does not assume you have Glyph of Shred. It auto-detects the presence of that Glyph, which, as those who have been paying attention know, should not be used at this time because it (Shred!) currently does 25% less damage than plain old Shred. Stay tuned for further testing and bugging of Blizzard about this.

[ShmooDude]

A nice little addition to the script I did for myself and I figured I'd post it for anyone that wants or Leafkiller can put it in the main script if he wants.

In the Defines area (should there be any SpellInfo for this? I'm not overly familiar with Ovale, just enough to be dangerous, lol):

Code: Select all

   Define(HEALINGTOUCH 5185)
   Define(predatory_swiftness 69369)

In the Fillers function, just above the "Fallback to Shred" line:

Code: Select all

    # Healing Touch if nothing needed rotationally
    if BuffPresent(predatory_swiftness 1) and 1.4s before Energy(more 99) Spell(HEALINGTOUCH)

Basically if nothing is needed rotationally (ie you're just energy pooling) and you have at least 1 second on your Predatory Swiftness buff (1 second so it doesn't show up just as its about to expire and cause you to try to hard cast a healing touch) show Healing Touch. There's no reason not to cast it anymore that it is usable without leaving cat form.

Obviously this'll need to be changed for a DoC version of the script at 90 but that's a whole 'nother kettle of fish.

[Sorcerer]

Finnaly, after 2 weeks break, I get into DS.

I think there is a chance for some minor tweaks.

- FF Script should be more aggressive looking as early release problems are fixed now. Getting FF icon when sunder is about to expire when in 30sec window there is so many occasions to do it while pooling. Happens sunder is about to expire, you must renew FF and you find yourself at energy cap.
- I don't understand so well how script handles 'how many combo points you have + time req to get 5 CP' but the finisher prediction is a bit too keen on Savage Roar when RIP has already fallen and you are sitting at 3/4 CP and still enough time to build 5th CP to get Rip + 0/1 CP roar.

- I found myself really annoyed when abilities go into 'red icon + round clock' while energy pooling/stalling rotation. Too often during stalling the suggested skills would change multi times within 1-2sec window time. Hard to even say when does it exacly happen.

[Leafkiller]

The "opportunistic" FF code I originally put in was not quite optimized. I recently sat there on a dummy waiting for energy pooling and refreshing TF, but sometimes I noticed delays the rotation due to the FF GCD (OOC procs for example and/or when pooling was about to end). I probably need to set the threshold to look for times when we will be pooling for at least another 2 seconds to make sure the rotation will not be impacted too much.

I agree on the issues with Rip and SR interactions, especially with the aggressive FB code. I think the primary culprit is the 3 second refresh on SR with combo points >= 1. I posted about this in the simulationcraft discussion thread here: http://fluiddruid.net/forum/viewtopic.php?p=8352#p8352 trying to see if we could clip SR sooner. I also tried to bound the 3 second SR code as follows:

unless ComboPoints(more 4) and TargetDebuffPresent(RIP) and BuffRemains(SAVAGEROAR) >target.DebuffRemains(RIP) Spell(SAVAGEROAR)

The most recent thing I tried in version 21 of the script (which I have not posted) was to move the 3 second SR refresh after the Rip code (separate from the 1 second SR refresh). I am still not happy with it though.

I plan to circle back with aggixx and see what happens to dps if we simply remove the 3 second check, or perhaps change the way I am bounding it (I could simply ignore it when Rip is close to expiring). We may still need to sometimes do an early 1-2 combo clip on SR right after an aggressive FB to minimize Rip downtime to avoid the case where SR eats up 5 combo points when Rip has just expired, or as is happening now, when Rip is about to expire.

I really want to sim these changes before putting them in the script. My focus at this point is to get the script ready for MoP and not worry about current imperfections for DS raiding.

[Leafkiller]

Per GC: http://us.battle.net/wow/en/forum/topic ... age=40#782

Also confirmed in testing, it is now safe to use Glyph of Shred.

[Jeshu]

It's possible we might need to keep track of the buffs present when the spell was cast for special buffs like DoC that affect "the next two melee attacks".

As opposed to what? Checking immediately after the execution of the spell?

I understand your answer here was probably meant to be cheeky, but I'll respond anyway.

Right now, Ovale allows for checking the buffs/debuffs that are currently present via the various Buff*() conditions. It also "tracks" various bits of information from the current state when a spell is cast. Right now, the state consists of the spell haste modifier, the damage modifier, and the spellpower/AP bonuses. What I meant by "keep track of the buffs" is to add the relevant buffs to the state, so that the presence or absence of these buffs when the spell was last cast can be queried later.

[aggixx]

I understand your answer here was probably meant to be cheeky, but I'll respond anyway.

Right now, Ovale allows for checking the buffs/debuffs that are currently present via the various Buff*() conditions. It also "tracks" various bits of information from the current state when a spell is cast. Right now, the state consists of the spell haste modifier, the damage modifier, and the spellpower/AP bonuses. What I meant by "keep track of the buffs" is to add the relevant buffs to the state, so that the presence or absence of these buffs when the spell was last cast can be queried later.

I wasn't trying to be a smartass =P. I thought that you were trying to say that it's already possible to track buffs active at the time of a use of a spell, but in this case you'd have to check the buffs before, not after, the execution of the spell. Or something like that.

But yes, your explanation makes more sense.

[tacololo]

Hello there,

I am playing this game about a year now. Started out balance druid and later frost dk and BM hunter.
Trying now to become real double spec on my druid.
Awesome site and addon. It seems clear to me that feral is a bit harder than balance with all the shortish cd`s and the energy"management"while the balance druid almost never has any mana problems and allover deals with less complications.
I have started practising and encounter one big problem using the addon namely that shred is always advised even if berserk and tiger's fury are not up and you are not behind the target.
What can I do about that?

greets,
Taco

[Jeshu]

I have committed fixes for two Ovale bugs and made a new alpha release r521. Please update your Ovale addon to that release if possible. It should fix the problem where not having a spell on your actionbar might cause it not to be recognized.

[Leafkiller]

Hello there,

I am playing this game about a year now. Started out balance druid and later frost dk and BM hunter.
Trying now to become real double spec on my druid.
Awesome site and addon. It seems clear to me that feral is a bit harder than balance with all the shortish cd`s and the energy"management"while the balance druid almost never has any mana problems and allover deals with less complications.
I have started practising and encounter one big problem using the addon namely that shred is always advised even if berserk and tiger's fury are not up and you are not behind the target.
What can I do about that?

greets,
Taco

As for positioning, that is up to you. I don't think you will find an addon that tells you ahead of time that you are not behind the target. If you are on a fight like Ultraxion, then select the "Frontal attack" checkbox (if you click on the Ovale frame the check box options will appear until you click on the Ovale frame again). As for recommending Shred while TF and Berserk are not up, that is like an issue of energy. Since TF adds 60 energy, we have determined that it is a dps loss to cast it with more than 35 energy, so the script asks you to cast several Shreds in a row to lower your energy before recommending TF when TF is off of cooldown.

[Jeshu]

As for positioning, that is up to you. I don't think you will find an addon that tells you ahead of time that you are not behind the target.

I might be wrong, but I remember Feral By Night did that. There actually is a CLEU event, SPELL_CAST_FAILED, with a failed type that may be checked against a localized string. In this case, we would check if the failed type is "You must be behind your target.", though I would need the exact message for each language.

I will add this as a feature-request ticket for Ovale.

[Leafkiller]

As for positioning, that is up to you. I don't think you will find an addon that tells you ahead of time that you are not behind the target.

I might be wrong, but I remember Feral By Night did that. There actually is a CLEU event, SPELL_CAST_FAILED, with a failed type that may be checked against a localized string. In this case, we would check if the failed type is "You must be behind your target.", though I would need the exact message for each language.

I will add this as a feature-request ticket for Ovale.

Wouldn't that be after the fact though? And if it does occur after the fact, what do we tell the user to do next? We won't know if they have moved behind until the next Shred attempt.

[Tinderhoof]

Droodfocus does this as well (after the fact as Leaf describes). If a shred fails to land due to being "Not Behind" the target an aura will flash on screen. I don't believe there is a way to pre check your position as the attack itself triggers the check.

[Jeshu]

The way I had envisioned it being used would be to put it in a separate icon, e.g.,

Code: Select all

AddIcon help=behind
{
    if LastSpellMissed(Shred) Texture(some_texture_to_indicate_move_behind)
    Texture(polar_bear)
}

That way it doesn't affect your rotations.

[Leafkiller]

It looks like you can overwrite Rip with a weaker Rip now

[Jeshu]

It looks like you can overwrite Rip with a weaker Rip now

I guess that makes your ticket 135 to get the proper damage multiplier a bit more urgent now?

[Leafkiller]

It looks like you can overwrite Rip with a weaker Rip now

I guess that makes your ticket 135 to get the proper damage multiplier a bit more urgent now?

It has always been urgent in my mind

Edit: but it will be core to the rotation we design, and it will make running the rotation without an addon difficult...

[Jeshu]

I have some changes to Ovale in my local repository that make the following script work:

Code: Select all

Define(dream_of_cenarius_damage 108381)
    SpellInfo(dream_of_cenarius_damage duration=30)
Define(rake 1822)
    SpellInfo(rake combo=1 duration=15 energy=35 tick=3 coeff=0.38 tickDamage=590)
    SpellAddTargetDebuff(rake rake=1)
    SpellDamageBuff(rake dream_of_cenarius_damage=1.25)

AddFunction RakeTickDamage
{
    # rake_tick_damage = (tick_damage + coeff * AP) * damage_multiplier * bleed_multiplier
    {SpellData(rake tickDamage) + SpellData(rake coeff) * AttackPower()} * DamageMultiplier(rake) * {1 + Mastery()/100}
}

AddFunction LastRakeTickDamage
{
    # rake_tick_damage = (tick_damage + coeff * AP) * damage_multiplier * bleed_multiplier
    {SpellData(rake tickDamage) + SpellData(rake coeff) * LastSpellAttackPower(rake)} * LastSpellDamageMultiplier(rake) * {1 + LastSpellMastery(rake)/100}
}


AddFunction RakeTickDamageRatio
{
    if TargetDebuffPresent(rake) RakeTickDamage()/LastRakeTickDamage()
    unless TargetDebuffPresent(rake) 1.0
}

AddIcon mastery=2
{
    RakeTickDamageRatio()
}

As you can see, you can now add stuff into the Rake SpellInfo() statement and then query the data later using SpellData() in the script. I'm using those in the example above to query the level 85 base tick damage and the AP coefficient. There is also a new statement SpellDamageBuff() that let's you track additional damage multipliers given the presence of the named buffs. You can also query for the mastery. Putting all of that information together like I did in the two functions above let's you calculate the true tick damage (without crits). Then you can check the ratio to see if it's worthwhile to clip Rake.

Let me know what you think. It does seem a bit cumbersome right now, but I was trying to keep the system general enough to use for every class. I think it might be possible to fold in the mastery effect into the damage multiplier, but that needs some extra thought given all the different masteries out there.

[Leafkiller]

It looks very powerful and something that will accomplish what we have been discussing. The rotation we build for MoP will be far more precise than any we have done before.

The challenge will be to make it simple enough for someone to execute

[Jeshu]

I'll commit these changes and crank out a new minor release of Ovale so you can play with it in your feral scripts.

[Leafkiller]

From now on, depending on the rotation, I am going to need to know the damage coefficients for all three DoTs...Thrash, Rip and Rake.

[Jeshu]

I'm sure the SimulationCraft folks will be able to provide you with the base tick damage and AP coefficients for all of the spells that you need

One thing about your scripts: I know that TimeToDie() doesn't work at all right now against the target dummies and the level 93 boss dummies are a little hard to hit to do proper testing, but I do like having them in the scripts anyway. What I did in my own scripts is:

Code: Select all

AddCheckBox(targetdummy "Target dummy")

AddFunction TimeUntilTargetIsDead
{
    if CheckBoxOn(targetdummy) 3600
    if CheckBoxOff(targetdummy) target.TimeToDie()
}

Then everywhere that I normally had "target.TimeToDie() < NN", I changed that to "TimeUntilTargetIsDead() < NN". That gave me a toggle for when I hit the dummies for testing purposes and when I'm in a dungeon or a raid.

[Leafkiller]

That is a good solution. It occurred to me when I was moving my script into the addon that I needed to put the time to die back in.