WeakAura Classic Auren mit Modifier verstecken?

Huhu an alle die sich mit Lua auskennen :slight_smile: ,

ich habe ein sehr spezielles Interface für mich zusammen gebaut, da ich auf einem etwas kleinen Notebook spiele und übersicht halt nunmal alles ist beim tanken :shield:.

Ich benutze sehr viel Makros mit “ALT” als Modifier, also das sich dann auch die jeweiligen Symbole und Tooltips ändern. Jetzt möchte ich mir mit Weakaura die jeweils andere Fähigkeit, aus dem Makro als Symbol mit CD anzeigen lassen.
Das Habe ich auch alles hinbekommen, also CD Anzeige, nur wenn ich im Kampf bin und nur mit einem Ziel. Funktioniert alles Sehr gut! :relieved:

SOOO… nur mal zum eigentlichen Problem :laughing:
Ich möchte, Weakaura so einstellen, dass die Auren ausgeblendet werden, solange ich “ALT” drücke!
Oder anders gesagt, Auren sollen nur dann angezeigt werden, wenn “Alt” NICHT gedrückt wird.
Ich suche schon seid Tagen eine Lösung dafür, komme aber leider nicht weiter.
Ich habe bei Wago . io “h t t p s://wago.io/HD5kmQuR3” eine Aura gefunden, wo mit den Modifiern, die Namen & Castbars der Mobs ausgeblendet wird, die gerade nicht Casten!
Also vom Prinzip genau dass, was ich brauche!
Leider wird die Funktion über einen LUA Code veranlasst, was ich nicht kapiere :frowning_face:!!!
Ich habe auch noch älter Weakaura LUA Scripte gefunden, wo mit “ALT” die Anzeige umgeschalten wird, also die Anzeige an- & abgeschaltet wird.
Was ich 1.stens nicht repliziert bekomme und 2.tens auch nicht dass ist, was ich brauche!

Also, falls jmd so lieb ist und eine Lösung für mein Dilemma hat, ich bin für jede Hilfe dankbar. :blush:

Kann grad nicht ingame schauen, aber gibt es dafür nicht einen Weg, ohne über LUA tippen zu müssen? Wie z. B. bei der folgenden Aura und dem ersten Bild zu sehen?

https://wago.io/4N7vVthan

Nein, ein direkt implementierter Auslöser für Modifier existiert in WeakAuras leider nicht.

Das lässt sich ausschließlich über eigenen LUA-Code umsetzen, was auch in der von dir verlinkten WeakAura der Fall ist.
Diese nutzt aber die relativ neue Implementierung von “Custom Options”, über die man als Autor einer Aura eigene Optionen erstellen und als komfortables Menü anzeigen lassen kann. Die genaue Funktionalität dieser Optionen muss aber trotzdem selbst in LUA programmiert werden - was ja wieder das Problem ist.


Auch wenn das mit eigenem LUA-Code auf den ersten Blick sehr kompliziert aussieht, so lässt sich das gewünschte Verhalten doch sehr einfach umsetzen, indem man die Auren einfach ganz normal erstellt und dann einen weiteren Auslöser hinzufügt, der per eigenem LUA-Code den Modifier abfragt. Dann einfach ganz oben einstellen, dass alle Auslöser zutreffen müssen und das sollte schon funktionieren.

Die Einstellungen dieses Auslösers wären dann bspw. so.:

  • Typ: Benutzerdefiniert
  • Ereignistyp: Ereignis
  • Ereignis: MODIFIER_STATE_CHANGED
  • Benutzerdefinierter Auslöser: function() return not IsAltKeyDown() end
  • Benutzerdefinierter Umkehrauslöser: function() return IsAltKeyDown() end

Um einen anderen Modifier anzusprechen, muss dann einfach die entsprechende Funktion (hier IsAltKeyDown()) angepasst werden. Weitere mögliche Funktionen dafür wären IsShiftKeyDown() für Umschalt und IsControlKeyDown() für Strg.


Als etwas weitergehende Erklärung:

  • Die genannten Funktionen liefern entweder “wahr” (“true”) oder “falsch” (“false”) zurück, je nachdem, ob der entsprechende Modifier gedrückt ist.
  • Der Befehl return sorgt dann dafür, dass der entsprechende Wert an den Auslöser zurückgegeben wird und dieser darauf reagieren kann.
  • Mit dem Befehl not kann man die Ausgabe umkehren, d.h. aus “wahr” wird “falsch” und umgekehrt.

Der Befehl return not IsAltKeyDown() sorgt also dafür, dass abgefragt wird, ob die Alt-Taste gedrückt ist und gibt danach das Gegenteil davon an den Auslöser zurück. Da diese Abfrage im benutzerdefinierten Auslöser steht, trifft dieser zu, wenn die Taste nicht gedrückt wird - als dem “falsch” wird durch not ein “wahr” und die Aura kann angezeigt werden.

Bei return IsAltKeyDown() ist kein not dabei, d.h. es wird einfach direkt der Wert der Abfrage zurückgegeben. Diese steht im “Umkehrauslöser”, d.h. ist dafür zuständig, wann die Aura ausgeblendet wird - ist die Taste gedrückt, so trifft die Abfrage zu und die Aura wird ausgeblendet.


EDIT: Idiotischen Status auf korrektes Event korrigiert, siehe Shinizus Kommentar.

5 Likes

Chrisey… DU BIST EINFACH NUR GÖTTLICH :fairy::woman_mage::fairy:

Ich danke dir vielmals. :kiss:

Dass ist genau dass, was ich gesucht habe !!!

Korrekt:

  • Typ: Benutzerdefiniert
  • Ereignistyp: Ereignis
  • Ereignis: MODIFIER_STATE_CHANGED
1 Like

Welp, ich wusste doch, dass ich dabei irgendwo etwas übersehen hatte und überhaupt nicht nachgeschaut habe, ob es dafür ein spezifisches Event gibt…

Ist im obigen Post ausgebessert, danke für den Hinweis! :star_struck:

1 Like

Huhu Ihr Lieben LUA-Göttinen :kissing_heart:, die mir so unglaublich weitergeholfen haben :fairy:‍♀,

Aber die Korrektur, die Shinizu, vorgeschlagen hat, hatte leider nicht den Effekt, den ich, mit der vermeintlich falschen Lösung hatte🤷‍♀️!!!

Vllt habe ich es aber auch falsch richtig gemacht :stuck_out_tongue_winking_eye:. Wenn ich raten müßte, könnte es vllt daran liegen, daß ich ALT, ja als Modifier in meinen Makros nutze.

Jedenfalls wird mir mit der Korrektur, egal ob ich mit oder ohne “not” im Code, immer die Aura angezeigt.

Erst als ich wieder geändert habe, ging alles perfekt!:+1:! :+1:! :+1:

Vllt wiederholen Andere meinen Fehler, deshalb wäre es vllt besser beide “Lösungen” darzulegen!

Jedenfalls nochmal vielen lieben :sparkling_heart: Dank für eure schnelle Hilfe.

Das Problem dürfte wahrscheinlich sein, dass WeakAuras durch die Umstellung auf ein Ereignis als Auslösertyp das Verbergen von “Benutzerdefiniert” auf “Zeitgesteuert” ändert. Dadurch soll die Aura nach einer gewissen Zeit ausgeblendet werden, was aber ja nicht dem entspricht, was du haben willst und ohne entsprechende Zeitangabe ja auch nicht funktioniert.

Du müsstest also darauf achten, dass das dann ebenfalls korrekt eingestellt ist, d.h.:

  • Verbergen: Benutzerdefiniert
  • Benutzerdefinierter Umkehrauslöser: function() return IsAltKeyDown() end

Ansonsten könnte man das mit dem Ereignis als Auslöser aber noch etwas optimieren, da man dann die spezifische Abfrage des Modifiers nicht benötigt - das Ereignis gibt direkt zurück, welcher Modifier dieses ausgelöst hat:

Benutzerdefinierter Auslöser:

function(event, key, state)
    if state == 1 and (key == "LALT" or key == "RALT")  then
        return true
    end
end

Benutzerdefinierter Umkehrauslöser:

function(event, key, state)
    if state == 0 and (key == "LALT" or key == "RALT")  then
        return true
    end
end

Der Unterschied zwischen den beiden Code-Blöcken ist dann nur die Abfrage des Rückgabewertes state, der eine 1 zurückgibt, wenn die Taste gedrückt wurde und eine 0, wenn diese losgelassen wurde.


Der Nachteil an meiner Lösung im ersten Post oben ist, dass die Aura damit bei jedem einzelnen Bild abfragt, ob die Taste gedrückt hast. Bei 60 FPS wäre das also 60 mal pro Sekunde, was natürlich absolut ineffizient ist und Unmengen an Ressourcen sinnlos verbraucht. Das mag bei einer einzigen Aura jetzt nicht dramatisch aussehen, aber es kann sich sehr schnell summieren und dann Performanceprobleme verursachen.

Mit dem Ereignis als Auslöser reagiert die Aura wirklich nur genau auf den Druck bzw. das Loslassen der Taste, wodurch das also immer nur genau dann abgefragt wird, wenn auch wirklich genau diese Taste genutzt wurde.

1 Like

Wenn dann Götter/Göttinnen, because last time I checked:grin:

Der Code ist im Fall von WA sinnvoller als die Nutzung der Event-Argumente, da beim Druck anderer Modifikatoren die Auslöser-Funktion ebenfalls aufgerufen wird und bei einem undefinierten Zustand die Aura unerwünschter Weise aus-/eingeblendet werden könnte.

Außerdem ist die Funktion so lesbarer & simpler zu verstehen.

Guter Punkt, aber sollte das nicht dadurch kompensiert werden, dass direkt die beiden Modifier in der if-Abfrage mit verglichen werden?
Und auch wenn das wahrscheinlich schon weit über das eigentliche Thema hier hinausgeht, inwiefern müsste man denn rein theoretisch noch irgendeine andere Abfrage hinzufügen, um das zu garantieren?

Wenn wir schon weiter oben bei der Effizienz waren und das meine genauen Kenntnisse noch ein wenig übersteigt: Welche Version (IsAltKeyDown() vs. if-Abfrage) wäre denn in Bezug auf die benötigte Rechenleistung sinnvoller?
Ich bin mir ja sicher, dass der Unterschied dabei praktisch irrelevant ist, aber geht da ja auch irgendwo dann ums Prinzip.

Die Lesbarkeit ist aber auf jeden Fall ein gutes Argument, gerade wenn es darum geht, dass die Auren von Spielern verstanden werden, die sich mit der Materie nicht so gut auskennen.


Dann verkürzen wir das Ganze doch ebenfalls auf Götter, denn… siehe Shinizus Aussage. :grin:

Wobei ich mich eher weniger in diese Kategorie einsortieren würde, ganz so gut kenne ich mich damit dann doch wieder nicht aus. :rofl:

Du musst einfach nur sicherstellen, dass der nil-return deiner Funktion (also wenn deine if-Bedingung/en nicht erfüllt ist) nicht die Aura unerwünschter Weise ein-/ausblendet.

z.B.: Was passiert, wenn statt ALT shift gedrückt wird?
Wird die Aura dann umgeschalten?

Der Funktionsaufruf oder 3 Vergleiche dürfte sich quasi nichts nehmen.

Zumal hier bei der geringen Häufigkeit des Aufrufs und des simplen Codes nahezu keinerlei CPU-Belastung entsteht.

Man kann Dinge auch unnötig bis kaputt optimieren. :wink:

Wenn ich nicht komplett auf dem Schlauch stehe, sollte dann überhaupt nichts passieren, da in der if-Abfrage ja direkt die beiden Alt-Tasten (LALT und RALT) abgefragt werden und es keinerlei andere Aktionen (bspw. durch elseif, else oder weiteren Code) gibt.

Die Aura wird ja nur angezeigt, wenn die Taste gedrückt wird (state == 1) und eine der beiden Alt-Tasten (key == "LALT" or key == "RALT") der Auslöser ist. Alle anderen Situationen sind nirgends definiert und sollten daher auch keine Auswirkung haben, außer es gibt hierbei noch irgendwelche Details von WeakAuras, die mir nicht bekannt sind.

Okay, das ist doch schon mal eine gute Information - wobei es mir da auch eher etwas um den prinzipiellen Unterschied zwischen LUA-eigenen Konstrukten und von Blizzard implementierten Funktionen ging.

Dass das im hier genannten Fall eine unnötige Optimierung ist, ist natürlich auch selbstverständlich. So oft kann man die Taste ja gar nicht drücken und wieder los lassen, als dass bei dem einen Funktionsaufruf etwas passieren „sollte“.

Performance-Optimierungen sind halt allgemein noch ein Punkt, mit dem ich mich mit meinen selbst angeeigneten Programmierkenntnissen noch schwer tue - daher dann auch meine nachfrage, wenn es hier im Thema schon um diese Problematik ging (*hust* „Bei jedem OnUpdate“ *hust*). :wink:

Dieses Thema wurde automatisch 180 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.