Grenache wrote:I also noticed it wasn't suggesting I use Savage Roar, and then I realised I hadn't put the SR glyph in. Once I did that, it was fine.

If you are not seeing any ability showing up in Ovale, make sure you have the Glyph of Savagery and...

MAKE SURE THAT EVERY ABILITY SHOWS UP ON AN ACTION BAR SOMEWHERE! MACROS DO *NOT* COUNT.

This rotation has been fully tested by many of us, and anytime we have had issues with things not showing up it is because the abilities have not been dragged out of the spellbook and/or talent tree onto an action bar. If you put spells into macros (I have macros for some abilities for example) then drag the actual ability onto an action bar somewhere else. You can put the abilities on a hidden action bar if you want (this is what I am doing) so you don't have to worry about clutter.

This is an Ovale issue that has shown up in 5.04. It is exacerbated by some really poor handling of macros by Blizz. Put some different abilities into macros, get the addon idTip, and hover over the macros and the equivalent spells, and you will sometimes see different spell ids in the tooltips. Fortunately, casting Bear Mangle while in cat form causes Cat Mangle to be cast (they took off the bear and cat modifiers so in macros all Mangles look alike).

Leafkiller wrote:I would suggest that everyone using the script disables the FF option. I think the issue is either Ovale or an in-game bug. The script itself is pretty simple - it just calls for FF is the armor debuff stack is less than 1...And yes, I am checking for the armor debuff stack and not for FF.

I am late to the party here. I am the author for Nerien's Ovale Scripts and lately added to the Ovale development team.

There was a change to Ovale with the patch release that made all buff/debuff checks default to the old "mine=1" condition. The way that you now check for a buff/debuff that can be applied by anyone is to use the new condition "any=1", e.g., target.DebuffStacks(weakened_armor any=1) < 3.

I hope this information can be used to improve your feral script. Please let me know if there are any bugs or weird results and I'll do my best to help.

Leafkiller wrote:This is an Ovale issue that has shown up in 5.04. It is exacerbated by some really poor handling of macros by Blizz. Put some different abilities into macros, get the addon idTip, and hover over the macros and the equivalent spells, and you will sometimes see different spell ids in the tooltips. Fortunately, casting Bear Mangle while in cat form causes Cat Mangle to be cast (they took off the bear and cat modifiers so in macros all Mangles look alike).

What Ovale currently does is loop through your spellbook and your action bars to "learn" all of the spells that you should be able to cast. Unfortunately, as you've seen, you can actually cast more spells than that because some spells "morph" when they are dragged onto the action bars, e.g., in Guardian spec, dragging Thrash (106832) from the spellbook onto an action bar suddenly turns it into Thrash (77758). There is an open ticket with a solution to this in Ovale Ticket #156, and once we nail down a clean way to solve this, this problem should go away. I agree that it's quite annoying and very hard on new Ovale users especially.

Thanks for the update on the changes to Ovale. I had not seen anything that indicated "mine=1" was now the defualt. I was planning on reaching out to you anyways to find out what your plans were for your scripts in MoP, but then I saw that you had joined the Ovale team, which pretty much answered my question.

What would be really helpful would be a place where script writers could post specific questions and get timely answers. Things tend to get lost on the Ovale class forums. I have exchanged PMs with Sidoine on Curseforge in the past, but I didn't want to bug him too much, especially right now when there are a lot of issues to resolve.

For example, I saw that division was listed as working in a recent build, and I was wondering about multiplication. I would like to combine these 4 statements:

You can also very slightly optimize the runtime of the script by using Counter(ripshreds less 3) instead of Counter(ripshreds) < 3, and similarly for other functions that can take comparison conditions, e.g., ComboPoints(), etc., but it's usually not worth it if it sacrifices readability.

Also, right now, documentation for Ovale is a bit lacking. I think Sidoine has just been devoting so much time to getting Ovale ready for MoP that user-friendly documentation has fallen by the wayside. We're probably going to have the documentation be automatically generated at some point in the (hopefully near!) future. However, if you have any questions, please feel free to PM me or ask on this thread. Your Feral DPS Ovale script is what got me into Ovale, and later SimulationCraft, in the first place I'll try to check in at least once a day here.

Thanks! I am sure there are quite a few things that can be done to make the script more efficient. I sometimes worry about it being to large as I have seen Ovale be very sensitive to high lag situations.

One question I have is whether or not adding spell info makes a difference. For example, this shows up in the 519 default druid script:

This is providing the spell info for (Guardian) Berserk buff*. More often then not, I leave out the SpellInfo and SpellAddBuff lines when I define spells since Ovale does use the API to check buff/debuff durations. Is there an advantage to using SpellInfo/SpellAddBuff (not including special cases such as counters)?

* As a side note, in the spellbooks, Guardian Berserk has spell id 106952, but the buff shows as 50334. In Feral the spellbook and the buff show as spell id 106951 (this is on live). The default script is using 50334 for the feral script which is incorrect (not to mention the feral duration for Berserk is 15 seconds).

Adding SpellInfo() helps in the sense that it improves your script's performance at run time. Without them, Ovale will ask for information it needs through the WoW API. If you do add SpellInfo() lines, then Ovale will use that information to avoid making extra WoW API function calls.

SpellAddBuff() and the rest of its family of statements are helpful, but less so since Ovale does hook into the combat log directly to see which buffs/debuffs are applied or removed. Ovale uses the SpellAddBuff(), etc., statements to help figure out which action should be next to be shown in an icon during the GCD after a spell is cast. Often, it won't matter because action priority lists generally aren't complex enough that it affects what's shown, but it's definitely possible. I don't think feral scripts rise to that level of complexity.

I hope that information helps.

As for fixing the default scripts, I'm busy making hand-translations of the SimulationCraft profiles into Ovale scripts. Once I've tested them to see that they work, I'll go back over the default scripts and compare them to mine to see where they might be going wrong. Right now, the default scripts are machine-translated, so I expect errors where the SC profile couldn't be translated perfectly into a working Ovale scripts.

As an addendum regarding SpellInfo(), the simplest thing you can do to improve your script's run-time performance and to reduce lag is to include information regarding the spell cooldown, e.g., SpellInfo(thrash_cat cd=6). This makes Ovale avoid calling GetSpellCooldown() to figure out when thrash_cat will next be ready.

Jeshu wrote:As an addendum regarding SpellInfo(), the simplest thing you can do to improve your script's run-time performance and to reduce lag is to include information regarding the spell cooldown, e.g., SpellInfo(thrash_cat cd=6). This makes Ovale avoid calling GetSpellCooldown() to figure out when thrash_cat will next be ready.

What should I do with a spell like Rip where the duration can be 16, 18, 20 or 22 depending on the number of Shreds (not counting the bug that sometimes makes Rips last up to 24 seconds)?

Leafkiller wrote:What should I do with a spell like Rip where the duration can be 16, 18, 20 or 22 depending on the number of Shreds (not counting the bug that sometimes makes Rips last up to 24 seconds)?

The "duration" spell info is only important if you use any of the "ticks" functions, e.g., NextTick(), Ticks() or TicksRemain(), as it's used to figure out how many ticks there are, taking spell haste into account. I don't think these functions are used in your feral script, so setting "duration" or "ticks" isn't too important. Given how Rip gets extended like it does, there's no good way in Ovale to make the "ticks" functions return the correct result all of the time anyway.

In an effort to make my script as responsive as possible I am going through the process of adding SpellInfo, SpellAddBuff, and SpellAddTargetDebuff where appropriate.

I was looking at the documentation for SpellAddBuff and it says the following:

SpellAddBuff(spellid buff1id=99 buff2id=99...)

1The SpellId of the spell that applies the buffsbuff1id, buff2id...The name of the parameter is the SpellId of the buff spell, and the value is its duration in seconds. if the value is 0 it means that the buff is removed. If the value is negative, it is the number of stacks that are removed.

I notice in the code there are lots of places where I see "SpellAddBuff(spellname spellname=1)". I am guessing that the "=1" in these cases is because spellname has a defined duration, so the "1" is how many of the spell durations. If it was a buffid, then the number would need to be the number of seconds.

Just a heads up on the default scripts. I copied the SpellInfo for Rip into my script from the default script (shown below). WHen I did that, Rip would not display. The issue was the "combo=0," which also appears on SR and FB. Removing it fixed my issue.

5.4.19 posted. There are no rotational changes. For feral, I added SpellInfo and spell buff/debuff info. The hope is that Ovale will be a bit quicker in indicating what spell to cast as a result of the spell info.

Also, the checkboxes for turning off the left and right cooldown boxes actually remove the boxes now rather than just blanking them out - so for those of you who are using other addons to track cooldowns, you can make the Ovale footprint a lot smaller.

Leafkiller wrote:I notice in the code there are lots of places where I see "SpellAddBuff(spellname spellname=1)". I am guessing that the "=1" in these cases is because spellname has a defined duration, so the "1" is how many of the spell durations. If it was a buffid, then the number would need to be the number of seconds.

Is this correct, or are all the places with "=1" suspect?

As far as I know, the =1 should be the duration of the (de)buff in seconds.

1The SpellId of the spell that applies the buffsbuff1id, buff2id...The name of the parameter is the SpellId of the buff spell, and the value is its duration in seconds. if the value is 0 it means that the buff is removed. If the value is negative, it is the number of stacks that are removed.

Leafkiller wrote:Just a heads up on the default scripts. I copied the SpellInfo for Rip into my script from the default script (shown below). WHen I did that, Rip would not display. The issue was the "combo=0," which also appears on SR and FB. Removing it fixed my issue.

That will inform Ovale that when Rip is cast that it consumes all the CPs (technically, it takes what it thinks is the existing number of combo points, and adds the value from "combo" to it, and if it's less than zero, then it resets the combo point state to zero). FB, SR and Maim should also have "combo=-5".

You should also add the following bits to Mangle, Shred, and all the other CP generators:

These lines aren't strictly necessary because Ovale refreshes the combo point state every 0.1s by default by querying the server anyway. However, they help Ovale predict the next spell to cast during that 0.1s interval. This has the potential to reduce flickering that you can sometimes see when Ovale is indecisive between two different actions, which usually happens because the game state that Ovale tries to keep using the information its given through SpellInfo() doesn't always match the exact conditions of the game.

Leafkiller wrote:I was looking at the documentation for SpellAddBuff and it says the following:

SpellAddBuff(spellid buff1id=99 buff2id=99...)

1The SpellId of the spell that applies the buffsbuff1id, buff2id...The name of the parameter is the SpellId of the buff spell, and the value is its duration in seconds. if the value is 0 it means that the buff is removed. If the value is negative, it is the number of stacks that are removed.

The documentation is correct but incomplete. When you have a SpellAddTargetDebuff() line (similarly for SpellAddBuff()), it tells Ovale which debuffs will be applied by the spell. There are two ways to tell Ovale the duration of each debuff: either by stating it in the SpellAddTargetDebuff() line directly (as above) or by adding an appropriate SpellInfo() line with a duration=n condition. The SpellInfo() duration information actually has higher priority than the one listed in the actual SpellAddTargetDebuff() line.

Leafkiller wrote:I notice in the code there are lots of places where I see "SpellAddBuff(spellname spellname=1)". I am guessing that the "=1" in these cases is because spellname has a defined duration, so the "1" is how many of the spell durations. If it was a buffid, then the number would need to be the number of seconds.

Is this correct, or are all the places with "=1" suspect?

When you see "SpellAddBuff(spellname spellname=1)" it tells Ovale that "spellname" applies a buff with the same spell ID, and the duration for that buff is found by looking at the SpellInfo(spellname duration=n) line. If there was no corresponding SpellInfo() line, then the "=1" would make Ovale think the buff only lasted for 1 second. In the default script, the "=1" is okay because of all the durations are listed in SpellInfo() lines.

The above means that "faerie_fire" with a spell ID of 770 applies two debuffs, "faerie_fire" and "weakened_armor". The durations of those two debuffs can be found in the SpellInfo() lines for those two spell IDs. You don't need a SpellAddBuff() line for weakened_armor because it's not actually a castable spell.

One more thing: if you actually add all of this information to your Ovale script, then you might want to see if that solves the lag issues with adding the second box with the rotation minus the fillers. I suspect that it will.

Leafkiller wrote:I am sure there are quite a few things that can be done to make the script more efficient. I sometimes worry about it being to large as I have seen Ovale be very sensitive to high lag situations.

This statement escaped my attention earlier, but let me try to explain why you shouldn't worry about the length of your script.

Ovale "compiles" your script into a pretty efficient representation that includes only commands within AddFunction() and AddIcon() groups. All of the Define(), SpellInfo(), SpellAddBuff(), etc., statements are all just information that Ovale reads in and refers to in lookup tables. So, don't worry about the length of your script -- most of the information gets boiled away into nothing that impacts the player at run-time.

Thanks for all of the help. I am going to make sure that the scripts include correct spellinfo going forward to minimize flicker. Per Mihir's comment/request, I will also reinstate the "look ahead" icon.

Next up is to add the rotation improvements to the shred filler script.