Im Charakterfenster werden die Beschreibungen der Werte wieder vorgelesen
Einfach: Unter "Eigenschaften" hatte jeder Wert - Zauberschaden,
Zaubertrefferwertung, Ausdauer, Waffengeschwindigkeit und alle uebrigen - nur seinen Namen und seine Zahl. Die Beschreibung, die das Spiel dazu anzeigt, war leer: was der Wert bewirkt, die Aufschluesselung nach Zauberschulen, Haupt- und Nebenhand. Die Taste fuer den vollstaendigen Text sagte an diesen Eintraegen nichts. Nur die Widerstaende und die Ausruestung hatten eine Beschreibung.
Jetzt hat jeder Wert seine, und sie wird bei jedem Anlaufen frisch gelesen, ist also auch nach einem Buff oder einem Ausruestungswechsel aktuell.
Technisch: Der Tooltip-Abruf war an dieser Stelle auskommentiert, und jeder Eintrag wurde mit leerem textFull gebaut - unveraendert schon in v41.06, das ist also kein Rueckschritt aus dem Umbau, sondern hat nie funktioniert. Zwei Gruende, warum er so auch nicht funktionieren konnte: GetButtonTooltipLines wurde mit GameTooltip als zweitem Argument aufgerufen, was genau den Schritt ueberspringt, der den Tooltip erst fuellt; und ohne dieses Argument haette der Helfer trotzdem abgebrochen, weil er ein OnEnter nur fuer Objekte ausloest, die eine .type-Markierung tragen - die haben die Werte-Frames nicht, und genau deshalb setzt die Widerstands-Schleife sie vor ihrem Abruf. Dazu kam ein dritter Grund, an dem eine naive Reparatur falsch geworden waere: TBC schickt alle 29 Werte durch EIN gemeinsames Widget (PlayerStatFrameLeft1), und die Blizzard-Setter lassen ihren Zustand darauf liegen - .tooltip/.tooltip2 sowie .bonusDamage/.spellCrit/.damage fuer die vier Werte, die ein eigenes OnEnter setzen. Keiner raeumt hinter dem vorherigen auf, vier tauschen OnEnter aus und nie zurueck; Blizzards eigenes UpdatePaperdollStats macht vor jeder Gruppe genau deshalb einen Reset. Ohne den haette Wert N die Beschreibung von Wert N-1 vorgelesen. Der Abruf setzt das Widget jetzt vor jedem Setter zurueck und liest den Tooltip ueber NumLines/GameTooltipTextLeft|Right statt ueber GetRegions - letzteres liefert linke und rechte Spalte als zwei getrennte Bloecke, die Aufschluesselung nach Zauberschulen waere also als sechs Schulnamen gefolgt von sechs Zahlen vorgelesen worden. Der Live-Getter, der den Wert bei jedem Anlaufen neu bestimmt, gibt die Beschreibung jetzt als zweiten Rueckgabewert mit; danach wird das Widget ueber PaperDollFrame_UpdateStats in den Zustand zurueckversetzt, den Blizzard erwartet.
Sku ist nicht mehr darauf angewiesen, dass interne Kennwoerter unuebersetzt bleiben
Einfach: Auf einem franzoesischen Client tat die Taste fuer das Quest-Log gar nichts - kein Fokus, kein Ton, keine Fehlermeldung. Schuld war ein einziges uebersetztes Wort in der franzoesischen Sprachdatei. Manche Eintraege dort sind naemlich keine Beschriftung, sondern ein internes Kennwort, mit dem Sku seine eigenen Menuepfade bildet und wiedererkennt; wird so eines uebersetzt, findet das Addon seinen eigenen Pfad nicht mehr. Das ist behoben, und zwar so, dass es sich nicht wiederholen kann: das Kennwort ist gar kein uebersetzbarer Text mehr. Wer sich einen franzoesischen Pfad angewoehnt hat, kommt damit weiterhin ans Ziel. Ein zweiter Fund derselben Art haette jeden franzoesischen Client beim naechsten Sortieren der Sprachdatei lautlos auf englische Namen fuer Gegner, Objekte und Quests umgestellt - auch das ist beseitigt.
Technisch: Gefunden, auf die Ursache zurueckverfolgt und behoben hat das ZenqFR (Games-Access) auf einem echten franzoesischen Client, als PR #2 in diesem Repo. Die weiteren Aenderungen bauen darauf auf. L["short"] trug zwei unabhaengige Bedeutungen: an rund 25 Stellen war es das erste Feld eines SkuOptions:SlashFunc-Pfads, also ein Protokoll-Kennwort, das der Code gegen sich selbst vergleicht, an genau einer Stelle (SkuCore/aq.lua) echter Anzeigetext. Ein Uebersetzer sieht immer nur die zweite Bedeutung. Beide sind jetzt getrennt: Sku.MENU_ROOT ist das Kennwort und wird von allen 23 pfadbildenden Stellen benutzt, dazu von den sechs, die das Literal "short," fest verdrahtet hatten - eine davon war die Quest-Log-Taste. Der Vergleich akzeptiert weiterhin auch L["short"], damit gelernte lokalisierte Pfade weiterlaufen. Nebenbei behoben: der Ersatzwert in SkuCore/dungeonBrowser.lua war "sku" und damit ueberhaupt kein gueltiges Kennwort. Zweitens definierte frFR.lua L["locale"] doppelt - "enUS" im sortierten Rumpf und "frFR" am Ende angehaengt. Richtig aufgeloest wurde das nur durch AceLocales Reihenfolge: eine Nicht-Standardsprache wird ueber einen Proxy registriert, der bedingungslos rawsetzt, also gewinnt die LETZTE Zuweisung. Aus diesem Schluessel liest Sku Sku.Loc, und daran haengt, welche SkuDB-Namenstabellen der gesamte Client benutzt: ein Neuerzeugen oder Sortieren der Datei haette jeden franzoesischen Client stumm auf englische DATEN umgestellt - kein Fehler, keine Logzeile, nur ueberall die falschen Namen. Die verlierende Zeile ist geloescht, die ueberlebende dokumentiert, und dev/rework-docs/_locale_dupes.py meldet ab jetzt doppelte Schluessel je Sprachdatei. Der Linter macht nebenbei sichtbar, dass enUS als AceLocale-Standardsprache umgekehrt ERSTE-gewinnt: derselbe doppelte Schluessel kann pro Sprache auf verschiedene Eintraege zeigen. 64 solcher Konflikte gibt es heute, fast alles alter Uebersetzungsstaub; sie sind bewusst stehen geblieben und jetzt wenigstens sichtbar. Drittens haelt
SkuDBEnsureActiveLocaleTables sein Versprechen nun auch wirklich - es laeuft zusaetzlich bei ADDON_LOADED (vorher erst einen OnUpdate nach PLAYER_LOGIN, wer also in seinem eigenen PLAYER_LOGIN-Handler auf [Sku.Loc] zugriff, sah fuer einen Moment nil) und steigt bei unbrauchbarem Sku.Loc nicht mehr wortlos aus, sondern prueft, meldet den wahrscheinlichen Verursacher ins Log und baut die Tabellen trotzdem.
Die Sprache verstummt nicht mehr, wenn du schnell durch eine Liste gehst
Einfach: Schnelles Blaettern durch ein Menue, durch die Liste der Objekte in der Naehe oder durch die Taschen konnte die Sprachausgabe ganz zum Schweigen bringen - uebrig blieben nur die Klick- und Bakengeraeusche - bis du ein paar Sekunden gewartet oder einen anderen Teil der Oberflaeche angesteuert hast. Jeder Eintrag, an dem du vorbeigelaufen bist, wurde verschluckt, oft auch der, auf dem du stehen geblieben bist. Jetzt geht jeder Eintrag, ueber den du laeufst, an die Stimme, und der Eintrag, auf dem du stehen bleibst, wird gesprochen. An der Frage, welche Ansage gewinnt, wurde nichts geaendert: eine neue ersetzt weiterhin die vorherige, schnelles Blaettern liest also nach wie vor nur das vor, wo du landest, und das Abbrechen der Sprache im Kampf bleibt unveraendert.
Technisch: Die Blizzard-TTS-Pumpe hat sich mit einem Countdown getaktet, der je Durchlauf nur die Dauer EINES Bildes abgezogen hat - ihr Rumpf laeuft aber nur alle 0,01 s. Oberhalb von rund 100 fps zog sie damit deutlich weniger ab als tatsaechlich vergangen war, und die beabsichtigte Pause von 0,1 s vor der naechsten Ausgabe wurde real zu 0,2-0,3 s. Da ein Queue-Reset die noch wartende Zeile loescht, bedeutet eine laengere Pause mehr verlorene Ansagen: der Fehler wurde schlimmer, je hoeher die Bildrate war. Die Pause ist jetzt eine GetTime-Frist - bei 60 fps identisch, darueber korrekt. Gemessen an einer Aufzeichnung mit 6-7 Tastendruecken pro Sekunde: vorher ergaben 7 Resets 2 gesprochene Zeilen, nachher ergeben 7 Resets 7. Eine zweite Absicherung unterdrueckt ein StopSpeakingText, wenn nichts unterwegs ist und innerhalb der letzten 0,15 s bereits eines gesendet wurde - der Client verarbeitet Stopps asynchron, ein nachlaufender konnte die naechste Ausgabe abbrechen, bevor sie begonnen hatte. Beim Navigieren greift diese Absicherung jetzt nicht mehr; sie bleibt fuer ereignisgetriebene Schuebe (Post, Chat), die in einer Sekunde 17 Stopps und gar keine Sprache erzeugt haben.
Weniger Arbeit je gesprochener Zeile
Einfach: Sku leistet fuer jede gesprochene Zeile und jeden abgespielten Ton spuerbar weniger Arbeit, was sich als fluessigeres Blaettern bemerkbar macht.
Technisch: Zwei voruebergehende [SOUND-PROBE]-Diagnosen wurden entfernt. Beide haben debugstack(...) als Argument an dprint uebergeben, und dprint prueft das Debug-Flag erst in sich selbst - ein vollstaendiger Stack-Walk lief also bei jedem Ton, auch bei ausgeschaltetem Log, und die Variante in Sku/Core.lua hing am globalen PlaySound, sodass auch Blizzards eigene Aufrufe dafuer bezahlt haben. Sie machten ein Viertel aller aufgezeichneten Log-Zeilen aus. Die Queue-Pumpe ueberspringt ihre Durchlaeufe jetzt vollstaendig, solange beide Warteschlangen leer sind, statt sie rund hundertmal pro Sekunde auszufuehren, und die Wiki-Linksuche steigt vor dem Normalisieren der Zeichenkette aus statt danach: sie wird aus OutputStringBTtts fuer jede gesprochene Zeile aufgerufen, ihr Ergebnis wird dort ohnehin verworfen, und ohne Wiki-Index liefen rund 19 string.gsub-Durchgaenge, nur um eine Abfrage zu erreichen, die nichts tat.
Der Installer und die Downloadseite sprechen jetzt auch Franzoesisch
Einfach: Sku selbst spricht seit v42.11 Franzoesisch, alles drumherum aber nicht. Der Sku-Installer laeuft jetzt auf Franzoesisch - er nimmt seine Sprache von Windows, und umstellen laesst er sich jederzeit in der Liste "Sprache dieses Installers" - und die Downloadseite gibt es in einer franzoesischen Fassung, erreichbar ueber die Sprachlinks oben auf beiden Seiten. Auch diese Patchnotes gibt es auf Franzoesisch, beginnend mit v42.11. Ein franzoesisches Sprachpaket gibt es weiterhin nicht: auf einem franzoesischen Client spricht Sku ueber den Screenreader, weshalb der Installer dort das englische Paket anbietet. Der Installer traegt damit die Version 4.1.
Technisch: Eine franzoesische Tabelle in Loc.cs des Installers (Lang.Fr, derselbe Schluesselsatz wie Englisch und Deutsch, "fr" aus der UI-Kultur des Systems; die Sprachauswahl wird aus ComponentsForm._langOrder aufgebaut, sodass kein Index-Literal mehr nachgezogen werden muss), docs/index-fr.html und "Patch Notes Sku FR.txt", das release.ps1 auf die Webseite spiegelt. Die Docs-Ersetzungen in release.ps1 laufen jetzt ueber eine LISTE von Seiten und greifen auf sprachneutrale Fragmente, damit eine uebersetzte Seite keine veraltete Versionsnummer behalten kann - genau der Fehler, um den es beim Ueberschriften-Fix in v42.11 ging, eine Seite weiter; dabei faellt auch die SkuMapper-Ueberschrift mit ab, die unbemerkt veraltet war. Die
Discord-Ankuendigung geht jetzt pro Kanal: eine Webhook-Zeile darf die Sprachen dieses Kanals nennen, ein rein deutscher Server bekommt also eine deutsche Zeile mit deutschen Links statt drei Sprachen, die er nicht wollte.
Zwei Menues, die nur ein Zwischenschritt waren, sind weg
Einfach: Unter "Einstellungen" stand der Punkt "Kampf", und darin genau ein Eintrag: "Sku Menue im Kampf". Dieser Eintrag steht jetzt direkt in "Einstellungen, Allgemein", das leere "Kampf" darueber gibt es nicht mehr. Dasselbe im Hauptmenue: "Werkzeuge" enthielt nur "Dial Targeting" und "Soft Targeting"; beide stehen jetzt im "Schnellmenue", und "Werkzeuge" ist aus dem Hauptmenue verschwunden. An den Einstellungen selbst aendert sich nichts, alle bisher gespeicherten Werte bleiben erhalten.
Technisch: Die drei Eintraege behalten ihre bisherigen Builder, ihre db und ihr keyPrefix, es aendert sich nur, wo sie eingehaengt werden - gespeicherte Werte sind damit unberuehrt. "Werkzeuge" ist als SkuMenu-Modul und aus SkuMenu:SetRootLayout entfernt (SkuZOptions/SkuMenu.lua); DialTargetingMenuBuilder und die softTargeting-Gruppe (weiter ueber IterateOptionsArgs mit
aIncludeHidden=true, da forAudioMenu=false) haengen jetzt in den BuildChildren des Schnellmenues (SkuZOptions/Core.lua). Die "Kampf"-Spezifikation faellt aus tSpecs in SkuCore/Options.lua weg; CombatMenuOpenMenuBuilder wird jetzt am Ende des Allgemein-Builders aufgerufen, mit derselben Einstellung combatMenuOpen. Kein SlashFunc-Pfad zeigte auf eines der beiden Menues, es musste also nichts weiter nachgezogen werden.