ShmooDude wrote:Its because Clearcasting Thrash is fairly high up in the list and doesn't have a test for that particular instance. And given that those exact conditions occur in ~14% of simcraft's 7.5 minute fights, I don't think it'd even be possible to tell whether that'd be a dps upgrade or not (the two 50k interations I did and it ended up a 60 DPS downgrade, well within the margin of error). Besides, a rune buffed thrash isn't exactly a bad thing.

Yeah, I honestly wasn't sure how they compared. Hence the questions.

Will the script suggest a non-Clearcasting Thrash with a Rune proc up? I would think that would be a DPS loss if it prevents you from getting a Rip up. Another thing I've noticed is that the script will ask you to Faerie Fire during a Rune proc as well. I would think that deferring Faerie Fire until you get your bleeds up would be better.

I've also seen the script want to pool energy during a Rune proc, so Mangle is showing up but the script wants me to wait before hitting it. This can lead to some frantic last minute spamming when it finally lights up as I try to get the Rip up. Again, maybe I'm doing it wrong, but my instinct when Rune procs is to pound CP-generators frantically to try to get the combo points built to get the Rip up. Waiting to hit an ability that generates CP if I have that energy available seems counter-intuitive to me, especially when playing DoC spec, since I need time to hit Healing Touch before the Rip also if possible.

ShmooDude wrote:I'd post it now but 5.3.5 has a few more bugs that need to be ironed out (target based bleed snapshotting and damage modifier buffs (savage roar, etc.). I fixed my local copy of the savage modifier buffs bug but I'm waiting on the other fix from Jeshu so that I can update it for that before I post a new one.

I will probably also try to add another script condition that returns the "normalized AP-modified weapon damage" which I believe is the "weapon damage" cited in most damage formulas. Currently the WeaponDamage() script condition returns the average of the min and max damage of the equipped mainhand (with some munging for cat and bear druids), but in the general case, you would also need the type of weapon to figure out the correct normalized attack speed to use in the calculation. It's not needed for ferals, but will be needed for other classes that have attacks based on weapon damage.

Aura snapshots are fixed only for target.debuff and not lastspell (or last, which are the same thing afaik). Since those are essentially legacy functions at this point I'm not sure it matters but figured I'd let you know.

The snapshotting doesn't seem to be 100% in regards to catching (near) instantaneous buff changes. Right now a TF macro can have both results (ie it might think it has the buff up, but then again it might not). The same is true if you reverse the order of the abilities (if i cast rake before TF, it also can produce both results). If I had to guess, its because the server can return the info in either order (which the combat log is notorious for doing).

It also doesn't solve the problem of incorrect suggestions for expiring buffs (but there may not be a viable solution for that; my script currently is decent with this because I give some allowance at the end of buffs to not use bleeds and so it only switches back for a split second, not really long enough for the player to react; that won't really be the case for most scripts I don't think though) For ferals, the old method of always being wrong is probably better because we can just always apply another rake which isn't a huge dps loss anyhow. Unsure about other classes.

The only fully accurate method I could think of would be to go from the damage directly and ignore all these other factors (except crit) in trying to calculate it (afaik no dots have "damage ranges"; please feel free to correct me if I'm wrong). While this would work extremely well for Rake, most other dots would have to "wait" until the damage ticked. I suppose maybe we could use the current method as an estimate until we see the raw damage tick and then update it?

Simply might not be a solvable problem and with the exception of macro'd abilities, probably doesn't come up as often as we think given that its been there the entire time.

target.DebuffComboPoints always returns 0; For now I'll probably just use target.Debuff for everything but that till fixed as you can't reliably get Rip up on a significant number of targets anyhow.

Jeshu wrote:I will probably also try to add another script condition that returns the "normalized AP-modified weapon damage" which I believe is the "weapon damage" cited in most damage formulas. Currently the WeaponDamage() script condition returns the average of the min and max damage of the equipped mainhand (with some munging for cat and bear druids), but in the general case, you would also need the type of weapon to figure out the correct normalized attack speed to use in the calculation. It's not needed for ferals, but will be needed for other classes that have attacks based on weapon damage.

Ah, yeah, good point. While most specs only rely on one item type and could probably make assumptions as to their AP coefficient, this would definitely be the more correct method.

Also, would it be possible to have access to the upgrade state of a trinket? This would allow me to account for all possible ilvls of a trinket (where as now I can only differentiate between ones with different item IDs and have to make assumptions about the upgrade level).

EDIT: Also, are certain calls more CPU intensive than others? I went and checked the CPU usage of my script and its roughly doubled over current Leafkillers (course its also about double the length too). I guess I'm asking if there's any way for me to optimize. Current script can drop FPS from like 60 to 40 at the target dummies if all my procs are up (especially Renataki's probably because it requires calculation based on stacks)

Aura snapshots are fixed only for target.debuff and not lastspell (or last, which are the same thing afaik). Since those are essentially legacy functions at this point I'm not sure it matters but figured I'd let you know.

I'm not sure what you mean here. Which script conditions aren't working and do you have an example script I can look at? They're not legacy script conditions because not all spells apply auras.

ShmooDude wrote:The snapshotting doesn't seem to be 100% in regards to catching (near) instantaneous buff changes. Right now a TF macro can have both results (ie it might think it has the buff up, but then again it might not). The same is true if you reverse the order of the abilities (if i cast rake before TF, it also can produce both results). If I had to guess, its because the server can return the info in either order (which the combat log is notorious for doing).

This I don't think we can do that much about. Ovale can only see the game from what happens in the combat log, including everything that the player does, so if two events are simultaneous and can have slight ordering issues in the combat log, there's nothing Ovale can do.

ShmooDude wrote:It also doesn't solve the problem of incorrect suggestions for expiring buffs (but there may not be a viable solution for that; my script currently is decent with this because I give some allowance at the end of buffs to not use bleeds and so it only switches back for a split second, not really long enough for the player to react; that won't really be the case for most scripts I don't think though) For ferals, the old method of always being wrong is probably better because we can just always apply another rake which isn't a huge dps loss anyhow. Unsure about other classes.

You'll need to explain what is the "problem of incorrect suggestions for expiring buffs". I'm not sure what you're referring to here. Again, an example script would be helpful.

ShmooDude wrote:The only fully accurate method I could think of would be to go from the damage directly and ignore all these other factors (except crit) in trying to calculate it (afaik no dots have "damage ranges"; please feel free to correct me if I'm wrong). While this would work extremely well for Rake, most other dots would have to "wait" until the damage ticked. I suppose maybe we could use the current method as an estimate until we see the raw damage tick and then update it?

This is easy to do, but it's not helpful for dealing with SimC action lists that ask for the stats active for a buff. For the narrow problem of comparing damage of a DoT, you can already check on the damage caused by a DoT tick using LastDamage.

ShmooDude wrote:target.DebuffComboPoints always returns 0; For now I'll probably just use target.Debuff for everything but that till fixed as you can't reliably get Rip up on a significant number of targets anyhow.

This is a bug. I'll take a look. If you could submit a ticket to remind me, that would be great.

ShmooDude wrote:Also, would it be possible to have access to the upgrade state of a trinket? This would allow me to account for all possible ilvls of a trinket (where as now I can only differentiate between ones with different item IDs and have to make assumptions about the upgrade level).

This isn't too hard to implement. Could you submit an enhancement ticket for this? I will probably just expose the item level of the gear in a given slot instead of the upgrade level.

ShmooDude wrote:EDIT: Also, are certain calls more CPU intensive than others? I went and checked the CPU usage of my script and its roughly doubled over current Leafkillers (course its also about double the length too). I guess I'm asking if there's any way for me to optimize. Current script can drop FPS from like 60 to 40 at the target dummies if all my procs are up (especially Renataki's probably because it requires calculation based on stacks)

There are probably ways to optimize, but in the end, complex scripts just take a lot of time to process. Ovale is easily one of the most CPU-hungry addons because it tries to compute so much on every frame refresh (OnUpdate). It basically executes the entire script in each frame refresh. This could be changed, but these are parts of the Ovale code that I'm not comfortable tinkering with yet.

@SchmooDude: One way you could perhaps optimize your script is to get some help from the player. Create a checkbox list that lets the player select which trinkets are equipped and you can use that data to make some of the script unreachable if it doesn't pertain to the selected trinkets.

ShmooDude wrote:Aura snapshots are fixed only for target.debuff and not lastspell (or last, which are the same thing afaik). Since those are essentially legacy functions at this point I'm not sure it matters but figured I'd let you know.

I'm not sure what you mean here. Which script conditions aren't working and do you have an example script I can look at? They're not legacy script conditions because not all spells apply auras.

Those two can differ when using a TF/Rake macro. If it catches the Tiger's Fury and waits to update the stat, target.debuff will wait where as last won't (ie target.debuff will be 15% higher than last). If it doesn't catch Tiger's Fury, then they'll match.

Jeshu wrote:This I don't think we can do that much about. Ovale can only see the game from what happens in the combat log, including everything that the player does, so if two events are simultaneous and can have slight ordering issues in the combat log, there's nothing Ovale can do.

I agree, this is probably as close as we're going to get until Blizzard updates the combat log to be more accurate (which is something they've said they wanted to do in the past, but I have my doubts it'll ever get down, probably not a high priority).

Jeshu wrote:You'll need to explain what is the "problem of incorrect suggestions for expiring buffs". I'm not sure what you're referring to here. Again, an example script would be helpful.

The first will appear and disappear a little after the second (when if we were 100% accurate they should both function identically). This means that the first icon will suggest Rake incorrectly for a split second before the character sheet updates. Again, probably not a solvable problem for ovale but thought you'd want to know in case you have any ideas.

Jeshu wrote:This is easy to do, but it's not helpful for dealing with SimC action lists that ask for the stats active for a buff. For the narrow problem of comparing damage of a DoT, you can already check on the damage caused by a DoT tick using LastDamage.

I knew there was a function for this, I remember playing around with it but for the life of me couldn't remember what it was. There's a couple things that keep it from being usable for what I want:1) I can't tell if its a crit or not (this would have to be factored out, I'd also need a crit damage bonus value)2) It only considers the last damage event, and not the last damage event on the target (which is probably correct compared to all the other "last" functions, so I guess I'm asking for a target.DebuffDamage() function)

I'll make an enhance ticket for this too.

Jeshu wrote:This is a bug. I'll take a look. If you could submit a ticket to remind me, that would be great.

Will do

Jeshu wrote:This isn't too hard to implement. Could you submit an enhancement ticket for this? I will probably just expose the item level of the gear in a given slot instead of the upgrade level.

Either way works, pretty sure the coding requirements on your end will be roughly the same (have to pull the upgrade level out of the tooltip and then recalculate the ilvl from the base item).

Jeshu wrote:There are probably ways to optimize, but in the end, complex scripts just take a lot of time to process. Ovale is easily one of the most CPU-hungry addons because it tries to compute so much on every frame refresh (OnUpdate). It basically executes the entire script in each frame refresh. This could be changed, but these are parts of the Ovale code that I'm not comfortable tinkering with yet.

Yeah, comparisons seem to take a lot of power where as anything that's fairly static is cheap. For example I have a bunch of functions that return just a number that's used in multiple parts of the script. I tried removing these to see if it affected the performance and it had zero impact except for the initial compile time when I pasted the script in (I assume, wasn't really noticeable).

In particular, these code blocks seem to be fairly intensive if you or anyone else has any ideas.

AddFunction TigersFuryRakeUsableBeforeExpire # Checks to make sure you have the energy/cooldown to use a bleed before the Rune buff expires{ if Energy() >= EnergyForRake() {BuffRemains(TIGERS_FURY) > {ExpiringBuffSafetyMargin()}} and BuffRemains(TIGERS_FURY) > {SpellCooldown(RAKE)+ExpiringBuffSafetyMargin()} unless Energy() >= EnergyForRake() {BuffRemains(TIGERS_FURY) > {TimeTilEnergyForRake()+ExpiringBuffSafetyMargin()} or BuffPresent(CLEARCASTING)} and BuffRemains(TIGERS_FURY) > {SpellCooldown(RAKE)+ExpiringBuffSafetyMargin()}}

Only really requires a lot of CPU power while TF is up, then goes back to more normal levels. When the similar code blocks for all the other buffs run simultaneously, it really eats up the cpu cycles. Think I'm gonna add one test to the function that calls this one so it only triggers towards the end of a buff when there's a possibility of it being true.

Last edited by ShmooDude on Tue Jul 16, 2013 3:39 pm, edited 1 time in total.

ShmooDude wrote:Its because Clearcasting Thrash is fairly high up in the list and doesn't have a test for that particular instance. And given that those exact conditions occur in ~14% of simcraft's 7.5 minute fights, I don't think it'd even be possible to tell whether that'd be a dps upgrade or not (the two 50k interations I did and it ended up a 60 DPS downgrade, well within the margin of error). Besides, a rune buffed thrash isn't exactly a bad thing.

Pretty much this. I've toyed with it in the past but I've never been able to get restricting it's use to actually be a clear DPS gain. If you see a situation where you know it's the difference between getting that Rip off or not you should definitely ignore the script and go for the Rip, but realistically that is a very rare scenario that would be difficult for the script to detect and not worth the CPU cycles or time to implement.

Kihrawr wrote:I've also seen the script want to pool energy during a Rune proc, so Mangle is showing up but the script wants me to wait before hitting it. This can lead to some frantic last minute spamming when it finally lights up as I try to get the Rip up. Again, maybe I'm doing it wrong, but my instinct when Rune procs is to pound CP-generators frantically to try to get the combo points built to get the Rip up. Waiting to hit an ability that generates CP if I have that energy available seems counter-intuitive to me, especially when playing DoC spec, since I need time to hit Healing Touch before the Rip also if possible.

This is just an oversight I believe, probably best to add a filler conditional for this, something like "if rune is up and rip ratio > 1.15" would work I think.

Jeshu wrote:I will probably also try to add another script condition that returns the "normalized AP-modified weapon damage" which I believe is the "weapon damage" cited in most damage formulas.

As far as I'm aware that is indeed the "weapon damage" used in all ability damage formulas.

Jeshu wrote:

ShmooDude wrote:EDIT: Also, are certain calls more CPU intensive than others? I went and checked the CPU usage of my script and its roughly doubled over current Leafkillers (course its also about double the length too). I guess I'm asking if there's any way for me to optimize. Current script can drop FPS from like 60 to 40 at the target dummies if all my procs are up (especially Renataki's probably because it requires calculation based on stacks)

There are probably ways to optimize, but in the end, complex scripts just take a lot of time to process. Ovale is easily one of the most CPU-hungry addons because it tries to compute so much on every frame refresh (OnUpdate). It basically executes the entire script in each frame refresh. This could be changed, but these are parts of the Ovale code that I'm not comfortable tinkering with yet.

Doesn't really surprise me at all the be honest looking at some of the things you implemented in the script, some of them immediately struck me as CPU hungry. I'm sure there's a lot more efficient ways of achieving some of the things by implementing the Ovale instead of trying to do them in the script.

For example, adjusting the Damage() function so that when you have insufficient energy to cast a spell it returns the damage of the spell based on what buffs you would have in (Energy()-Cost)/EnergyRegen() seconds. That way you wouldn't need many of the extra functions you added.

Melee Crit functions are already implemented, so you're good there. An optional boolean parameter that would ceil the value at 100 would probably be helpful (default would be true, but you could set it to false for calculation of abilities like Chaos Bolt or Soul Fire).

Physical damage reduction of the target (armor) would probably be more suited to being implemented in Ovale rather than in the script. At least in the last version you posted you're doing a ton of unnecessary calculations when you could just have it return a hard-coded decimal value. Edit: Something like this:

That only has values for bosses, and uses level 92 armor values for everything else, but it keeps it very simple. And since our sunder applies three stacks at a time it's not really worth calculating anything but 3 and 0 stacks.

Target needs to be specified to figure out the appropriate armor reduction to damage.

There's also the more general problem of dealing with target debuffs that increase damage taken, or increase crit chance, etc. These I'm not sure I can implement in Ovale, though I can at least factor in the standard target debuffs available in a raid.

Hey guys, thanks again for all the work you do for your feral brethren.

I went back several days in the posts, and didn't (kind of) notice anything that addressed this, but for me, 5.3.6 is still suggesting rake for pretty much all combo point generation. I use DroodFocus as well, and I'm definitely being told to reapply weaker rakes. I reverted to 5.3.2, and the issue didn't come up. I'm assuming this is tied to the discussion about snapshots, which was posted as fixed. If so, is there something I may be missing?

On a side note, I can't seem to stay logged in to the site on Firefox, but Chrome works fine. Any link I click after logging in on Firefox sends me right back to the login page. Any clue?

Raolf wrote:Hey guys, thanks again for all the work you do for your feral brethren.

I went back several days in the posts, and didn't (kind of) notice anything that addressed this, but for me, 5.3.6 is still suggesting rake for pretty much all combo point generation. I use DroodFocus as well, and I'm definitely being told to reapply weaker rakes. I reverted to 5.3.2, and the issue didn't come up. I'm assuming this is tied to the discussion about snapshots, which was posted as fixed. If so, is there something I may be missing?

On a side note, I can't seem to stay logged in to the site on Firefox, but Chrome works fine. Any link I click after logging in on Firefox sends me right back to the login page. Any clue?

Yeah, apparently 5.3.6 has a bug in the LastSpellEstimatedDamage function in that it no longer accounts for DamageMultiplier where as the Damage function still does, causing a disconnect in the ratios. I put in a ticket for Jeshu.

@Jeshu I noticed a while back that you added to spell info the ability to specify my own damage function for an ability but I've never gotten it to work. My question is, would using this (once functional) have any performance advantage or is it simply another way to call that function (or does it confer some other advantage)? If it does, I'd love to try it out. If not then I'm not really worried about it.

AddFunction IncarnationBerserkLogic{ #incarnation,if=energy<=35&!buff.omen_of_clarity.react&cooldown.tigers_fury.remains=0&cooldown.berserk.remains=0 #use_item,name=eternal_blossom_grips,sync=tigers_fury #tigers_fury,if=(energy<=35&!buff.omen_of_clarity.react)|buff.king_of_the_jungle.up #berserk,if=buff.tigers_fury.up|(target.time_to_die<15&cooldown.tigers_fury.remains>6) if {{Energy() <=35 and BuffExpires(CLEARCASTING)} or BuffPresent(INCARNATION_CAT)} and Spell(TIGERS_FURY) { if CheckBoxOn(berserk) and Spell(BERSERK_CAT) { if TalentPoints(INCARNATION_TALENT) Spell(INCARNATION) if not TalentPoints(INCARNATION_TALENT) or BuffPresent(INCARNATION_CAT) Spell(BERSERK_CAT) } unless BuffPresent(BERSERK_CAT) Spell(TIGERS_FURY) } if CheckBoxOn(berserk) and TalentPoints(INCARNATION_TALENT) and BuffPresent(BERSERK_CAT) Spell(INCARNATION_CAT)}

AddFunction ExecuteRangeRipFerociousBiteLogic # Left one Doc line in here and added a talent check, normally tried to take them out but this one was annoyingly in a bad place so left here for simplicities sake{ #ferocious_bite,if=combo_points>=1&dot.rip.ticking&dot.rip.remains<=3&target.health.pct<=25 if target.HealthPercent() <=25 and ComboPoints() >=1 and target.DebuffPresent(RIP) and target.DebuffRemains(RIP) <=4 Spell(FEROCIOUS_BITE)

#thrash_cat,if=target.time_to_die>=6&buff.omen_of_clarity.react&dot.thrash_cat.remains<3 if target.TimeToDie() >=9 and BuffPresent(CLEARCASTING) and target.DebuffRemains(THRASH_CAT) <3 Spell(THRASH_CAT)

if ComboPoints() >=5 { #natures_swiftness,if=buff.dream_of_cenarius_damage.down&buff.predatory_swiftness.down&combo_points>=5&target.health.pct<=25 if TalentPoints(DREAM_OF_CENARIUS_TALENT) and TalentPoints(NATURES_SWIFTNESS_TALENT) and BuffExpires(DREAM_OF_CENARIUS_DAMAGE) and BuffExpires(PREDATORY_SWIFTNESS) and BuffRemains(SAVAGE_ROAR) >5 Spell(NATURES_SWIFTNESS)

#virmens_bite_potion,if=combo_points>=5&$(time_til_bitw)<15&$(rip_ratio)>=1.15&buff.dream_of_cenarius_damage.up # if not HasTrinket(ROR_ITEM) and ComboPoints() >=5 and BuffPresent(DREAM_OF_CENARIUS_DAMAGE) and RipRatio() >=115 UsePotion()

#virmens_bite_potion,if=combo_points>=5&$(time_til_bitw)<15&buff.rune_of_reorigination.up&buff.dream_of_cenarius_damage.up # if HasTrinket(ROR_ITEM) and ComboPoints() >=5 and BuffPresent(DREAM_OF_CENARIUS_DAMAGE) and BuffPresent(ROR_MASTERY) UsePotion()

AddFunction DocRipLogic # If any changes are applicable to NonDoc logic, also make changes there!!!{ if target.HealthPercent() >25 and ComboPoints() >=5 and target.TimeToDie() >30 and RipRatio() >=92 { #natures_swiftness,if=enabled&buff.dream_of_cenarius_damage.down&buff.predatory_swiftness.down&combo_points>=5&$(rip_ratio)>=0.92&target.time_to_die>30 if TalentPoints(NATURES_SWIFTNESS_TALENT) and BuffExpires(DREAM_OF_CENARIUS_DAMAGE) and BuffExpires(PREDATORY_SWIFTNESS) Spell(NATURES_SWIFTNESS)

AddFunction NonDocRipLogic # If any changes are applicable to Doc logic, also make changes there!!!{ #rip,if=combo_points>=5&$(rip_ratio)>=1.15&target.time_to_die>30 #rip,if=combo_points>=5&target.time_to_die>=6&dot.rip.remains<2&(buff.berserk.up|dot.rip.remains+1.9<=cooldown.tigers_fury.remains) if {target.HealthPercent() >25 and ComboPoints() >=5 and target.TimeToDie() >30 and RipRatio() >= 115} or {target.TimeToDie() >=6 and ComboPoints() >=5 and target.DebuffRemains(RIP) <2} Spell(RIP)}

#healing_touch,if=buff.predatory_swiftness.up&combo_points>=4&buff.dream_of_cenarius_damage.down if BuffPresent(PREDATORY_SWIFTNESS) and BuffExpires(DREAM_OF_CENARIUS_DAMAGE) and ComboPoints() >=4 Spell(HEALING_TOUCH)

First a disclaimer, This script is VERY CPU intensive (something like 4-5x the processing time of current leafkiller's script); even on target dummies it pretty much murders my frame rates from like 60 to 30 at its peak (more buffs you have proc'd the more CPU intensive it is). Just wanted everyone to be aware of this. That said this version does seem to be slightly faster than the 5.3.2 script now that I've optimized it a bit by removing duplicate calls (if X unless X logic was unnecessary as functions will return as soon as they get a valid value). EDIT: Jeshu said he fixed the throttling functionality in ovale. It was updating every frame instead of every 10th of a second OR when something happened (which acutally isn't very often so mostly every 10th of a second). Has a pretty decent impact on the performance of the script (I changed mine internally, probably not the proper way but it works enough) but hopefully 5.3.7 will come out soon.

Now, onto the features:

Buff prediction now supports all current tier trinkets (currently assumes 2/2 upgrade for all trinkets until Jeshu adds the ability to detect ilvl; all new trinkets are currently untested as I only have my two which were in the previous script).Changed rune buff prediction to assume a 2:1 ratio (instead of being in the main script, there were some bugs with that; while not 100% accurate should still give accurate predictions if not a perfectly accurate ratio).Armor now assumes level 92 unless its a boss level, weakened armor is all or nothing (no stack based; this is all done to improve performance)Enabled the if RipRatio >= 115 then apply a new rip all the time instead of just under rune conditions.Changed Rake to be based on damage done instead of a ratio (so for example a slightly under 100 ratio Rake under rune is still a dps up to keep raking). Rake will now also be used on mobs about to die if its still a DPS up (like when rake hits harder than mangle; before wouldn't do it if the rake dot outlasted the mob).Resplit DoC and non-doc (mostly for performance reasons, though was likely pretty minor; bulk of the calculations are for the buff prediction stuff).

Might be a bug or two as I haven't tested it quite as much as I wanted, let me know (especially with other trinkets).

Probably last update for a bit as I got everything in it I wanted essentially. Also gonna see what'd it take to get added to nernian's addon so updating is easier and everyone doesn't have to copy/paste from here.

EDIT: Couple of minor bug fixes, please recopy.

Last edited by ShmooDude on Tue Jul 16, 2013 6:45 pm, edited 2 times in total.

agixx, I know you are the one adding code etc to leafkiller however , I know nothing about code and or where to put stuff, I have ovale 5.3.6 and the most recent update from curse... I am still getting sometimes 7 rake spam recommendations even when I have 5 CP and a rip should be applied .. I do have RoR 530 lvl. however the rake spam was happening even before that trinket . Also sometimes there will be nothing proc'd and it wants me to rake way past 5 CP when I could have bitten and or ripped. also the new leafkiller automatically wants you to rip the minute it sees the ROR proc along with rake spam? I thought you were supposed to rip on 5 CP would a 2 CP rip really outdo a 5 one with the ROR buff . also I have noticed that with all the rake spamming my dps has actually gone down with the trinket and I do track it and do what the script says. I replaced bad juju with it and kept the TF renataki which is what is with my ROR now . can you please tell me is this going to be fixed. I just cant find a reason to spam rake sometimes 6 to 7 times in a row with 5 CP waiting ror buff or not/// that just dosent make sense when shred should be in there. Thanks for letting me replyBacevicius, Undermine

5.3.6 has some bugs in it, revert to 5.3.2 and it will fix your problems until the bugs are fixed (either in the script by moving to some of the new functions which aren't broken or by a new ovale release, I got strong hopes 5.3.7 will be a stable release).

ShmooDude wrote:EDIT: Jeshu said he fixed the throttling functionality in ovale. It was updating every frame instead of every 10th of a second OR when something happened (which acutally isn't very often so mostly every 10th of a second). Has a pretty decent impact on the performance of the script (I changed mine internally, probably not the proper way but it works enough) but hopefully 5.3.7 will come out soon.

Where do we patch the throttling in Ovale to fix it? I want to fix my local copy.

ShmooDude wrote:EDIT: Jeshu said he fixed the throttling functionality in ovale. It was updating every frame instead of every 10th of a second OR when something happened (which acutally isn't very often so mostly every 10th of a second). Has a pretty decent impact on the performance of the script (I changed mine internally, probably not the proper way but it works enough) but hopefully 5.3.7 will come out soon.

Where do we patch the throttling in Ovale to fix it? I want to fix my local copy.

idk how Jeshu fixed it, I tried a bunch of stuff for the built in code and couldn't get it to work, lol.

I'm encountering a weird bug where ovale is forgetting about the stats for Rip in the target.Debuff functions. Question is, is anyone else getting this bug (you'll notice cause the Rip ratio goes into the thousands) and if so where? I've only ever encountered it in raids (never happens on target dummies on which I do *extensive* testing) but seeing as I don't really do a whole lot of other content I can't be certain its not occurring elsewhere.

If you are encountering this bug, could you please post here with your group makeup (since I never see it solo, its almost gotta be something to do with that)?

For the first, I believe that's bliz saying that ovale took too much CPU time and thus stopped it (its capped at like 300ms per run or something?). However it still functions fine despite that error happening occasionally.The second (which I experienced once over ~4 hours) I'm not really sure how to parse, maybe jeshu could help.

Chances are it may just be that the script is trying to do too much and I'll have to cut it down to the bare minimum or find a different logic that's less CPU intensive.

Hello,I have a problem with this script: everytime I have ff and tigers fury up it shows rake. Even if the bleed is already active. Im not sure if this is the right place to ask for my problem, sorry if not.

EDIT: Nevermind, problem was the new ovale version as said before.But now there is another problem, its recomending Mangle even if Im standing behind the target. Is there any way to turn this off?

Paloro wrote:Mangle is actually the better cp generator outside of Berserk and TF.

Ah ok thanks, noxxic wasnt saying anything about that.

Since these types of questions seem to get asked a lot, it would be cool if someone could maintain a generic PvE Feral thread here at the FluidDruid, that outlines all of the best practices, similar to: http://us.battle.net/wow/en/forum/topic/6471617676 but more focused on the action list and mechanics.

Things like: when to use various cooldowns, how to open, how to AoE, when to AoE, when to tab-Rake, casting during HotW, how snapshotting works, how clipping works, various buff strengths (see Ovale/DroodFocus + Catus Rake/Rip tables), symbiosis overview, critical macros (shiftless-HT, TF+Berserk), etc...

It would be cool to have a breakdown of the Simc/Ovale script with approximate English descriptions, so non-technical Cats can understand what's going on.

I think having a comprehensive and up-to-date Feral Cheat-sheet would be very valuable, as a lot of this information is currently spread across various threads.