Leafkiller's MoP Feral/Guardian Ovale Script

[Leafkiller]

@Leafkiller: Could you open a ticket for the feral ability that grants the extra combo point? I tried finding the post about how it worked, but didn't see it during my search.

I started to work on a ticket, but it became clear to me that I don't understand how Ovale is calculating combo points on a target right now. It looks like it is calling GetComboPoints() every time a "Damage" event happens (by setting a refreshNeeded flag on the player). I have not found where it uses the "combo=" parameter on SpellInfo. I am assuming that it will use that when it determines that a spell has been cast, but there does seem to be some lag.

Druids have a passive ability called Primal Fury (http://www.wowhead.com/spell=16961) which returns 15 rage on Mangle and auto-attacks while in Bear form and two combo points while in cat form from single target combo point abilities (Mangle, Rake, Shred, Ravage, Shred! and Ravage!).

So I have some questions for you. First, does the predicitive code use the "combo=" parameter to update the combo points for script evaluation? If it does do that, when is it done? Is it relying on the API call, GetComboPoints() to update the combo points after every event that it cares about?

The "SPELL_DAMAGE" event is sufficient to determine when a combo point has been added. It is also sufficient to determine when two need to be added. Here is some lua code that aggixx wrote into a Weak Aura to see how many combo points to add:

Spoiler: show

Code: Select all

function (event, ...)
    local isCombo, isFinisher
    WA_feralCP_spells = WA_feralCP_spells or {
        [1822] = true, -- Rake
        [5221] = true, -- Shred
        [6785] = true, -- Ravage
        [33876] = true, -- Mangle
        [102545] = true, -- Ravage!
        [114236] = true, -- Shred!
    }
    
    WA_feralCP_count = WA_feralCP_count or 0
    WA_feralCP_GCD = WA_feralCP_GCD or 0
    
    if event == "COMBAT_LOG_EVENT_UNFILTERED" then
        local _, cleuevent, _, sourceGUID, _, _, _, destGUID, _, _, _, spell, _, _, _, _, _, _, _, _, critical = ...
        if sourceGUID == UnitGUID("player") then
            if cleuevent == "SPELL_DAMAGE" then
                if destGUID == UnitGUID("target") then
                    if WA_feralCP_spells[spell] and critical then
                        WA_feralCP_count = min(WA_feralCP_count + 1, 5)
                    end
                end
            end
        end
    elseif event == "UNIT_COMBO_POINTS" then
        local unit = ...
        if unit == "player" then
            WA_feralCP_count = GetComboPoints("player", "target")
        end
    elseif event == "PLAYER_TARGET_CHANGED" then
        WA_feralCP_count = GetComboPoints("player", "target")
    end
end

Here are two Mangles from a combat log, the first is a normal hit, and the second is a crit:

11/27 23:58:26.888 SPELL_DAMAGE,0x0200000005C273A4,"Leafkiller",0x511,0x0,0xF53079AA0000417F,"Raider's Training Dummy",0x10a28,0x0,33876,"Mangle",0x1,19320,-1,1,0,0,0,nil,nil,nil

11/27 23:58:28.856 SPELL_DAMAGE,0x0200000005C273A4,"Leafkiller",0x511,0x0,0xF53079AA0000417F,"Raider's Training Dummy",0x10a28,0x0,33876,"Mangle",0x1,38979,-1,1,0,0,0,1,nil,nil

Note that the third to last parameter is the crit indicator.

Since Ovale is spell agnostic, my idea is to add a new parameter to SpellInfo to tell it to add two combo points for crits on certain spells. For example:

Code: Select all

Define(MANGLECAT 33876) #cat bleed+debuff
    SpellInfo(MANGLECAT inccounter=ripshreds energy=35 combo=1 critcombo=2)

In an ideal world, Ovale would update the combo points when it gets the SPELL_DAMAGE event and not wait for a call to GetComboPoints. This would make the move suggester much more responsive and reduce flickering. I see a lot of that right now, both when I add combo points that crit, and also when I use a finisher, where a new finisher is briefly displayed before Ovale realizes that combo points is now equal to zero. It seems like it knows I have cast something before it knows how many combo points are now on the target.

I am happy to post a ticket requesting an enhancement, but I want to make sure I understand what Ovale is currently doing, so I know what to post. Can you provide some insight into the current workings?

[Leafkiller]

@Jeshu - I don't know if you are following any other threads on this forum, but could you take a look at this post and comment on it (you might want to check the posts above it): http://fluiddruid.net/forum/viewtopic.p ... 331#p11331

[Jeshu]

@Leafkiller: If you could just copy and paste what you wrote above into a ticket, that is sufficient information for me to implement.

I'll try to give an explanation of how Ovale works. What happens in WoW is laid out on a continuous timeline, but the game client gives you a bunch of snapshots of that timeline based on your framerate, i.e., 30 fps means you get 30 snapshots of that timeline per second. At each frame refresh, Ovale snapshots the game state, which includes things like how many combo points you have, what spell you are casting, what buffs you have, what buffs your target has, etc. It runs the script to see what is the best action to suggest given the game state.

All of the information that we tell Ovale about the spells that are being cast help Ovale interpolate what happens before the next frame refresh. Suppose you use Ferocious Bite, which consumes all your combo points. Your game client send a message to the WoW server saying that you used FB and then the WoW server sends a message back to your game client saying "okay, I confirm you just cast FB". While those message are flying back and forth, you'd still really like to know what's the next action you should queue up to cast, because from your perspective you just used all your combo points in FB, even though WoW hasn't fully caught up yet. Ovale uses the information from the SpellInfo() statements to advance the game state that it snapshotted so it can tell you the next spell to cast given the advanced game state. When the game client finally catches up, Ovale will take a fresh snapshot of the game state and the cycle will continue.

I hope that helps.

[Leafkiller]

Ticket posted: http://wow.curseforge.com/addons/ovale/ ... bo-points/

[pltr]

Not sure if if anyone posted it already, but the search didn't find anything.
The spell id for clearcasting was changed (in 5.1 i think) It's now 135700 instead of 16870
http://www.wowhead.com/spell=135700

[Leafkiller]

Not sure if if anyone posted it already, but the search didn't find anything.
The spell id for clearcasting was changed (in 5.1 i think) It's now 135700 instead of 16870
http://www.wowhead.com/spell=135700

Thanks for the heads-up.

[Leafkiller]

Not sure if if anyone posted it already, but the search didn't find anything.
The spell id for clearcasting was changed (in 5.1 i think) It's now 135700 instead of 16870
http://www.wowhead.com/spell=135700

I pushed a new version of my script that fixes this, so update Nerien's.

[aggixx]

Not sure if if anyone posted it already, but the search didn't find anything.
The spell id for clearcasting was changed (in 5.1 i think) It's now 135700 instead of 16870
http://www.wowhead.com/spell=135700

Beat me to it. Presumably they had to add a second spell ID so they could have a different display pop up for feral.

[Jeshu]

Ticket posted: http://wow.curseforge.com/addons/ovale/ ... bo-points/

This has been implemented in Ovale 5.1.2. The semantics for "critcombo=N" means that N extra combo points are added on a critical strike of that spell. You should also use "if_spell=primal_fury" to make sure that only comes into effect if the druid has learned primal_fury, e.g.:

Code: Select all

  Define(mangle 33876)
    Spellinfo(mangle combo=1 energy=35 inccounter=ripshreds)
    SpellInfo(mangle critcombo=1 if_spell=primal_fury)
  Define(primal_fury 16961)

[Jeshu]

@Jeshu - I opened an Ovale ticket: http://wow.curseforge.com/addons/ovale/ ... r-pooling/

I have some questions on your ticket that I've posted over on the Ovale site. I figure that's better than cluttering up this thread with Ovale design questions

[Leafkiller]

@Jeshu - I opened an Ovale ticket: http://wow.curseforge.com/addons/ovale/ ... r-pooling/

I have some questions on your ticket that I've posted over on the Ovale site. I figure that's better than cluttering up this thread with Ovale design questions

Replied.

[Leafkiller]

@Jeshu - consider this a continuation of the last reply I did on the Ovale ticket.

The construct:
PreConditions()
if (condition) PoolResource()
PostConditions()

As you indicated in your post, you will look at the highest priority Spell in PostConditions() for what to display. The difference is that we do not use a specific resource level, but rather an if clause, and the timer should be based on how long we expect the if clause to be true.

This construct is very interesting and will allow the simplification of the filler code in the current script. Here is an interesting example of what is possible (I am using simc syntax). Consider these six lines from the current simc script:

actions+=/ravage,if=(buff.tigers_fury.up|buff.berserk.up|buff.natures_vigil.up)
actions+=/ravage,if=cooldown.tigers_fury.remains<=3.0
actions+=/ravage,if=energy.time_to_max<=1.0
actions+=/shred,if=(buff.tigers_fury.up|buff.berserk.up|buff.natures_vigil.up)
actions+=/shred,if=cooldown.tigers_fury.remains<=3.0
actions+=/shred,if=energy.time_to_max<=1.0

We can express these as follows:

actions+=/pool_resource,wait=0.1,if=!(buff.tigers_fury.up|buff.berserk.up|buff.natures_vigil.up|cooldown.tigers_fury.remains<=3.0|energy.time_to_max<=1.0)
actions+=/ravage
actions+=/shred

This makes it much clearer in the script that what we are actually doing is pooling energy, and it also will make it easier to add additional conditionals to the filler actions, for example making Ravage only cast if buff.incarnation.up.

***Edit: Obviously we can make the changes I outlined above in the current simc script without the change to Ovale, but it does highlight what the desired behavior is. I do think this change is useful for us to make in the simc script since it will make it clearer and shorter, and that is a discussion I will have with aggixx.

******Second Edit, just for aggixx. For Incarnation we actually want the following (protects against Shred being cast during Incarnation due to having a lower energy cost):

actions+=/pool_resource,wait=0.1,if=!(buff.tigers_fury.up|buff.berserk.up|buff.natures_vigil.up|cooldown.tigers_fury.remains<=3.0|energy.time_to_max<=1.0)
actions+=/ravage
actions+=/shred,if=!buff.incarnation.up

[Jeshu]

How exactly does SimC work? Is there a clock in the background that ticks every millisecond (or some other sub-second interval) that drives the simulation forward? If so, what is that interval?

It would matter for statements like:

Code: Select all

$(energy_for_fb)=(energy>50|(energy>25&buff.berserk.up))

/pool_resource,wait=0.1,if=!$(energy_for_fb)&combo_points>=5&dot.rip.ticking&target.health.pct<=25
/ferocious_bite,if=combo_points>=5&dot.rip.ticking&target.health.pct<=25

In the code above, that "wait=0.1" will cause the execution of the action list to pause up to an extra 0.1s after energy has pooled sufficiently to cast FB.

Structuring those actions as below should cause the FB to happen without the artificial delay:

Code: Select all

$(energy_for_fb)=(energy>50|(energy>25&buff.berserk.up))

/pool_resource,for_next=1
/ferocious_bite,if=$(energy_for_fb)&combo_points>=5&dot.rip.ticking&target.health.pct<=25

I'm leery of adding artificial delays into the action list when the feral rotation is already so sensitive to different timers.

Is my understanding correct?

[Leafkiller]

@Jeshu - I don't have a complete understanding of how pool_resource is implemented, however, I devised some tests to see how the energy pooling constructs work (1000 iterations, 7.5 minutes +-20%).

Case 1, using wait:

Code: Select all

actions=auto_attack
actions+=/mangle_cat,if=energy>=70
actions+=/pool_resource,wait=0.1,if=energy<70
actions+=/shred
actions+=/rake

Results: 19857 cat_melee, 16479 mangle_cat

Case 2, using for_next:

Code: Select all

actions=auto_attack
actions+=/mangle_cat,if=energy>=70
actions+=/pool_resource,for_next=1
actions+=/shred,if=energy>=70
actions+=/rake

Results: 19834 cat_melee, 14624 mangle_cat, 8898 rake

Notice that in both cases, the script is continuing to execute from the top when it is pooling energy, so this is not a hard stop on the script. In the case of the "for_next" it is also executing the "rake" action that follows it. I am not sure why it is implemented this way, but it is not the behavior I am looking for. Here is another test:
Case 3, use pooling on Shred:

Code: Select all

actions=auto_attack
actions+=/pool_resource,wait=0.1,if=energy<70
actions+=/shred
actions+=/rake

Results: 19870 cat_melee, 17590 shred

Case 4, no pooling:

Code: Select all

actions=auto_attack
actions+=/shred
actions+=/rake

Results: 19849 cat_melee, 27084 rake, 3538 shred

Note that Shred is 40 energy and Rake is 35 energy, which is why Case 4 casts many more Rakes than Shreds.

The behavior I am looking for is Case 1 and Case 3. I want to script to re-execute from the top every time, but if it hits a pooling action that is the highest priority "Spell", then I want the next highest spell displayed with a timer/countdown of some sort. It may not be possible to show a countdown based on how long a conditional will stay true, but the countdown can be based on the needed resource. I don't want a hard stop on execution, which is what the "wait" seems to indicate in simc, but that is why the wait is set to such a small number there. Here is what I am (now) envisioning as the syntax:

Code: Select all

PreConditions()
if {some conditions} PoolResource(N)
PostConditions()

Where "N" is the desired energy. Then the behavior could be, if {some conditions} are true, and resource<N, return the highest priority Spell from PostConditions using a countdown based on how long before resource>=N

Hopefully we are getting closer to an implementable solution.

[Jeshu]

Case 1, using wait:

Code: Select all

actions=auto_attack
actions+=/mangle_cat,if=energy>=70
actions+=/pool_resource,wait=0.1,if=energy<70
actions+=/shred
actions+=/rake

Results: 19857 cat_melee, 16479 mangle_cat

Case 2, using for_next:

Code: Select all

actions=auto_attack
actions+=/mangle_cat,if=energy>=70
actions+=/pool_resource,for_next=1
actions+=/shred,if=energy>=70
actions+=/rake

Results: 19834 cat_melee, 14624 mangle_cat, 8898 rake

Notice that in both cases, the script is continuing to execute from the top when it is pooling energy, so this is not a hard stop on the script. In the case of the "for_next" it is also executing the "rake" action that follows it. I am not sure why it is implemented this way, but it is not the behavior I am looking for.

Based on the documentation for pool_resource, I think the 2nd case should be written as:

Code: Select all

actions=auto_attack
actions+=/mangle_cat,if=energy>=70
actions+=/pool_resource,for_next=1
actions+=/shred,if=energy>=70
actions+=/pool_resource,for_next=1
actions+=/rake,if=energy>=70

Otherwise, as in your Case 2 above, if the druid has less than 70 energy, the action list will fall through to the "rake" action.

What we want to test is something like the following two cases:
Pooling for Mangle using "wait=0.1":

Code: Select all

actions=auto_attack
actions+=/pool_resource,wait=0.1,if=energy<70
actions+=/mangle_cat

Pooling for Mangle using "for_next=1":

Code: Select all

actions=auto_attack
actions+=/pool_resource,for_next=1
actions+=/mangle_cat,if=energy>=70

We want to see the number of hits of cat_melee and mangle_cat instead of their damage, and see if one script produces more hits than the other.

I want to script to re-execute from the top every time, but if it hits a pooling action that is the highest priority "Spell", then I want the next highest spell displayed with a timer/countdown of some sort. It may not be possible to show a countdown based on how long a conditional will stay true, but the countdown can be based on the needed resource. I don't want a hard stop on execution, which is what the "wait" seems to indicate in simc, but that is why the wait is set to such a small number there. Here is what I am (now) envisioning as the syntax:

Code: Select all

PreConditions()
if {some conditions} PoolResource(N)
PostConditions()

Where "N" is the desired energy. Then the behavior could be, if {some conditions} are true, and resource<N, return the highest priority Spell from PostConditions using a countdown based on how long before resource>=N.

An Ovale script is run every time there is a frame refresh. It takes each statement ("node" in Ovale's terminology) and attaches a time interval of when that node is ready and when it ends. In your example script above, Preconditions() is a node that's composed of smaller nodes that make up the function. So Ovale figures out all of the time intervals for all of the nodes, then it goes from top to bottom and finds the first node that is ready right now and displays its icon. If nothing is ready right now, then it finds the node that will become available soonest and displays its icon while we wait for that node to become ready.

I'm trying to think of a way to insert the concept of pooling energy into this time-interval approach that still causes the next action/node to be displayed.

[Leafkiller]

@Jeshu - Coming back to the actual example I used last night:

Code: Select all

actions+=/pool_resource,wait=0.1,if=!(buff.tigers_fury.up|buff.berserk.up|buff.natures_vigil.up|cooldown.tigers_fury.remains<=3.0|energy.time_to_max<=1.0)
actions+=/ravage
actions+=/shred,if=!buff.incarnation.up

Trying to put that into Ovale terms. Assume that N = 100-energyRegenPerSec*. Maybe something like the following:

Code: Select all

if not {BuffPresent(berserk) or BuffPresent(tigers_fury) or BuffPresent(natures_vigil_buff) or TimeToMaxEnergy() <=1.0}
        PoolResource(N)
Spell(ravage usable=1)
if not BuffPresent(incarnation_buff) Spell(shred)

Note that I included TimeToMaxEnergy() <=1.0 in the conditionals, and then put in the number I want to pool to in the PoolResource(). I think that will make it easier to implement even though the data is somewhat redundant, but that really a question for you as to what will work best. As a side note, ravage may need to be ravagebang. That may be a bug in my feral script (it also is not handling the 4 piece pvp set bonus properly )

* Is there an easy way to calculate 100-energyRegenPerSec short of throwing out a number between 85 and 90? (as a side note, I actually use 1.4 seconds in the Ovale script and probably should move that into the simc script...)

[Leafkiller]

What you wrote for the example of case 2 is not what I want. I was simply including the Rake to see if the the behavior of the two simc pool_resource structures was the same, and it is not.

You should not look at the actual numbers I listed, because I had variable length fights. It is clearly recycling to the top of the script each time.

I do understand (at a high level) how Ovale is working. What I am proposing is this: if the first node that is ready right now is PoolEnergy, you calculate how long until "N" is ready and then display the next node in the list with the cooldown from N. Where that node comes from does not matter, since it will be the next node suggested - so technically it could be in either PreConditions() or PostConditions().

I guess there is a challenge for the PostCondition() nodes since you won't get to them until energy hits N. I think this will be ok as long as we leave the energy constraint off of the Spell(s) we are trying to pool for, which is how it is handled in the FB code we have in simc:

Code: Select all

actions+=/pool_resource,wait=0.1,if=combo_points>=5&dot.rip.ticking&target.health.pct<=25&((energy<50&buff.berserk.down)|(energy<25&buff.berserk.remains>1))&talent.dream_of_cenarius.enabled
actions+=/ferocious_bite,if=combo_points>=5&dot.rip.ticking&target.health.pct<=25

Note that the ferocious_bite action would be the second node in your list using the construct I proposed.

[Leafkiller]

Next question is how do we make "N" be a return from a function so we can vary it like in the FB example (25 or 50 depending on Berserk).

[Jeshu]

What you wrote for the example of case 2 is not what I want. I was simply including the Rake to see if the the behavior of the two simc pool_resource structures was the same, and it is not.

What I was pointing out is that your use of "for_next" didn't match the documentation if you were hoping that the two scripts would behave the same way.

You should not look at the actual numbers I listed, because I had variable length fights. It is clearly recycling to the top of the script each time.

I know that pool_resource causes SimC to cycle back to the start of the action list. The purpose of the test cases I gave was to find out if the 0.1s wait has a measurable impact in the actual DPS that the simulation computes.

I do understand (at a high level) how Ovale is working. What I am proposing is this: if the first node that is ready right now is PoolEnergy, you calculate how long until "N" is ready and then display the next node in the list with the cooldown from N. Where that node comes from does not matter, since it will be the next node suggested - so technically it could be in either PreConditions() or PostConditions().

This is what I'm trying to avoid because it changes something that's pretty core and stable in the way Ovale works.

[Leafkiller]

@Jeshu - here are the two tests you suggested:
I changed to fixed length fights that are only 100 seconds long.

Pooling for Mangle using "wait=0.1":

Code: Select all

actions=auto_attack
actions+=/pool_resource,wait=0.1,if=energy<70
actions+=/mangle_cat

126 cat_melee, 39 mangle_cat

Pooling for Mangle using "for_next=1":

Code: Select all

actions=auto_attack
actions+=/pool_resource,for_next=1
actions+=/mangle_cat,if=energy>=70

126 cat_melee, 39 mangle_cat

No difference.

On this point:

Based on the documentation for pool_resource, I think the 2nd case should be written as:

Code: Select all

actions=auto_attack
actions+=/mangle_cat,if=energy>=70
actions+=/pool_resource,for_next=1
actions+=/shred,if=energy>=70
actions+=/pool_resource,for_next=1
actions+=/rake,if=energy>=70

Otherwise, as in your Case 2 above, if the druid has less than 70 energy, the action list will fall through to the "rake" action.

I didn't want to limit the Rake to 70 energy and I did not need to, when I used the other form of pool_resource. I was specifically testing to see if the pool_resource would fall through or not to judge how it impacted the script.

=============================

Hopefully this is not too confusing since we are jumping back and forth between posts. I think the last solution I suggested will prevent you from having to change the core engine since it does not require you to re-evaluate the PostConditions() based on the PoolResource(N) as the cooldown can be based solely on how long until N. It basically separates the pooling logic from nodes, and allows what node is displayed to change during the cooldown (if a node ahead of it becomes ready, obviously it will replace the cooldown).

[Jeshu]

@Jeshu - here are the two tests you suggested:
I changed to fixed length fights that are only 100 seconds long.

Pooling for Mangle using "wait=0.1":

Code: Select all

actions=auto_attack
actions+=/pool_resource,wait=0.1,if=energy<70
actions+=/mangle_cat

126 cat_melee, 39 mangle_cat

Pooling for Mangle using "for_next=1":

Code: Select all

actions=auto_attack
actions+=/pool_resource,for_next=1
actions+=/mangle_cat,if=energy>=70

126 cat_melee, 39 mangle_cat

No difference.

Hrmm, how do you get so many attacks in a 100-second window? Maybe I'm misunderstanding something.

[Leafkiller]

I used the BiS T14H profile. Haste does shorten swing speed for white attacks. Also, more white attacks = more clearcasting procs for more yellow attacks since we are energy limited and not gcd limited.

[Leafkiller]

I just pushed a new version of the script - in Nerien's 2.1.3. It has support for faster combo point recognition and also a change that (hopefully) will make the Ravage code work for the pvp 4 piece set. If anyone is using that, please let me know if the script is calling out Ravage every 30 seconds per the set bonus.

[Jeshu]

I know how I want to implement it now. Something like the following:

Code: Select all

pool while PoolingConditions() {
    OtherActions()
}

If PoolingConditions() is true, then pool energy for OtherActions(). If PoolingConditions() is false, then fall through directly to OtherActions().

I'm going to wait a few days before implementing this so I can think this through a bit more, but this would fit with how Ovale currently works. I don't really like the syntax I've come up with because it doesn't read nicely, so I'm open to suggestions.

[aggixx]

I just pushed a new version of the script - in Nerien's 2.1.3. It has support for faster combo point recognition and also a change that (hopefully) will make the Ravage code work for the pvp 4 piece set. If anyone is using that, please let me know if the script is calling out Ravage every 30 seconds per the set bonus.

It's always worked for me with older versions when I've PvPed. Maybe I'm delusional.