Jeshu wrote: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.
Code: Select all
AddIcon
{
target.DebuffDamageMultiplier(RAKE)
}
AddIcon
{
LastDamageMultiplier(RAKE)
}
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.
Code: Select all
# don't use anything else that affects the damage multiplier when testing, just tiger's fury
AddIcon { if DamageMultiplier(RAKE) >= 1.15 Spell(RAKE) }
vs.
Code: Select all
AddIcon { if BuffPresent(TIGERS_FURY) Spell(RAKE) }
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.
Code: Select all
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.