"Spell Usable" condition does not consider debuffs that increase power cost

[ValokAsura]

What version of TellMeWhen are you using? 9.0.2

What steps will reproduce the problem?

1. Create a conditional icon
2. Set the only condition for the icon's success to: Spell Usable: Rampage (or any spell that costs a flat value that might be a high percentage of your power)
3. Get a debuff or stack of debuffs that increases the power cost of your spells to be beyond what is possible to cast. In my example, the "Hysteria" debuff stacks increased the cost of Rampage to 128.
4. The condition will show Rampage as being usable, even though it is not, because I cap at 100 Rage.

What do you expect to happen? What happens instead? I expect the "Spell Usable" condition to return false, since it is impossible to cast a 128 Rage spell when my maximum rage is 100. Instead, the condition returns true, even though the spell is not usable.

Screenshots and Export Strings https://prnt.sc/vpzv3n

This export is only a small example of the issue and is what you get when following the steps mentioned above. The problem affects all of my other conditions that should become unusable due to an unattainable power cost.

^1^T^SGUID^STMW:group:1Vlf6nQ5kW04 ^SPoint^T ^Sy^F8392939474518016 ^f-44^SrelativePoint ^SBOTTOMLEFT^Sx ^F6501778937872384^f-43 ^t^SColumns^N1 ^SSortPriorities^T ^N1^T ^SMethod^Sshown ^SOrder^N-1 ^t^t^SLayoutDirection^N4 ^SName^SSpell~`Usable~`Problem~`Bar ^SIcons^T ^N1^T ^SType^Sconditionicon ^SConditions^T ^N1^T ^SType^SMANAUSABLE ^SName^SRampage ^t^Sn^N1 ^t^SCustomTex^SRampage ^SEnabled^B ^t^t^t^N90201^S~`~| ^Sgroup^N17 ^^

Other Thoughts Maybe there are a lot of if/thens I could integrate into each spell in order to workaround this issue, but it feels like it must be a bug or oversight, since "Spell Usable" is straight-forward and implies certain behavior.

Thank you for your time!

[ValokAsura]

Just a note: I wonder if it'll also consider buffs that make your spells cost less, or nothing at all. There is a Torghast buff that removes spell costs for 90 seconds. I suspect if it suffers the same problem, it'll say a spell isn't affordable when it is, since it costs 0. I'll test it when I get a chance.

[ascott18]

Unable to reproduce.

Gif is slowed 500%. Multi-shot is normally 40 focus, here you can see it debuffed to 53. I added colors to the condition passing/failing states on the icon to make it more clear, but you can see it changes instantly to conditions passing as I pass 53 focus.

[ValokAsura]

I'm on 9.0.3 now. It seems like it's working as expected in your example. I did another test and ended up with results similar to my original post, but slightly different/better.

https://prnt.sc/w7ysww

The icon on the left has a single Lua (Advanced) condition: UnitPower("Player") >= spellCost("Rampage")

the spellCost() function is something I put into the Lua Snippets to help me learn a little code. It isn't the proper way of getting spell costs for all classes, but it's only for testing. It contains the following:

function TMW.CNDT.Env.spellCost(spellName)
    local table = GetSpellPowerCost(spellName)

    if table == nil or table == {} then
        return 0
    else
        return table[1].cost
    end
end

The right icon has a single condition as well, the TMW option: Spell Usable, Rampage.

When Hysteria increased my Rampage cost to 101, only the icon on the left that uses my code switched from true to false. The one on the right still returned true. Interestingly, after a couple of seconds, the icon on the right eventually changed to false.

Here is an export of the two-icon group:

^1^T^SGUID^STMW:group:1VuXr9qmUx0W ^SStrata^STOOLTIP ^SScale^F4566153678553088 ^f-51^SPoint ^T^Sy^F-7099519302325200 ^f-46^Sx ^F-7393677790877519^f-55 ^t^SEnabledSpecs^T ^N73^b ^N71^b ^t^SColumns^N2 ^SLayoutDirection^N2 ^SName^SRampage~`Re-Test ^SSettingsPerView^T ^Sicon^T ^STextLayout^Sbar1 ^t^t^SIcons^T ^N1^T ^SType^Sconditionicon ^SConditions^T ^N1^T ^SType^SMANAUSABLE ^SName^SRampage ^t^Sn^N1 ^t^SEnabled^B ^SCustomTex^SRampage ^SStates^T ^N2^T ^SColor^Sffffffffd ^SAlpha^N1 ^t^t^t^N2^T ^SType^Sconditionicon ^SConditions^T ^N1^T ^SType^SLUA ^SName^SUnitPower("Player")~`>=~`spellCost("Rampage") ^t^Sn^N1 ^t^SCustomTex^SRampage ^SStates^T ^N2^T ^SColor^Sffffffffd ^SAlpha^N1 ^t^t^SEnabled^B ^t^t^SConditions^T ^N1^T ^SType^SEXISTS ^SUnit^Starget ^SPrtsBefore^N1 ^t^N2^T ^SType^SALIVE ^SUnit^Starget ^t^N3^T ^SType^SREACT ^SPrtsAfter^N1 ^SUnit^Starget ^SLevel^N1 ^t^N4^T ^SType^SCOMBAT ^SAndOr^SOR ^t^Sn^N4 ^t^t^N90301^S~`~| ^Sgroup^N24 ^^

A second test gave results as you got. It seems I have a problem only when I'm already at 100 rage, and then the spell cost increases to be too high. If I have enough debuffs to make it cost > 100 rage, and THEN I build my rage up to 100, it stays false as expected. I'm not sure if this is worth worrying about, or how often this could be a problem. I just wanted to let you know in-case it was a bug or something.

Thank you for responding, and sorry for the delay. I didn't realize there was an update until today. Thanks again for this terrific addon!

[ascott18]

If this is a bug, its a bug in Blizzard's API. I won't switch TMW to use GetSpellPowerCost because GetSpellPowerCost incurs a minimum of two table allocations per call. TMW has a function, TMW.GetSpellCost(spell), which uses GetSpellPowerCost that TMW uses in some cases where the actual cost must be known (power bar overlays and the actual Spell Cost condition), but whenever possible, IsSpellUsable is used instead because it doesn't churn any garbage.

Effects that change the power cost of abilities are quite unusual in the game, and outside of this specific example, and also never in my own personal experiences, the current methods used by TMW have never malfunctioned.