SR is up but on short duration (but not justifying next), we have 5CP or almost, No rip on target and it suggests NS Roar instead of RIP? That is with quite some time left on roar, the logic should be tigher.

Also when Roar is on short duration between 3-5sec it will often skip suggesting HT when its available from PS.

Sorcerer wrote:Is NS HT at 5 CP intented following 5 CP roar and no suggested rake/rip in next 2 attacks?

There are a few other things to think about in those situations. How much time is left on Rake? Was it buffed with DoC on it's last application. Hitting NS just before SR will give our next 2 hits bonus, but it will also make sure we are actually using the buff. The SR we just hit will give us a full PS proc to try and get the next Rip we are going to do with DoC. No point in holding NS for to long or we are just leaving damage on the table.

Now I have seen the same things you have and I will make a judgement call about if I want to refresh Rake, or if I want to Rip and do a quick 0 combo point SR. Give it a little more time for script tinkering. I mean really its only the second week of raiding for this expantion, and I know everyone is pretty busy (lord knows I am).

Ye I fully support that, I am basicly playing around it myself couse this kind of things are pretty obvious if you play long enough. Anyway I should have some streams/fraps from heroic bosses coming with new script to pin point more bugs/fixed.

I've noticed (usually at the start of a fight) that sometimes when there is no Rip up at all yet, that it will ask for a SR even though there is ~2 secs left on the roar (enough to get the rip off before it runs out). I think this is always after the NS-HT has just been cast.

Fae wrote:Latest update is alot more smoother besides ovale eating up memory/lua errors. One of em is http://pastebin.com/ZY1BBCNM, unsure if its from script or ovale itself.

The "script ran too long" problem is affecting a lot of addons. I'll see if we can do something in Ovale with continuations to defer some of the work for compiling the code, but the run-time stuff is tough to make smaller and still be real-time. It's possible that Blizzard may fix this for us.

RareBeast wrote:I've noticed (usually at the start of a fight) that sometimes when there is no Rip up at all yet, that it will ask for a SR even though there is ~2 secs left on the roar (enough to get the rip off before it runs out). I think this is always after the NS-HT has just been cast.

I think part of the issue is that the rotation has been designed with T14H gear which generates combo points fast enough to avoid the issue. I will have to do some simming with current gearing levels and see what can be done. Lowering the SR window is not necessarily a solution (we have tried that).

RareBeast wrote:I've noticed (usually at the start of a fight) that sometimes when there is no Rip up at all yet, that it will ask for a SR even though there is ~2 secs left on the roar (enough to get the rip off before it runs out). I think this is always after the NS-HT has just been cast.

When we tried it in SimulationCraft, using Rip instead of Savage Roar in such a situation was more often than not a loss.

Jeshu wrote:The "script ran too long" problem is affecting a lot of addons. I'll see if we can do something in Ovale with continuations to defer some of the work for compiling the code, but the run-time stuff is tough to make smaller and still be real-time. It's possible that Blizzard may fix this for us.

Based on the blue post in this thread, I'm going to disable compiling a new script while in combat to weed out one way in which this error can occur.

Are people seeing this error while not in combat?

Update: This won't work because scripts need to be compiled during run-time in some cases, e.g., weapon swaps, checkbox toggled, etc. The problem does happen due to compilation occurring while in combat as noted in the blue post. I'll see if there is a way we can be more efficient at parsing the script.

RareBeast wrote:I've noticed (usually at the start of a fight) that sometimes when there is no Rip up at all yet, that it will ask for a SR even though there is ~2 secs left on the roar (enough to get the rip off before it runs out). I think this is always after the NS-HT has just been cast.

When we tried it in SimulationCraft, using Rip instead of Savage Roar in such a situation was more often than not a loss.

The problem is the wasted NS-HT when we do that (or any other DoC proc). I think I will test adding a conditional to the two SR lines to hold off on SR if DoC is up. This will tell us if the 3 second window is an issue that is hurting DPS.

My experiance using the DoC script on dummy (since i've used HotW during raids) is following;

Nature's Swiftness is often left available most times used during berserk or on the pull and not any other time.Savage Roar is often used when a rip could've been applied with DoC and TF up and SR right after rip thanks to Glyph of Savagery.This is probably a gear question but my Predatory Swiftness strikes didn't last long enought for the 4th CP most of the time, and was most used on the 3rd instead, Dose this change in raids?Tiger's Fury is not used before we pop berserk but berserk is delayed if Tiger's Fury is on CD.Healing Touch is not used prepull (Don't know if this can be included)Faerie Fire usage is awkward is it possible to include FF usage when we for example pool energy?

This is a definite dps increase - about 180dps on the T14H profile. Simming at 50k iterations (using my sim script):Before the change: 121078 26dps errorAfter the change: 121258 26dps errorOnce I fix this in the Ovale script, it should significantly improve the situation where SR is eating up 5 combo points with DoC up.

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

Responding to Etapicx's post:The Nature's Swiftness conditionals are already pretty complex. I might try some alternate conditionals to see if I can get better results, but given how infrequently NT is cast during a fight, I would not expect it to make that much difference.

I already addressed the SR/DoC/Rip interactions above.

I suspect the issue with Predatory Swiftness not getting to the 4th combo point is gear related (the sims have been done with full T14 heroic gear). It might be possible to address this by shifting the reforging scheme towards more crit. We need to do some simulations with starting gear to see if reforging can help with this.

You should have a Berserk macro with TF in it. You (almost) never cast Berserk without catsing TF at the same time. The only exception is during the last 15 seconds of the fight. If you need to cast Berserk at a key point in the fight and your energy is high enough that the script is not suggesting TF, cast both anyways and waste the energy. The script does not know what is going on, it only knows what would be best to do on a Patchwerk fight.

The script currently does not include precombat logic. The simc script does include HT in the precombat logic. You should cast it. I will look into putting in some precombat logic, but raiders need to understand what to do beyond just what the script has.

Every time I have tried to put in FF during energy pooling in simc, it has been a dps loss. Maybe I have just not found the right conditionals yet. You can cast it during pooling if you think it won't interfere with anything else.

Requesting adding a tick option into the script to show HT when we have PS up outside of DoC spec. Possibly adding energy starved condition into it. It is still quite helpfull in raids outside of DoC spec.

There seemed so many bugs with not DoC rotation (Hotw spec) on Feng HC I had no clue what was going on sometimes. DoC was perfectly fine. Basicly it looked like FB was many times way to agressive.Couldnt stream/record due to bug, tomorrow Ill get stream on Garajal HC and I will probably stick to HoTW so I will have video. Too focused this raid to be much bothered what exacly was wrong.

FB is aggressive due to SotF and is independent of DoC or HotW. You will have times when Rip is down, but that simmed as a significant dps up. SotF wants you to use combo points in order to get more energy for more attacks and of course, more dps.

I would really like the script to add two combo points on crits in the predictive code. Trying to keep this general, would it be possible to get a new parameter in SpellInfo to call out when a given Spell will generate two combo points on a crit? For example:

and repeated for Rake and Ravage (Swipe does not generate extra combo points on crits).

There is a noticeable lag in game for the second combo point from Primal Fury to show up in the combat log, and this results in visually changing the recommendation to the user on almost every combo point crit when the current combo points are <=3. aggixx worked around this by redirecting the Ovale code to a Weak Aura he created (here is the hook he created: viewtopic.php?f=11&t=852#p8445). This, of course, requires re-editing the Ovale code on every new release.

Sorcerer wrote:Requesting adding a tick option into the script to show HT when we have PS up outside of DoC spec. Possibly adding energy starved condition into it. It is still quite helpfull in raids outside of DoC spec.

I am reluctant to do that. Based on the TF testing I did, it will certainly be a small dps loss to add HT into the script, even if it is while you are pooling energy and it adds complexity to the script. My preference is to keep the script focused on providing an optimized rotation and not to try and deal with everything the person needs to track. In the past I had all sorts of checkboxes for people to customize what was tracked in various icon boxes, and it made the code hard to manage. There are plenty of other addons you can use.

In my case, since I was already using Weak Auras for my combo point display (using aggixx's code), I went ahead and created a thin progress bar for tracking PS. I have it between my combo point display and my Ovale display so I can track PS at the same time I am looking at the Ovale suggestions. You can choose to use HT when needed this way, and also use your PS proc for a BRez.

I'm still seeing the script very very often tell me that I should cast rake as it falls off, not when it's at <=2.9 seconds. I've gotten used to just clipping it anyways, but I am really the only one that's having this issue?

aggixx wrote:I'm still seeing the script very very often tell me that I should cast rake as it falls off, not when it's at <=2.9 seconds. I've gotten used to just clipping it anyways, but I am really the only one that's having this issue?

Hey guys first off i want to say thanks for all the work that you guys put into the script I've taken a month off due to work and just downloaded the new beta version of beta of ovale with the script in it but im getting a lua error that wont go away. If any one has any info it would be a huge help thanks

aggixx wrote:I'm still seeing the script very very often tell me that I should cast rake as it falls off, not when it's at <=2.9 seconds. I've gotten used to just clipping it anyways, but I am really the only one that's having this issue?

Here are the Rake conditionals right now (I am about to add a third one):

if TimeUntilTargetIsDead() >8.5 and RakeTickDamageRatio() >=112 Spell(RAKE) if TimeUntilTargetIsDead() >8.5 and TargetDebuffExpires(RAKE 2.9) and {BuffPresent(BERSERK) or {SpellCooldown(tigers_fury) +0.8 } >=target.DebuffRemains(RAKE)}

Here is what the second conditional looked like in 4.3:

if TargetDeadIn(more 8.4) and TargetDebuffExpires(RAKE 2.9 mine=1) and {BuffPresent(BERSERK) or Mana(more 70) or {{spell(TIGERSFURY)+0.8}>target.debuffExpires(RAKE mine=1)}} Spell(RAKE)

Maybe it is the missing Mana(more 70) that is the problem as it might be waiting for TF but we have too much energy to get to TF in time. My 4.3 script was based off of the Mew rotation (several of us spent a lot of time on that), and the simc rotation was copied from the Mew rotation. It is possible (likely) that the simc rotation had either errors in it, or it was behind.

When I make a new version of the script to match the most recent changes I made in the simc script, I will drop in the 4.3 version of that conditional.