Jeshu wrote:@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:

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?

@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): viewtopic.php?f=3&t=911&p=11331#p11331

@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.

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 16870http://www.wowhead.com/spell=135700

pltr wrote: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 16870http://www.wowhead.com/spell=135700

pltr wrote: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 16870http://www.wowhead.com/spell=135700

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

pltr wrote: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 16870http://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.

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.:

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:

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):

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:

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:

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

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:

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.

Leafkiller wrote: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:

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.

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...)

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:

Leafkiller wrote: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.

Leafkiller wrote: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.

Leafkiller wrote: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.

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).

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.

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.

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.

Leafkiller wrote: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.