#Trigger State Updater + Unit Frames Usage

72 messages · Page 1 of 1 (latest)

cedar frigate
#

Originally posted in #the-war-within before noticing this area:

I'm trying to add a glow to all unit frames with Renew buff based on the example here: https://wago.io/WatchedTriggerExample.
Although this is trivial without custom code, the goal of this exercise is to master Trigger State Updater triggers.
I came up with the WA below, but it doesn't work... any hints would be really appreciated
https://wago.io/lk0AgdCAg

Wago.io

Wago.io is a database of sharable World of Warcraft addon elements

aMy watched trigger

Imported from WeakAuras Community Discord, #the-war-within by pallyhedron.

unborn ore
#

delete your other post then

#

👍

cedar frigate
#

I'm unable to delete the WA link that was generated by a bot, but the rest is cleaned up

#

the custom trigger I implemented appears to set proper variables and returns true, yet the condition that adds the glow to unit frames seems to be ignored

unborn ore
#

find the error

#

you set inRange to the name of the aura, but check if it's true instead

#

while it's "truthy" that way, it simply doesn't work like this for conditions

#

adjusting it to this:

image.png
#

shows the glow just fine

image.png
#

since it's actually true then

cedar frigate
#

ahh, this is what I get for being mainly a Java/JS developer... glad it's just a Lua quirk

#

tyvm

#

glow appears, but doesn't deactivate once the buff drops off... trying to debug

unborn ore
#

you need to tell it to turn it off

#

with glow external element -> hide in your case

#

external glows need to be turned off

cedar frigate
#

tried an extra condition, but it didn't work:

image.png
#

might be a logic issue in the trigger... perhaps I'm never returning false

#

need to step away, but will try to investigate during the next hour

unborn ore
#

here's your example with these changes

#

works

cedar frigate
#

is this Trigger State Updater pattern pretty much the state of the art when you need to update some elements (unit frames, nameplates, etc.) out of a group?

#

seems a bit clunky to put dummy icons inside of unit frames just to track parents and then combine a TSU trigger with a Smart Group trigger... maybe there's a cleaner way?

unborn ore
#

seems a bit clunky to put dummy icons inside of unit frames
the icons don't even need to be "present". you can make them invisible, or 1px wide. or just make a text aura and remove all the text

#

to react to events in any kinda of way in WoW you will always need to create frames

#

every single addon does the same thing

#

maybe there's a cleaner way?
I mean, you yourself said how you're aware that this is needlessly complicated no?

#

first of all this thing doesn't even need code, and even if it did: like this would not be the way

#

If you need code, a TSU is always the most "powerful" and versatile choice you're gonna have.

#

But what you do with it can still be garbage obviously, depends on how you use the tool ye

cedar frigate
#

ty, I got it working with an empty text string, so that's an improvement

#

I was indeed looking for a powerful pattern, rather than a simple solution to the specific "Renew" exercise. I imagine it might be hard to improve on, given that the template came from asakawa, who is cited in WA documentation and is one of the mods here. 😄

#

thanks again, I still have much to learn 🙂

unborn ore
#

it's made for a completely different use case

cedar frigate
#

right, the template is for doing a range check on a collection of nameplates, and my understanding is that TSU might very well be necessary there

#

I know I don't need code at all for my "Renew" example, but I'm thinking ahead to more complex things that I intend to do with unit frames in the future, which should require TSU

unborn ore
#

range check
and that's the only reason why it's making use of FRAME_UPDATE
in 99.9% of cases you'd never need that and it's an incredibly bad solution

but yeah if it's purely for looking at TSU or watched triggers then it's whatever. just a very weird example you decided on

#

usually the best examples/learning opportunities happen when you run into a situation that you actually can't solve witht the default options anymore

cedar frigate
#

here's a much better example... I used the same technique to solve a different problem

#

would appreciate a critique of this WA

#

please lmk if there better way to implement this

#

it's obviously not polished, since I left debugging statements and hard-coded some spell names... I'm just wondering if the overall approach can be improved

#

ugh, performance is unimpressive:

#

it's my slowest WA by a fair margin, and I have tons of them

unborn ore
#

what's the use case? glow the lowest HP unit frame, unless you got no range on them?

#

that's pretty much that^ just that I exclude 100% hp units

#

should be more or less the same deal as yours though, just that this one relies on WAs health trigger
so yeah it's kinda whatever in this case. every frame checks are always gonna be rough on performance
and watching a health trigger for the entire group like I do is also very expensive

cedar frigate
#

I wonder if this will remain true in a raid, where more health events should be fired

#

have to experiment 🙂

#

just for kicks, I wrote a standalone add-on years ago that does the same thing and runs on every frame with throttling, yet takes up a fraction of CPU time of the WA version

#

...so there appears to be significant overhead for using the WA framework

unborn ore
# cedar frigate ...so there appears to be significant overhead for using the WA framework

That depends on how you look at it I'd say.

You could also say that there's significant overhead for not using the WA framework. Because that's what you're doing here.
The purely default features that 99.9% of users come into contact with are perfectly performant.

Once you move out of that and into custom code, you gotta be aware that all of WAs custom code blocks get xpcalled. The performance impact of that is absolutely negligible in most cases, but especially if you run your stuff very often like with FRAME_UPDATE here it's getting more and more "problematic". Your (or any) Addon doesn't do that, so it's bound to perform better in those circumstances if everything else is equal.

But even within custom code solutions: you already noticed a difference.
I watch a Health Trigger, which means I only update when necessary and all the API calls are handles by WA, while you just do that in an every frame Check (which is obviously less accurate, but that aside), and my version performs a bit better.
Usually, relying more on WAs native features rather than solving the same thing with custom code is more performant.

cedar frigate
#

in other words, my WA (frame update) < your WA (health trigger) << standalone add-on (frame update) in terms of performance

#

the add-on uses an "OnUpdate" script vs. FRAME_UPDATE script, but unless I'm mistaken, they're equivalent

#

I tweaked all 3 implementations to throttle (30 times/sec), so no differences there

unborn ore
#

yes. read what I wrote

cedar frigate
unborn ore
#

I have no clue if that's solely it, but it is one objective performance factor that's just there for any WA using custom code vs. doing the same thing outside of WA.

unborn ore
#

E.g. a very simplified example

     -- some random math and table operations
     local num = math.random(1, 1000)
     local is_even = (num % 2 == 0)
     
     local result = 0
     for i = 1, 10 do
          result = result + math.sqrt(num * i) / i
     end
     
     local tbl = {}
     for i = 1, 10 do
          tbl[i] = math.random(1, 100)
     end
     table.sort(tbl, function(a, b) return a < b end)
     
     local sum = 0
     for _, v in ipairs(tbl) do
          sum = sum + v
     end
     
     return sum
end

local start = os.clock()
for i = 1, 18000 do
  xpcall(f, function() end)
end
local xpcallTime = os.clock() - start

start = os.clock()
for i = 1, 18000 do
  f()
end
local directCallTime = os.clock() - start

print("xpcall: ", xpcallTime)
print("directCall: ", directCallTime)
print("xpcall/directCall: ", xpcallTime/directCallTime)

Leaves me with:

xpcall: 0.080209
directCall: 0.078167
xpcall/directCall 1.0261235559763