Are self-modifying WAs no longer possible with the change to GetData?

[dense cypress]

My use case was that I wanted aura-local custom events that would only fire for one WA even if the WA is duplicated. The way I accomplished this was to self-modify the trigger events string to rename colliding event names. Seems that this change breaks this: https://github.com/WeakAuras/WeakAuras2/commit/f65f05ed6055ed72457e03e471bf6e24bcd8e40c

Is there a way to have custom events that remain aura-local without needing to manually rename the event when duplicating the aura? I could add an argument with the aura id and filter on that, but I would rather avoid unwanted cross-firing of the trigger at all, for performance reasons.

[dense cypress]

Just took another look into the source - is WeakAuras.ScanEventsInternal the intended API for this use case?

[maiden bronze]

Just scanevents, not internal

And just use the first argument as the aura id

Self modifying is far worse than a simple check on the first argument

[dense cypress]

Sure that would definitely be the simplest solution. Ideally I would like to avoid cross firing to avoid the performance overhead of activating triggers though. If I have N auras all using the same event name with similar fire rates then this overhead will scale O(N^2).

[rugged knot]

if you filter by aura_env.id how would this affect performance at all

unless you return true no matter what

[dense cypress]

It's been a while since I checked this but activating the aura environment and running the trigger func has a cost, I think on the order of hundreds of table accesses

It's why every frame WAs have a measurable overhead even if the trigger func does nothing on each frame

[maiden bronze]

No

If you have performance issues it's at a different place. I can imagine you are doing quite a bit of weird and questionable decision if you came to the conclusion that you need self modifying auras.
Even a single CLEU trigger is worse in that regard than whatever you can do with scanevents if you aren't making a infinite loop

[dense cypress]

Okay I'll just use what you suggested then to avoid any issues in the future

I didn't actually experience any performance issues yet, my main concern was that if I was going to commit to using a single event for my WAs, I wanted to avoid the possibility of performance issues down the line when I'm using a lot of WAs I've written this way

[cursive spoke]

Do not write code that use same event

[maiden bronze]

Often people building very complicated stuff are over complicating while simple triggers could accomplish the same

[maiden bronze]

can you post an example aura of your building and explain what it does and why?

[dense cypress]

my main motivation behind this has been to have a framework where my WAs can (1) update their own trigger state based off timers, and/or (2) update their trigger state every X seconds. I would like to use the event names ARC_TIMED and ARC_PERIODIC respectively, and have that be consistent across all my WAs, instead of having to come up with an arbitrary unique name for each one.

Example that uses ARC_TIMED: https://wago.io/hurF0-Rb4 I wanted WAs that display charge cooldowns in the same way as Blizz action bars (special display for spells with 1+ charges available but still recharging; charge cooldown recognized properly by OmniCC). I need a timed trigger since SPELL_UPDATE_COOLDOWN doesn't reliably fire when the cooldown finishes (WeakAuras itself does the same thing in GenericTrigger.lua).

Example using ARC_PERIODIC: stuff like frame rate, latency, player movespeed, etc. that don't have a WoW API event for updates. Latency: https://wago.io/qhobRGmcK Movespeed: https://wago.io/FAjuOa7B9

also I'm curious, is there a good way for WAs to save persistent state now that writing to WeakAurasSaved is bricked? e.g. saving a timestamp in order to display a message once a day

[maiden bronze]

aura_env.saved

[dense cypress]

oh nice

thanks

[cursive spoke]

so you have pseudo recursion event

and you think that edit event is better?

[dense cypress]

I don't know what you mean by that

[cursive spoke]

function aura_env:InitArcEvents(interval, tolerance)
    local a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,A,B,C,D,E,F=WeakAuras,C_Timer.After,random,ipairs,pairs,self,{},{},"ArcEventIDs","arcEventID","arcEventNormal","events",{},"ARC_PERIODIC","ARC_TIMED",{},interval,tolerance;for G in("ABCDEFGHIJKLMNOPQRSTUVWXYZ"):gmatch"."do tinsert(g,G)end;function u()for H=1,6 do h[H]=g[c(1,#g)]end;return table.concat(h)end;v=a.GetData(f.id)w=_G[i]or{}_G[i]=w;x=v[j]or u()z=w[x]if z and z~=v.uid then for I=1,99 do y=u()if w[y]==nil then x=y;break end end end;w[x]=v.uid;v[j]=x;f[j]=x;A=n.."_"..x;B=o.."_"..x;f[k]={[A]=n,[B]=o}for I,J in d(v.triggers)do J=J.trigger;if J and J.type=="custom"and J[l]and(J.check~="update"or J.custom_type=="event")then for K,L in e(f[k])do C,D=J[l]:gsub(L.."[%w_]*",K)if C~=J[l]then J[l]=C end;if D>0 then m[L]=true end end end end;t=a.ScanEvents;s=f.region;if m[n]and q then(s[n]or{}).c=1;r=r or min(1,q)/20;E=function()if p.c then return end;if a.IsPaused()then b(.2+.01*c(),E)else t(A)b(q+(2*c()-1)*r,E)end end;s[n]=p;b(q+(2*c()-1)*r,E)end;if m[o]then F=s[o]or{}s[o]=F;function f:SetArcTimed(M,N,O,P)local Q,R=F[M]or{c=0}F[M]=Q;if Q.t~=N then R=Q.c+1;Q.c=R;Q.t=N;if N==nil then return end;b(max(0,N-GetTime()),function()if Q.c==R then t(B,M,O,P)end end)end end end
end

if i read it correctly ARC_TIMED_LMIKCP event call the trigger

and trigger call ARC_TIMED_LMIKCP again

after some time

[dense cypress]

yeah sorry I have the unminified version if you want (although it's also ugly, it was written to be minified)

[cursive spoke]

esp with Spell Charges Template

[dense cypress]

only ARC_PERIODIC is on a recursive timer like that. ARC_TIMED is a one-time thing