Sku v43.5 - Patchnotes

Ueberblick

Fehlerbehebungen

Questdatenbank: das Oeffnen der Questlisten liess das Spiel einfrieren

Einfach: Wer unter Quest > Questdatenbank die Liste "Alle" oeffnete, bekam seit v43.2 einen Haenger von mehreren Sekunden. Die Liste oeffnet jetzt wieder sofort; die Eintraege einer Quest (Annahme, Ziel, Abgabe ...) werden erst gebaut, wenn man die Quest betritt. Gleiches gilt fuer "Start in Zone" und "Quests in der Naehe".

Technisch: "Alle" baute fuer jede der mehreren tausend Quests der Datenbank sofort das komplette Untermenue (CreateQuestSubmenu). Seit v43.2 loest dessen Ziel-Zweig fuer Quests mit einem Ausloese-Ort (triggerEnd) den naechsten Routen-Wegpunkt geometrisch auf (GetTriggerEndWps) - ein kompletter Scan des Wegpunkt-Caches eines Kontinents - und seit v43.3 fuer jede solche Quest statt nur fuer die ohne andere Ziele. Ein Oeffnen kostete so rund 170 Kontinent-Scans in einem einzigen Frame. Die Quest-Eintraege sind jetzt dynamische Knoten mit eigenem BuildChildren, wie in "Aktuelle Quests" schon immer.

Chat: falsche Kanalansage nach dem Oeffnen mit dem Schraegstrich

Einfach: Wer zuletzt jemandem gefluestert hatte und die Chatzeile mit "/" oeffnete, hoerte "An Kai" - und nach "/g " gleich darauf "Gilde". Die erste Ansage war falsch: solange die Zeile mit einem Schraegstrich beginnt, geht nichts an diesen Kanal, erst der Befehl entscheidet. Die Ansage schweigt jetzt, solange ein Befehl in der Zeile steht, und sagt den Kanal, sobald er feststeht ("/g " wird zu "Gilde") oder der Schraegstrich wieder geloescht wird. Ein bewusster Wechsel auf "Sagen" ("/s ") wird jetzt ebenfalls gesagt, wenn Sagen nicht ohnehin der Standardkanal war. Beim Zurueckholen einer gesendeten Zeile (Pfeil hoch) entfaellt der Kanal-Vorspann, wenn die Zeile ein Befehl ist.

Technisch: Blizzard zeigt in der Kopfzeile immer das Attribut chatType, und das ist beim Oeffnen der sticky-Kanal der zuletzt gesendeten Nachricht (auch Fluestern ist sticky, samt tellTarget). Die Schraegstrich-Taste ruft ChatFrameUtil.OpenChat("/"): dieselbe Kopfzeile plus ein "/" im Feld, gesetzt erst im naechsten OnUpdate (editBox.setText), die UpdateHeader-Aufrufe des Oeffnens laufen also noch mit leerem Feld. Ein Text, der mit "/" beginnt, geht nie an den Kanal der Kopfzeile: erst wenn ParseText den Befehl aufloest ("/g " beim Leerzeichen, "/w Name " hinter dem Namen), setzt Blizzard chatType neu, SetText(Rest) und dann UpdateHeader. Sku prueft jetzt an allen Ansage-Stellen (UpdateHeader-Haken, Fokus, verzoegertes Sprechen) den effektiven Text inklusive des ausstehenden setText (SkuChat:EditboxTextIsCommand); eine neue OnTextChanged-Kante deckt das Loeschen des Schraegstrichs ab, fuer das Blizzard kein UpdateHeader ruft.

Sprachausgabe: einzelne Zeilen blieben zufaellig stumm

Einfach: Wer schnell durch eine Liste ging, hoerte hin und wieder eine einzelne Zeile nicht - etwa "Nagakampfhandschuhe" in der Ausruestung, waehrend die Nachbarn gesprochen wurden - und sie blieb auch beim mehrfachen Darueberfahren stumm. Das betraf die NVDA/SAPI-Bruecke und konnte ueberall in Sku passieren, meist nach einem /reload. Jede Zeile wird jetzt wieder zuverlaessig gesprochen.

Technisch: Der WoW-Client speichert gerenderte Sprachausgabe pro Text und spielt sie bei einer Wiederholung ab, ohne die Stimme erneut aufzurufen - bei der Bruecke ist diese Wiederholung Stille. Sku haengt darum an jeden Text eine pro Text zaehlende Folge geschuetzter Leerzeichen (1..64), damit jede Wiederholung ein neuer Text ist. Der Zaehler lebte aber nur in Lua und begann bei jedem /reload von vorn, waehrend der Cache des Clients den Reload ueberlebt (die Utterance-IDs laufen ueber den Reload hinweg durch). Eine nach dem Reload erneut gesehene Zeile konnte so wieder in einen schon gerenderten Bereich fallen und blieb stumm, bis der Zaehler diesen Bereich verlassen hatte - im Protokoll sechs Anschlaege in Folge mit sauberem SpeakText + STARTED + FINISHED. Die Zaehler liegen jetzt in SkuOptionsDB.global (bttsCacheBust) und laufen ueber den Reload weiter; zudem ist der Raum pro Text 512 Varianten statt 64 (fuehrende geschuetzte Leerzeichen 1..8 tragen den hohen Teil des Zaehlers).

Quest: "Raenes Saeuberung" (Eisenknauf) hatte kein Questziel

Einfach: Die Quest 1027 "Raenes Saeuberung" im Eschental verlangt das letzte Teil von Dartols Rute, den Eisenknauf. Sku kannte dafuer keinen Ort, "Questziel" blieb leer. Jetzt fuehrt das Questziel in das Schleimgebiet suedoestlich von Raynewoods Zuflucht: Dort lassen die Faulenden Bruehschleimer beim Tod eine Rostige Truhe zurueck, in der der Knauf liegt.

Technisch: Der Gegenstand 5519 (Iron Pommel) verweist in der Datenbank korrekt auf das Objekt 19021 (Rusty Chest), doch dessen Datensatz hatte keine Spawn-Koordinaten, weder in objects.lua noch in objects_fixes.lua - der Item-Zweig von GetResultingWps fand nichts. objects_fixes.lua (TBC und Era) traegt jetzt die 44 Truhenpositionen von Wowhead im Eschental nach (Zone 331, etwa 68-78 / 68-80); das ist dieselbe Flaeche wie die Spawns des Faulenden Bruehschleimers (3928), der die Truhe hinterlaesst.

Sprachausgabe: getippte Zeichen und abgebrochene Ansagen kamen verspaetet nach

Einfach: Wer eine laengere Nachricht tippte und die Chatzeile dann schloss, hoerte die Buchstaben danach weiter - Zeichen fuer Zeichen, waehrend man laengst in einem anderen Menue navigierte, in einem Mitschnitt fast eine Minute lang. Dasselbe galt fuer eine abgebrochene Ansage: nach "Abgebrochen" kam noch ein Rest der alten Zeile, etwa eine Entfernungsangabe aus dem gerade geschlossenen Wegpunktmenue. Was beim Schliessen oder Abbrechen noch aussteht, wird jetzt verworfen. Die Tastenansage bleibt dabei vollstaendig - es geht kein Buchstabe verloren.

Technisch: Der Client nimmt jedes SpeakText ohne Begrenzung an, spielt aber nur eines nach dem anderen ab, und C_VoiceChat.StopSpeakingText bricht nur die gerade LAUFENDE Ausgabe ab - ein Leeren der Warteschlange wie SAPIs PurgeBeforeSpeak gibt es nicht. Alles bereits Uebergebene ist damit unwiderruflich. Die Tastenansage gab bisher pro Anschlag sofort eine Ausgabe ab, drei bis vier pro Sekunde, waehrend der Client etwa eine pro Sekunde schafft: eine getippte Zeile von 104 Zeichen parkte so rund 80 Ausgaben im Client, die danach einzeln nachliefen. Aus demselben Grund liefen CancelBttsOutput und EndScope ins Leere - sie leeren Skus eigene Warteschlange, in der die Zeichen nie lagen (85 von 93 EndScope-Aufrufen eines Mitschnitts verwarfen nichts). Die Zeichen warten jetzt in Sku, es geht immer nur eines an den Client, und das naechste erst bei dessen PLAYBACK_FINISHED - dem Moment, in dem der Client ueberhaupt wieder eine Ausgabe annimmt (jedes STARTED des Mitschnitts faellt mit einem FINISHED zusammen). Damit ist nie etwas uebergeben, das noch nicht laeuft, und ein Abbruch erreicht alles. Ein kurzes Abbruchfenster sichert den Rest ab: nach einem harten Abbruch wird nichts uebergeben und jede dennoch startende Ausgabe sofort gestoppt. Das entspricht dem Aufbau von NVDA, das die Warteschlange ebenfalls selbst haelt und der Stimme nur eine Ausgabe auf einmal gibt.

Anmelde-Tool 3.3: Absturz beim Start durch eine beschaedigte Windows-Stimme

Einfach: Nach einer frischen Installation sagte das Tool noch "Version 3.2" an und brach dann mit einem Fehlerfenster ab ("Error: (0x80045039) Specifically: GetVoices"). Schuld war nicht das Tool allein, sondern eine beschaedigte Stimme in Windows - etwa eine deinstallierte Stimme, die Reste hinterlassen hat. Das Tool ueberspringt eine solche Stimme jetzt, vermerkt sie in log.txt und startet normal; sie fehlt dann nur im Menue "Stimme auswaehlen".

Technisch: 0x80045039 ist SPERR_NO_MORE_ITEMS: SAPI meldet N Stimmen, eine davon laesst sich aber nicht lesen (kaputter Eintrag unter HKLM\SOFTWARE\Microsoft\Speech\Voices\ Tokens). Das Tool starb beim Aufbau des Stimmen-Menues an der for-Schleife ueber sap.GetVoices(). GetVoices() und SetSapiVoiceByName() lesen jetzt ueber die neue Funktion ReadableVoiceTokens() jede Stimme einzeln per Item(i) in einem eigenen try; eine unlesbare wird uebersprungen und geloggt, scheitert schon die Liste, bleibt sie leer. SapiInit() liest die Standardstimme ebenfalls geschuetzt. Am Rechner mit kaputter Stimme noch ungetestet.

Sprachausgabe: schnelles Blaettern las ueber die NVDA-Bruecke den vorigen langen Eintrag zu Ende

Einfach: Mit der NVDA/SAPI-Bruecke als Stimme las Sku beim schnellen Blaettern durch eine Liste mit langen Eintraegen (Wegpunktliste, Questtexte, Chatverlauf) erst den vorigen Eintrag ganz zu Ende und dann den, auf dem der Cursor stand. Jetzt wird der alte Eintrag nach einem kurzen Moment abgebrochen und der gewaehlte gelesen, wie bei einer Windows-Stimme. Laengere Texte, die in mehreren Teilen kommen, werden weiter vollstaendig gelesen, und das Tipp-Echo bleibt unveraendert. Die Behebung braucht die neue NVDA-Bruecke aus dem Sku-Installer 5.1: ueber den Installer aktualisieren (nicht nur das Addon-Zip) und WoW danach komplett neu starten.

Technisch: StopSpeakingText des Spiels stoppt nur die eigene Wiedergabe des Clients. Auf der Bruecke steht der Text dann schon in NVDAs Warteschlange, und SAPI reicht "purge before speak" nie an eine Engine weiter - nichts auf dem Weg konnte NVDA unterbrechen. Bei der Engine kommt nur die Ausgabe selbst an, Markup eingeschlossen. Deshalb reist die Absicht jetzt darin mit, wie bei Prisms speak(text, interrupt): jeder Stopp setzt ein Flag, und die naechste Zeile traegt <bookmark mark="skuint"/>. Die mit dem Installer ausgelieferte Engine (SAPI2SR mit Skus Patch C) ruft bei diesem Bookmark nvdaController_cancelSpeech und reicht dann den Text weiter. Zeilen ohne Stopp davor tragen keine Marke und reihen sich weiter ein. Echte SAPI-Stimmen verschlucken das Bookmark lautlos; eine aeltere Engine ueberspringt es.