aggixx wrote:Alright, I've reverted the most recent update entirely. Long story short it was my fault and I shouldn't have committed it in the first place, Ovale doesn't properly support weapon damage calculations and I forgot that.
The fix ShmooDude describes works to an extent, but the base damage is set so that I can calculate the hit size based on my equipped weapon, so it's really not appropriate to use that number for others.
I've also incorporated the change you requested ShmooDude, thanks for the code snippet, made it nice and easy.
The new version should be available some time today or tomorrow depending on when Jeshu accepts the pull request.
Are you sure you got it? I see the code snipet that I asked for, but the problematic line is still there and its still suggesting rake at any ratio of 100 or more.
What was it before? a simple RoR check? (since barring say primordius is probably the only way currently to make this true besides unequipping our weapon)
EDIT: Actualy at really high attack power levels it becomes true, last few seconds of my heroic rentaki's proc puts rake damage over mangle (though not shred, of course I'm 1:1:1 reforged might even end up true for someone mastery reforged)
aggixx wrote:It does not, nice catch. Submitted a pull request with the fix for that. That might explain why it was frequently not suggesting to clip Rip during Rune.
Along that note, that line NEVER fires in the non-doc section. Pretty sure it'd have to get moved higher up (for example I can have a 1 CP rip up and 5 cps and it'll suggest ferocious bite even though the rip ratio is something like 1000%
Looks like "if not" doesn't work? I changed it to "unless" and then it works. But that can't be the whole story because you have "if not" in many other places that it does work (or the whole thing would be bollocks). Best guess is BITWRange() isn't returning as expected (maybe its returning "true" or "nothing" and "not nothing" isn't false?)
EDIT2: It defiantly has some weird behavior. Take this for example:
if BITWRange() Spell(MANGLE_CAT)
if not BITWRange() Spell(SHRED)
no target = shred
target > 25% health = mangle with an estimation of how long to GET to 25% health (red as if its not usable)
target <= 25% health = mangle
and "if not BITWRange()" is the same as "if not target.HealthPercent() <= 25" while "unless target.HealthPercent() <= 25" is the same thing as "if target.HealthPercent() > 25" So it looks like "not" doesn't work with less than or greater than conditionals because its not strictly a boolean return but a number?
EDIT3: Yeah looking at the documentation HealthPercent() can return either a boolean OR a number depending on how you call it
target.HealthPercent() < 25 returns a number while
target.HealthPercent(less 25) returns a boolean (there is no "less than or equal" setting however, according to the tooltip its a less than anyhow)
So actually I think this probably needs to be fixed in a lot of places as there are many functions that work this way. I might hunt some down before I go to bed.
EDIT4: Except changing that doesn't work (tried making it less 25 didn't change the broken functionality), I'm really not sure what its doing at this point unless it simply never returns a boolean, lol. I would say probably to not use "not" on any multi return type functions. You have to use "unless"