Sku v43.9 - Patchnotes

Ueberblick

Neu

Aenderungen

Fehlerbehebungen

Quest-Menue: "Route" findet Kreaturen mit Bindestrich im Namen

Einfach: Im Quest-Menue (Annahme, Ziel, Abgabe) bietet eine Kreatur "Route", "Nahe Route" und "Wegpunkt". "Route" sagte "Liste leer", sobald der Name der Kreatur einen Bindestrich, eine Klammer oder ein aehnliches Zeichen enthielt, auch wenn die Kreatur gut an das Wegenetz angebunden ist. Im deutschen Client betraf das 249 Kreaturen, darunter alle drei Affenarten im Krater von Un'Goro. "Nahe Route" und "Wegpunkt" waren nicht betroffen.

Technisch: SkuQuest/Options.lua, CreateRtWpSubmenu, Zweig "Route": string.find(i, wpName) ohne plain-Argument las den Wegpunktnamen als Lua-Muster. Dort ist "-" ein Quantor ("o-" = beliebig viele o), der Name fand sich also nie selbst. Jetzt string.find(i, wpName, 1, true) an beiden Stellen. Die Routendaten im Krater waren in Ordnung (geprueft: Links, Spawn-Indizes und Anbindung an das Wegenetz).

Nahe Route: die zehn naechsten verbundenen Wegpunkte werden wirklich gefunden

Einfach: Die meisten Kreaturen sind nicht selbst an das Wegenetz angebunden. Fuer "Nahe Route" sucht Sku darum bis zu zehn verbundene Wegpunkte im Umkreis von 500 Metern um das Ziel und nimmt den besten erreichbaren davon. Diese Suche lieferte oft weniger als zehn. Der naechste Wegpunkt war aber immer dabei, und das Wegenetz ist fast ueberall zusammenhaengend. Das hat sehr wahrscheinlich nie jemanden getroffen; die Korrektur ist nur der Korrektheit wegen da. Sichtbar geworden waere der Fehler nur, wenn der naechste Wegpunkt auf einem abgetrennten Stueck des Wegenetzes liegt: dann "Liste leer" oder ein kleiner Umweg.

Technisch: SkuNav:GetNearestWpsWithLinksToWp (SkuNav/Core.lua). Das sortierte Einfuegen kannte keinen Anhaenge-Fall: ein Kandidat, der weiter weg war als alle Eintraege, fiel weg, obwohl die Liste noch Platz hatte. Der erste Treffer von pairs() setzte damit die Obergrenze. Das Kuerzen bei mehr als N Eintraegen entfernte schon immer den entferntesten und bleibt. Offline gegen "die N naechsten" geprueft (20000 Zufallsfaelle): alt 9059 zu kurz, neu alle richtig. Alle fuenf Aufrufer werten die ganze Liste aus und nehmen den besten erreichbaren Eintrag, mehr Kandidaten koennen also nur gleich gute oder bessere Routen ergeben.

Auren: Basis-Auren haben die volle Ausgabeliste

Einfach: Unter "Neue aura", "Basis-Auren" hatte jede Vorlage einen Eintrag "Ton", in dem man genau einen Ton auswaehlen konnte, sonst nichts. Dieser Eintrag heisst jetzt "Ausgabe", mit der Anzahl der eingeschalteten Ausgaben dahinter, und oeffnet dieselbe Liste wie bei einer eigenen Aura: alle Toene und alle Datenausgaben, zum Beispiel Zaubername oder Zieleinheit. Jeder Eintrag ist ein Schalter, Enter schaltet ihn ein oder aus, und mehrere duerfen gleichzeitig an sein. Was die Vorlage bisher vorgab (ihr Ton, bei "Dein Buff auf Gruppenmitglied ausgelaufen" zusaetzlich Zaubername und Zieleinheit), ist beim Oeffnen schon eingeschaltet und laesst sich jetzt auch abschalten.

Technisch: SkuAuras/Options.lua. tBuildOutputsLevel nimmt einen optionalen Kontext (outputs, ownerLabel, tooltip); ohne ihn bearbeitet die Liste wie bisher den Entwurf des Aura-Baukastens, mit ihm die Liste des Basis-Formulars. Das Formular (tBaseForm) fuehrt statt eines einzelnen sound-Werts eine Liste outputs, vorbelegt aus defaultSound und defaultOutputs (vorher fixedOutputs, die beim Erstellen fest angehaengt wurden). Zusammenfassung und tBaseFormCommit lesen diese Liste; ist keine Ausgabe an, bleibt es bei "Keine Ausgabe festgelegt".

Auren: "Alle Auren loeschen" fragt nach

Einfach: "Alle Auren loeschen" im Auren-Menue hatte keine Unterebene: ein Enter oder Pfeil rechts, und alle Auren des Charakters waren weg. Jetzt fuehrt der Eintrag, wie beim Loeschen einer einzelnen Aura, auf "Wirklich loeschen?". Erst Enter dort loescht, Pfeil links bricht ab.

Technisch: SkuAuras/Options.lua, MenuBuilder: der Eintrag ist jetzt dynamic und legt per BuildChildren den einen Kindeintrag "Wirklich loeschen?" an. Beim Betreten zeigt selectTarget auf den Eintrag selbst, Enter auf dem Kind ruft dessen OnAction. Vorher dynamic = false ohne Kinder, OnPostSelect lief also direkt in den OnAction-Zweig.

Menue: Pfade werden aufgeloest statt durchlaufen

Einfach: Immer wenn Sku das Menue selbst an eine bestimmte Stelle setzt (ein Fenster geht auf, eine Schnelltaste wie Umschalt-F10, oder ein Fenster hat sich geaendert und sein Menue wird neu aufgebaut), lief es bisher den Pfad dorthin ab, als wuerde auf jeder Ebene Enter gedrueckt, und sagte jede Zwischenstation an. Beim leisen Neuaufbau eines Berufs- oder Lehrerfensters nach Herstellen oder Lernen hoerte man darum den Fensternamen ("Beruf", "Lehrer"), und der Cursor wurde nach Zeilennummer zurueckgesetzt, in einer Liste, die sich gerade veraendert hatte. Jetzt wird der Zielpfad direkt aufgeloest, ohne Ansage der Zwischenstationen, und der Cursor kehrt zu demselben Eintrag zurueck: dasselbe Rezept (auch mit neuer Anzahl), dieselbe Faehigkeit, derselbe Knopf. Nur wenn dieser Eintrag weg ist, wird angesagt, wo der Cursor gelandet ist.

Technisch: SkuOptions:ResolveMenuPath und EnsureLevelBuilt (SkuZOptions/Core.lua) ersetzen die Schleife in SlashFunc, die auf jedem Pfadsegment OnSelect(true) aufrief. Ebenen auf dem Weg werden nur gebaut (dynamic: RebuildNodeChildren, sonst einmal BuildChildren, wenn leer), nie selektiert; nur das Ziel bekommt sein OnSelect wie bisher (Vorbau bei leerer, nicht dynamischer Ebene, nie auf isSkuToggle). Damit entfallen die Nebenwirkungen des Durchlaufs: actionOnEnter-Knoten auf dem Weg wurden ausgeloest, alle Geschwister vor dem Treffer vorgebaut. Der aSilent-Parameter von SlashFunc wirkt jetzt. Die Wiederherstellung in SkuCore:CheckFrames macht einen stillen Aufruf statt zwei sprechender und setzt den Cursor direkt: skuIdentity, dann Name, dann die Zeile am alten Index (begrenzt auf die neue Laenge). Fenster-Eintraege tragen skuIdentity (SkuIterateGossipList kopiert es): Rezepte "recipe:Name (Rang)", Kategorien "cat:", Lehrer-Faehigkeiten "skill:", sonst "frame:<Frame>" fuer jeden Eintrag, der allein auf seinem Frame steht (SkuCore:PrepareWindowEntries am Ende der drei Builder). SkuCore:RefreshWindowMenuQuietly (LocalMenu.lua) ist der gemeinsame leise Neuaufbau fuer TRADE_SKILL_UPDATE/CRAFT_UPDATE und den Lehrer-Knopf; er spricht nur, wenn Identitaet (oder der Name ohne Anzahl) hinterher eine andere ist. Die Taschen behalten ihren eigenen Pfad (tFindMenuNodeByPath, tBagAnnounceSuppress).

Berufsfenster: Enter auf Rezept oder "Erstellen" sagte den Eintrag doppelt an

Einfach: Nach Enter auf einem Rezept oder einem Erstellen-Knopf wurde der Eintrag zweimal gesprochen. Jetzt einmal.

Technisch: Der klassische Klickpfad in SkuIterateGossipList rief nach func ein sprechendes CheckFrames und 0,35 s spaeter OnUpdate auf, zusaetzlich zur Ansage des Tastenhandlers. Die dritte Ansage fing meist die Dubletten-Sperre (1 s) ab, die zweite kam 0,9 s spaeter und nicht. Eintraege mit quietClick (gesetzt von PrepareWindowEntries fuer alle Klick-Knoepfe ohne containerFrameName) laufen jetzt ueber func plus RefreshWindowMenuQuietly; Knoepfe mit sicherem /click behalten den alten Pfad.

Briefkasten: "Ziel" vor "Neuer Brief"

Einfach: Beim Oeffnen eines Briefkastens wurde zuerst "Ziel" angesagt und dann erst "Neuer Brief". Jetzt nur noch "Neuer Brief".

Technisch: Mail:MAIL_SHOW oeffnete den Pfad "Lokal, Post", bevor der MailFrame sichtbar war; der Post-Eintrag unter Lokal existiert aber nur bei sichtbarem Frame. Der Pfad fand nichts, und das stille Oeffnen sagte ersatzweise den ersten Wurzeleintrag an ("Ziel", das Zielmenue); die Taschen holten das Menue kurz darauf ueber CheckFrames in die Post. Das Debug-Log zeigte "path walk found nothing ... short,lokal,post" bei jedem Briefkasten seit mindestens v43.6; aufgefallen ist es erst, als die Zwischenansagen weg waren. Jetzt oeffnet MAIL_SHOW einen Frame spaeter (C_Timer.After(0)), nur bei sichtbarem MailFrame und nur, wenn der Cursor nicht schon in der Post steht.

Tastenbelegung: zweite Taste fuer Monitor, Scan, Drehen und Co.

Einfach: Unter "Sku Tastenbelegung" hat jede Taste eine erste und eine zweite Belegung. Fuer eine Reihe von Tasten liess sich die zweite zwar setzen und wurde auch als "Taste 2" angesagt, tat aber nichts. Betroffen waren "Monitor Gruppe fortlaufende Ausgabe ausloesen", Zielentfernung, Panikmodus, Minimap-Scan weit und eng, Reichweitenpruefung der Gruppenmitglieder, "Zu Einheit drehen" 1 bis 6 und 180 Grad, "Scan fortsetzen", Scan 1 bis 8 und die Ressourcen-Benachrichtigung. Jetzt wirkt die zweite Taste ueberall. Ausserdem heisst die Monitor-Taste jetzt richtig "fortlaufende" statt "forlaufende".

Technisch: SkuCore/Core.lua, OnHide-Script von SkuCoreControlOption1: die Bindungen dieses Frames wurden mit SetOverrideBindingClick nur fuer .key gesetzt (einzige Ausnahme war SKU_KEY_TAXICANCEL), der Click-Dispatcher prueft per SkuKeyBindsMatchKey aber beide Felder. Die Tastenbelegungs-Menues in SkuZOptions/Core.lua setzen key2 seit jeher, daher funktionierte die zweite Taste bei anderen Aktionen. Ein lokaler tArm(aConst)-Helfer bindet jetzt jede Taste, die SkuKeyBindsGetKeys liefert; die zwanzig handgeschriebenen Einzelzeilen sind weg.

Monitor Kampf: Todesansage nennt die Numblock-Taste

Einfach: Unter Monitor, Kampf, Freundlich, "Tode ansagen" wird ein gestorbenes Gruppenmitglied angesagt. Die Nummer darin ist jetzt immer die Taste, die das Mitglied anwaehlt. In einer Gruppe sind das Skus Standardtasten: Numblock 1 = selbst, 2 bis 5 = die vier anderen. Das vierte Gruppenmitglied heisst darum jetzt "party 5, dead", nicht mehr "party 4". So zaehlen der Gesundheitsmonitor und die Uebersicht seit jeher. Im Raid wird die Dial-Targeting-Nummer angesagt: bis 10 Spieler die eine Taste, ab 11 die zweistellige Folge. Bisher hiess es dort "party 2" fuer Mitglieder der eigenen Untergruppe und "raid 17" (der rohe Raid-Platz) fuer alle anderen, zwei Zaehlungen in einem Kampf, keine davon passte zum Numblock. Raid-Plaetze 26 bis 40 wurden gar nicht angesagt. "Tode hochzaehlen" ist entfernt: im Modus "nur Nummer" war sein "3, dead" nicht von "party 3, dead" zu unterscheiden, und der Zaehler ging bei einer Wiederbelebung nie zurueck.

Technisch: SkuCore/aqCombat.lua, aqCombat_SKU_UNIT_DIED. Neuer Helfer tDeathUnitToken(GUID) liefert gesprochenes Token und echte Unit-ID getrennt, die Pruefungen UnitIsDeadOrGhost und Begleiter brauchen den rohen Platz. Gruppe: Token aus aqCombatGroupGuidToUnitId, Ziffer plus 1. Raid: alle MAX_RAID_MEMBERS Plaetze per GUID durchsucht (die 25 in tAllPartyRaidUnits reichten nicht), Nummer aus dem Dial-Targeting-Raster gelesen (SkuSecureTargetingFrame, unitNameSlotGG-SS, Taste = (GG-1)*5+SS; Attribute eines Secure-Frames darf unsicherer Code lesen), sonst tDTRaidRoster aus aq.lua, sonst live (Untergruppe-1)*5+Position. Raster und Roster werden nur ausserhalb des Kampfes neu gebaut, veralten also gemeinsam mit dem Numblock. partyDeadCount samt Zaehler, Menue und Locale-Schluessel entfernt, der gespeicherte Wert wird beim Login geloescht.

Monitor Kampf: "Tote Gruppenbegleiter ignorieren" bleibt auf Nein

Einfach: Die Einstellung liess sich auf "Nein" stellen, stand nach dem naechsten Neuladen aber wieder auf "Ja". Behoben.

Technisch: aqCombatOnLogin setzte den Wert mit "x or true"; ein gespeichertes false ist in Lua falsch und wurde so bei jedem Laden durch true ersetzt. Jetzt nur noch bei nil.

Monitor Gesundheit: "Tot bei 0 Prozent anhaengen" standardmaessig aus

Einfach: Der Tonhoehen-Stil des Gruppen- und Raid-Gesundheitsmonitors haengt an den Ton eines Mitglieds mit 0 Prozent einen "dead"-Clip an. Das war fuer Gruppe und Raid eingeschaltet und ist jetzt aus, auch bei bestehenden Charakteren. Wer es will, schaltet es unter Monitor, Gruppe beziehungsweise Raid, Gesundheit wieder ein. Die Todesansage des Kampfmonitors (oben) ist damit die einzige Todesmeldung, die von sich aus laeuft.

Technisch: SkuCore/aq.lua, AqOnLogin: Vorgabe false statt true, einmalige Umstellung bestehender Charaktere ueber addDeadOn0PercentDefaultOff (Muster wie *DefaultOff in aqCombat).

Dial Targeting: nur noch im Raid, eine Taste bis 10 Spieler

Einfach: "Aktiviert" unter Dial Targeting ist jetzt ein Ein/Aus-Schalter und wirkt nur im Raid. Die Auswahl "Gruppe" und "Gruppe und Raid" ist weg: in einer Gruppe erreichen Skus Standardtasten Numblock 1 bis 5 ohnehin jeden, und der Gruppenmodus legte eine verschobene Zaehlung (0 = selbst, 1 bis 4 = die anderen) darueber und verdeckte die Standardtasten, solange er aktiv war. Gespeichertes "Gruppe" wird zu Aus, "Raid" und "Gruppe und Raid" zu Ein. In Raids bis 10 Spieler ist jetzt immer eine Taste pro Mitglied aktiv (Numblock 1 bis 9, 0 = Mitglied 10, Reihenfolge nach Untergruppen), ab 11 Spielern die zweistellige Eingabe. Die Option "Nur ein Tastendruck in Raids bis 10 Spieler" ist weg, das ist jetzt die Regel.

Technisch: SkuCore/DialTargeting.lua. enabled wird beim Login einmalig auf Aus/Ein abgebildet, singleKeyinRaid10 geloescht. DialTargetingRosterUpdate und DialTargeting_EndableDisable pruefen nur noch UnitInRaid und enabled == Ein; der Gruppenzweig (unitNameSlot01-0x = partyx) und der tote "party"-Zweig im Secure-Snippet sind entfernt. Raid-Modus: tNumCurMembers > 10 heisst zweistellig, sonst raid10. Drei Locale-Schluessel entfernt. Alles ungetestet im Spiel.

Gruppennummern: eine Zaehlung fuer alle Monitore

Einfach: Jede Nummer, die Sku fuer ein Gruppenmitglied sagt, soll die Taste sein, die es anwaehlt. In der Gruppe ist das Numblock 1 fuer dich und 2 bis 5 fuer die anderen; im Raid die Dial-Targeting-Nummer, also eine Taste 1 bis 10 bei bis zu 10 Spielern und zwei Ziffern ab 11. Die Todesansage zaehlt seit dieser Version so. Jetzt tun es auch der Gesundheitsmonitor und der Debuff-Monitor im Raid, die Bedrohungswarnungen, "Ziel des Ziels" und "ausser Reichweite" im Kampfmonitor sowie die Auren-Ausgaben "Quelleinheit" und "Zieleinheit". Der Gesundheits- und der Debuff-Monitor fuer die Gruppe laufen im Raid weiter mit der Gruppenzaehlung, denn wer im Raid nur seine Untergruppe im Blick hat, waehlt sie dort mit Numblock 2 bis 5 an.

Der Gesundheitsmonitor im Raid hat Tonhoehen-Dateien nur fuer die Nummern 1 bis 25.

Mitglieder 26 bis 40 waren darum stumm; sie werden jetzt gesprochen, erst die Nummer, dann die Gesundheit in Zehnerschritten, mit der Stimme aus der neuen Einstellung "Stimme fuer Mitglieder ab 26" (Monitor, Raid, Gesundheit; Standard Justin).

Technisch: SkuCore/aq.lua: SkuCore.Monitor.RaidMemberNumbersByName() baut die Name-zu- Nummer-Tabelle nach der Dial-Regel (bis 10 Mitglieder flach 1-10 in Untergruppenreihenfolge, ab 11 (Untergruppe-1)*5+Position); tDTRaidRoster und das Dial-Targeting-Raster (DialTargeting.lua) werden daraus gefuellt, bisher rechnete tDTRaidRoster immer zweistellig. SkuCore.Monitor.GroupMemberNumber(unitId) liefert die Tastennummer fuer party-/raid-Tokens. Die fortlaufende Debuff-Ausgabe im Raid sagte string.sub(unitId, 5)+1. MonitorOutputRaidPercent2 spricht Nummern ueber 25 per MonitorOutputPlayerStatus (raid.health2.voice, Standard 1) und gibt die Dauer an die Warteschlange zurueck; die Warteschlangen-Eintraege tragen dafuer die absolute Gesundheit. SkuCore/aqCombat.lua: tAllPartyRaidUnits und

tUnitsToTestOnGameRaidTargets enthielten raid1-25 fest; sie werden jetzt bei jedem Roster-Ereignis an Ort und Stelle aus der echten Raidgroesse neu gefuellt.

tSpokenGroupUnit(unitId) nutzt die Todesansage-Zuordnung fuer alle freundlichen Ansagen. "party5"/"partypet5" gibt es in den Kampfstimmen nicht als Wort, SkuCoreAqCombatGetVoiceString zerlegt sie in "party", "pet", "5". SkuAuras/data.lua:

tUnitIdToSpokenName sagt party N als N+1 und raid N als Dial-Nummer.

Raid-Untergruppen-Tasten: mit einer Taste in eine Raid-Gruppe springen

Einfach: Wer im Raid nur seine eigene Gruppe versorgt, braucht einen schnellen Einstieg in eine Gruppe, ohne die zweistellige Dial-Eingabe. Alt+Numblock 1 bis 8 nimmt das erste Mitglied der Raid-Gruppe 1 bis 8 ins Ziel (das Mitglied mit Nummer 1 in dieser Gruppe, dieselbe Reihenfolge wie Dial Targeting und die Monitore). Das Ziel wird wie jedes Ziel angesagt. Ist die Gruppe leer, sagt Sku "Gruppe N leer" und nichts passiert; ausserhalb eines Raids "Kein Schlachtzug". Die acht Tasten haben ein eigenes Untermenue "Raid-Untergruppen Tasten" in der Sku-Tastenbelegung, auch die zweite Taste funktioniert. Die Funktion laesst sich unter Funktionen abschalten. Wie bei allen Zieltasten gilt: Gruppenwechsel waehrend eines Kampfes werden erst nach dem Kampf uebernommen, bis dahin springt die Taste zum alten ersten Mitglied.

Technisch: Neue Datei SkuCore/subgroupTargeting.lua (Untermodul SubgroupTargeting, in der TOC nach skuFocus.lua). Acht SecureActionButtons SkuSubgroupTarget1-8 mit type1=macro, macrotext1="/tar <Name>", gebunden per SetOverrideBindingClick OHNE fuenftes Argument (LeftButton, damit type1/macrotext1 gelesen wird); die Namen werden aus GetRaidRosterInfo (erster Name je Untergruppe in Roster-Reihenfolge) bei GROUP_ROSTER_UPDATE, GROUP_FORMED/JOINED/LEFT und PLAYER_ENTERING_WORLD ausserhalb des Kampfes geschrieben, im Kampf auf PLAYER_REGEN_ENABLED verschoben. PreClick (unsicher, laeuft auch im Kampf) spricht die Leer-/Kein-Raid-Meldung. Kontroll-Frame SkuCoreSubgroupControl, Script OnHide, bewaffnet beide Tasten jeder Konstante ueber SkuOptions:SkuKeyBindsGetKeys. Konstanten SKU_KEY_SUBGROUPTARGET1-8, Standard ALT-NUMPAD1-8 (SkuZOptions/SkuKeyBinds.lua), Gruppe "Raid Untergruppen Tasten" in SkuCore/Options.lua.