Ovale Spell Priority

278 - Time elapsed since buff gain or expire

What version of Ovale are you using?

What class and specialization were you playing when the problem occurred?
Feral Druid

Please provide any additional information below.
Basically what I'm looking for is the time elapsed since a buff expired, but buff gain (which as you told me before is in there but unimplemented) could be useful for some things too.

This was actually really easy to implement as far as this specific functionality goes. I simply went to the OvaleAura.lua and made RemoveAuraIfExpired always return false. This then allowed BuffRemains to continue into the negative values (unless you make the change below) because the aura's information is never released. Only works for buffs, not debuffs though (you'd probably know why).

Doing this change does require some updates to any buff related functions that have the following:

	if start and ending and start <= ending then


	if start and ending and start <= ending and Ovale.now <= ending then

Might be able to get away with just replacing start with Ovale.now but I don't know if that'd have any side effects or not (I wouldn't think it would). Could obviously have other unintended side effects.

A better option would probably be that when that RemoveAuraIfExpired is run that the expired buff's start/ending times are then stored in a new variable for expired auras and thus not interfering with any of the current code (and being more memory friendly as these are the only 2 variables we need for this functionality). I'm assuming it'd also need some garbage collection too (I'm probably telling you things you already know, but I'm doing it for my own education as I need more programming practice)n

As far as the functions themselves (the ones scripters have access to). I could see this as either being a parameter to BuffRemains or an entirely new function (a parameter might be more flexible as it'd allow one function to have the whole gamut of possibilities instead of it being split into BuffRemains for the time till expire and TimeSinceBuffExpired (or whatever you'd name it) for the time since expiration).

User When Change
jlam May 08, 2014 at 21:04 UTC Changed status from Accepted to Fixed
jlam Jul 24, 2013 at 19:21 UTC Changed status from New to Accepted
jlam Jul 24, 2013 at 19:20 UTC Changed assigned to from Sidoine to jlam
ShmooDude Jul 24, 2013 at 14:30 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • Avatar of jlam jlam May 08, 2014 at 21:04 UTC - 0 likes

    BuffRemains() should continue into negative values in the latest release.

  • Avatar of ShmooDude ShmooDude Oct 20, 2013 at 12:53 UTC - 0 likes
    OvaleCondition.conditions.buffremains = function(condition)
    	local auraId, comparator, limit = condition[1], condition[2], condition[3]
    	local start, ending = GetAura(condition, self_auraFound)
    	if not start or not ending then
    		if condition.track == 1 and self_auraFound.ending and self_auraFound.start then
    			return TestOvaleValue(self_auraFound.start, self_auraFound.ending, self_auraFound.ending - self_auraFound.start, self_auraFound.start, -1, comparator, limit)
    			return Compare(0, comparator, limit)
    		return TestOvaleValue(start, ending, ending - start, start, -1, comparator, limit)

    change the buff remains code to that and then make a script with the following:

    Define(TIGERS_FURY 5217)
    AddIcon { BuffRemains(TIGERS_FURY track=1) }

    Now, instead of stopping at 0, buff remains will go into the negative. I made no changes to how the auras are actually stored, the data is there. If its intended to be cleared, its currently not clearing it.

  • Avatar of ShmooDude ShmooDude Sep 29, 2013 at 20:12 UTC - 0 likes

    Actually turned out this was really easy because OvaleAura keeps aura data after expiration so no changes to anything else was needed.

    Also added a TimeSinceLastSnapshot() function to help take advantage of the new functionality (these two together will help my bleed prediction stuff significantly).

    Last edited Sep 29, 2013 by ShmooDude
  • Avatar of ShmooDude ShmooDude Jul 24, 2013 at 22:29 UTC - 0 likes

    Oh yeah, one other thought. If, once this is done, I could also have access to the last stat snapshot time (which looks like it should be pretty easy; I could probably do it but I don't have time atm). What I'm thinking is with these two additions, I could near perfectly fix the stat snapshots around buff expiration (at least as far as ovale's suggestions in the feral script; its not the kind of thing ovale should do as a whole as it requires accounting for every buff in the game).

    Logic would be something like this:
    if LastStatSnapshotTime() >= BuffExpirationTime() and TimeSinceBuffExpired() >= 0
    <factor out the buff from ratios>
    or if you decide to go the parameter route:
    if LastStatSnapshotTime() >= BuffExpirationTime() and BuffRemains( allownegative=1) <= 0

    That should, barring simultaneous expiring/adding buffs, perfectly eliminate bad suggestions occurring slightly after a buff expires without having to overshoot by using an assumed duration (which is what I was thinking before). However, feel free to let me know if you think there's a better way this could be done.

  • Avatar of ShmooDude ShmooDude Jul 24, 2013 at 21:52 UTC - 0 likes

    I would think that if you went the new variable route (that only stored start and ending for auras) that the memory consumption would be limited to the number of spells a player has access to as each time you cast another of the same spell it simply overwrites the old data. Or is that not a good assumption to make (as I said, I don't have a lot of programming experience).

    To keep the memory consumption to a minimum, you could add a new spell info tag called something like "trackdurationafterexpire" (or maybe something shorter) and that way the script maker could enable it only for those abilities that matter (which in my case at the moment is 4 potential trinket buffs and Tiger's Fury).

  • Avatar of jlam jlam Jul 24, 2013 at 19:20 UTC - 0 likes

    Yes, the problem here is memory consumption. I believe the existing table management is sufficient to allow the change you're proposing, but I need to review the code more stringently to determine if there are potential memory leaks. At the very least, I need to add garbage collection of tables associated with auras on friendly/neutral targets before going down the route you've proposed.

    Ovale used to have a lot of problems with memory usage, and it took a lot of work to fix that problem, so I'm sensitive to changes that may cause memory leaks to recur.



Last updated
May 08, 2014
Jul 24, 2013
Fixed - Developer made requested changes. QA should verify.
Enhancement - A change which is intended to better the project in some way
Medium - Normal priority.

Reported by

Possible assignees