Load: In Combat OR Target Attackable OR Mouseover Attackable
Beaker567 opened this issue ยท 7 comments
Is your feature request related to a problem? Please describe.
I want a lot of my WAs to show pre-pull, in addition to when in combat.
I currently make this happen with a bunch of extra code and trigger manipulation (read below if you wanna see what a masochist I am).
Describe the solution you'd like
It'd be way easier if the Load tab included these options appended to In Combat, something like this:
[ ] In Combat
--- [ ] OR Target Attackable
--- [ ] OR Mouseover Attackable
or like this:
[ ] In Combat
[ ] In Combat OR Target/Mouseover Attackable
Not everyone is gonna want this, but thought I'd make this request cuz I'm probably not the only one either?
Describe alternatives you've considered My home-baked solution, which I'd love to get rid of:
I made a WA that creates a global and an event, then I add a trigger to every WA that checks these, and AND that trigger to each WA's 'required to activate'.
`
-- my custom load conditions (so we can show WAs before entering combat)
local canAttackMO = UnitCanAttack('player','mouseover')
local canAttackTAR = UnitCanAttack('player','target')
local myLoad = InCombatLockdown() or canAttackTAR or canAttackMO
local gMyLoad = WA_BKR_LOAD or false -- get value from the global
-- store current attackable unit in a global
WA_BKR_UNITATTACK = (canAttackMO and "mouseover")
or (canAttackTAR and "target") or "none"
local myLoadChanged = (not myLoad and gMyLoad) or (myLoad and not gMyLoad)
if myLoadChanged then -- load conditions have changed, so fire event
WA_BKR_LOAD = myLoad -- update global
WeakAuras.ScanEvents("WA_BKR_LOAD_CHANGED") -- fire event
end
-- global for gcd duration, used in custom duration calcs for many of my WAs
-- from: https://github.com/WeakAuras/WeakAuras2/wiki/Useful-Snippets
WA_BKR_GCD = UnitPowerType("player") == 3
and (WA_GetUnitBuff("player",13750) and .8 or 1)
or max(1.5/(1 + .01 * UnitSpellHaste("player")),
WA_GetUnitBuff("player", 194249) and .67 or .75)
return ""
`
Additional context
-
I'm sure my solution sucks, and in hindsight not sure I'd do it again. But now that I have it, I don't want to 'not have it', if that makes sense.
-
Also seems like this would be relatively easy to implement? Maybe a lot of people would use it if it was available?
Thanks for considering this!
I don't understand how the above comment relates to my request.
-
What does this have to do with UI scale?
-
The 'recommendation' is to use default triggers? I can't imagine it would be good idea computationally, for each of my WAs to individually check, every frame, if both the target and mouseover are attackable? Just seems MUCH more reasonable to put these checks in the Load section.
Sorry if I'm just missing something here...
That UI you proposed would solve your problem, but there are a pratical infinite amount of combinations that people would want. And accomedating that with such a UI design wouldn't work.
Yes using triggers for that is fine. Making it a load option doesn't make checking that any cheaper at all.
Well, that's certainly not a UI that would scale at all. We recommend using default triggers for that. And eventually solving #1236 would make this easier to do.
Can't argue with that, makes perfect sense. Thanks to you both for the dialogue <3
I'm posting here in case anyone else is following this, some improvements I made to my implementation:
-
Removed the extra trigger from my all my WAs, that I was adding just to check for WA_BKR_LOAD, and instead just put that in my activation code. So what was:
return (t[1] or t[2] or t[3]) and t[4]
is now
return (t[1] or t[2] or t[3]) and WA_BKR_LOAD
This also means I could get rid of my custom event and associated code. -
Improved some logic to minimize the number of UnitCanAttack calls.
Revised code looks like:
-- my custom load conditions (so we can show WAs before entering combat)
local boolCanAttackTarget = false
local boolCanAttackMouseover = false
local boolMyLoad = false
-- this weird if-then structure is used to minimize UnitCanAttack calls
if InCombatLockdown() then
-- vast majority of time, this is what sets boolMyLoad true
boolMyLoad = true
else
-- if not in combat, then let's check if we might enter combat soon
-- no UnitCanAttack calls if we're already in combat
boolCanAttackMouseover = UnitCanAttack('player','mouseover')
boolCanAttackTarget = UnitCanAttack('player','target')
boolMyLoad = boolCanAttackTarget or boolCanAttackMouseover
end
WA_BKR_LOAD = boolMyLoad -- update global
-- store current attackable unit in a global
-- revisit if this is even needed, since won't be avail when in combat
-- preference for mouseover, since that's how I'm using mouseover macros
WA_BKR_UNITATTACK = (boolCanAttackMouseover and "mouseover") or
(boolCanAttackTarget and "target") or "none"
-- global for gcd duration, used in custom duration calcs for many of my WAs
-- from: https://github.com/WeakAuras/WeakAuras2/wiki/Useful-Snippets
WA_BKR_GCD = UnitPowerType("player") == 3
and (WA_GetUnitBuff("player",13750) and .8 or 1)
or max(1.5/(1 + .01 * UnitSpellHaste("player")),
WA_GetUnitBuff("player", 194249) and .67 or .75)
return ""
Ah I see what you meant by 'scale' now.
Though IMO, what I'm proposing is a fairly typical 'need' of players. That is, WAs they'd want visible in combat, they likely would want to see pre-pull (cooldowns are off, especially), if there's a way to determine when we might start combat soon.
Checking if the target or mouseover is attackable, is a reasonable way to detect 'pre-pull'. Adding all the other possible combinations of 'Load checks' (your 'infinite amount of combinations'), are not things people would want.
Am I in combat, or about to be in combat - that's all I'm looking for, without all the code/trigger hoops I'm currently hopping through.
If we only implemented what people have specifically asked for, then WeakAuras wouldn't be nearly as powerful as it is today. We cast as wide a net on possible use cases as we can for each additional feature, in the hopes of minimizing bloat, and maximizing utility.
For this case in particular, we have been over the course of the past few years evolving WeakAuras to be more flexible in a way that also will be able to solve your usecase neatly. Since you can already write triggers to produce the behavior you desire, there doesn't seem to be any pressing need to add in a special case that we would then have to maintain for potentially a long time, and which would conflict with the design that we are developing towards.
a hopefully-final update:
well...looks like my fix didn't work :(
It appears that the activation code doesn't fire unless an event associated with the triggers fires (auras aren't showing/hiding when WA_BKR_LOAD changes). This makes sense of course, though I was hoping the activation code fired every frame, for my solution to work.
So, I've got to revert back to having the extra trigger in all my WAs, and my custom event to fire them - bummer.
activation custom function, for most of my WAs:
function(t)
return (t[1] or t[2] or t[3]) and t[4]
end
where trigger 4 is: Custom > Status > Event(s) > WA_BKR_LOAD_CHANGED
function()
return WA_BKR_LOAD
end
and the text WA customtext that runs every frame is:
-- my custom load conditions (so we can show WAs before entering combat)
local boolMyLoad = InCombatLockdown() or UnitCanAttack('player','target') or
UnitCanAttack('player','mouseover')
local gMyLoad = WA_BKR_LOAD or false -- get value from the global
local myLoadChanged = (not boolMyLoad and gMyLoad) or
(boolMyLoad and not gMyLoad)
if myLoadChanged then -- load conditions have changed, so fire event
WA_BKR_LOAD = boolMyLoad -- update global
WeakAuras.ScanEvents("WA_BKR_LOAD_CHANGED") -- fire event
end
-- global for gcd duration, used in custom duration calcs for many of my WAs
-- from: https://github.com/WeakAuras/WeakAuras2/wiki/Useful-Snippets
WA_BKR_GCD = UnitPowerType("player") == 3
and (WA_GetUnitBuff("player",13750) and .8 or 1)
or max(1.5/(1 + .01 * UnitSpellHaste("player")),
WA_GetUnitBuff("player", 194249) and .67 or .75)
return ""