Sku v43.7 - Patchnotes

Ueberblick

Aenderungen

Fehlerbehebungen

Drehen: schneller, genauer, selbst eingemessen

Einfach: "Zum Beacon drehen" (T) und die beiden anderen Drehbefehle wurden anhand von Messungen im Spiel ueberarbeitet. Drei Dinge aendern sich spuerbar. Erstens: grosse Drehungen kommen mit einem Druck an. Bisher schaffte ein Druck hoechstens etwa 88 Grad, egal wie weit es gehen sollte - das war ein unbemerkter Fehler seit v43.2. Zweitens: die Drehung ist schneller, eine Kehrtwende dauert nur noch gut eine Zehntelsekunde. Drittens: bist du schon auf 3 Grad genau ausgerichtet, passiert bei einem weiteren Druck nichts mehr. Frueher drehte jeder Druck mindestens 5 Grad, darum pendelte man um den Beacon-Ping herum und kam nie zur Ruhe. Im Wasser spart das ausserdem unnoetige Tauchstupser. Sku lernt dabei deinen Rechner: nach jeder Drehung wird gemessen, wie weit der Charakter wirklich gedreht hat, und die naechste Drehung wird danach berechnet. Bei hoher Bildrate dreht Sku von selbst flotter, bei niedriger langsamer und dafuer genau. Nach dem Update sind die ersten paar Drehungen Lernschritte und duerfen danebenliegen. Sehr grosse Drehungen nahe 180 Grad landen auf etwa 5 Grad genau; ab und zu verfeinert ein zweiter Druck. Ein Druck waehrend einer laufenden Drehung wird wie bisher verworfen.

Technisch: GameWorldObjects:TurnToWorldPosition (SkuCore/gameWorldObjects.lua). Gemessen 2026-09-21: cameraYawMoveSpeed wirkt nur bis 360 - Werte darueber drehen nicht schneller (376, 453 und 731 ergaben in 0.25 s alle ~88 Grad). Die Regel max(360, Winkel/0.25) aus v43.2 deckelte darum jeden Druck still bei ~88 Grad. Mehr Tempo kommt nur ueber das Argument von MoveViewLeftStart/MoveViewRightStart, das die CVar multipliziert (Technik aus WowVision). Zwei Gaenge: Gang 1 = CVar allein bis 360 Grad/s, Gang 2 = CVar 360 mal Faktor bis 1440 Grad/s. Modell je Gang: gedreht = k * Sollgeschwindigkeit * (Timerdauer + L); k ab der ersten Messung aus dem Median, ab 8 Messungen mit streuenden Dauern eine Ausgleichsgerade fuer k und L. Geschwindigkeit nach Bildrate: die Stopp-Streuung ist eine halbe Framedauer mal Tempo, erlaubt sind 3 Grad bzw. 6 Prozent des Winkels; nie langsamer als Winkel/0.25 s; gebremst, wenn der Timer kuerzer als 2 Frames waere. Multipliziert der Faktor auf einem Client nicht, legt Sku Gang 2 dauerhaft still. Messwerte accountweit in SkuOptions.db.global.SkuCore.turnCal. Die Sperre gegen Folgedruecke deckt jetzt auch die Nachmess-Wartezeit ab (ein Druck in dieser Luecke rechnete mit der alten Blickrichtung). Jede Drehung schreibt eine Zeile "TurnCal" ins Debug-Log. /skuturn zeigt den Stand, /skuturn reset verwirft die Messwerte, /skuturn legacy schaltet auf das alte Verhalten. Gebaut, getestet und wieder ausgebaut: eine Nachkorrektur im selben Druck - die Kamera hat Schwung und gleitet nach dem Stopp weiter, ein Befehl in dieses Gleiten kostete bis zu 35 Grad.

Schwimmen und Fliegen: Neigungssperre greift auch im Kampf

Einfach: Die automatische Neigungssperre, die dich beim Schwimmen und Fliegen waagerecht haelt, wartete bisher das Ende des Kampfes ab. Wer kaempfend ins Wasser ging, war solange ungeschuetzt, und jede Beacon-Drehung drueckte ihn tiefer. Die Sperre greift jetzt sofort. Auch die Taste Strg+Umschalt+N geht jetzt im Kampf.

Technisch: Die InCombatLockdown-Pruefungen in SkuCore:TogglePitchLock und im Automatik- Tick (SkuCore/Core.lua) beruhten auf der ungeprueften Annahme, pitchlimit sei im Kampf geschuetzt. Es ist ein Konsolenbefehl und im Kampf setzbar (getestet 2026-09-21). Im Log desselben Tages lagen zwischen Schwimmbeginn und Sperre 6 Sekunden mit drei ungeschuetzten Drehungen.

Tooltip von Set-Gegenstaenden: Ruestungsart wurde doppelt vorgelesen

Einfach: Gehoert ein Gegenstand zu einem deiner gespeicherten Ausruestungssets, fuegt Sku im Tooltip die Zeile "Gehoert zu Set" ein. Bei genau diesen Gegenstaenden war danach die Ruestungsart zweimal zu hoeren, zum Beispiel "Seelengebunden, Stoff, Kopf, Stoff". Das erste "Stoff" war ein Rest und gehoerte dort nicht hin. Jetzt kommt es nur noch einmal, hinter dem Platz: "Seelengebunden, Kopf, Stoff". Bei Waffen betraf das genauso die Waffenart und das Tempo. Gegenstaende ohne Set waren nie betroffen.

Technisch: tInsertSetLineAtTop (SkuCore/equipmentSets.lua) schiebt alle Tooltip-Zeilen ab Zeile 2 um eine nach unten. Die rechte Spalte wurde dabei nur geschrieben, wenn die Quellzeile eine hatte. Die Zeile, aus der "Kopf | Stoff" wegwanderte, bekam links "Seelengebunden" und behielt rechts ihr altes "Stoff". TooltipLines_helper liest jede FontString-Region einzeln, darum war der Rest hoerbar. Die rechte Spalte wird jetzt immer geschrieben: gesetzt und gezeigt, oder geleert und versteckt; ebenso in Zeile 2. Der Fehler steckte seit v42.00 im Code und fiel erst mit gespeicherten Sets auf.

Sprachausgabe: ueberholte Zeilen kamen verspaetet doch noch (echte Windows-Stimmen)

Einfach: Betrifft nur Spieler, die Sku ueber eine echte Windows-Stimme sprechen lassen, nicht ueber die NVDA-Bruecke. Dort konnte eine Zeile, die Sku laengst durch eine neuere ersetzt hatte, im Spiel haengen bleiben und viel spaeter doch noch gesprochen werden: Wer im Menue schnell einen Filter tippte, hoerte "g r" oder "g r e i f" erst nach "Menue geschlossen". Wer die Pfeiltaste hielt, hoerte nach dem letzten Eintrag noch zwei, drei uebersprungene. Und Chatzeilen, die waehrend des Blaetterns eintrafen, kamen bis zu 70 Sekunden zu spaet und ausser der Reihe. In einem eingeschickten Log waren das 24 von 524 Ansagen in einer halben Stunde. Das ist behoben: was Sku ersetzt oder abgebrochen hat, bleibt stumm. An den Regeln, was was unterbrechen darf, aendert sich nichts. Auch das Mischen bleibt: schiebt sich eine wichtige Ansage in eine Reihe wartender Zeilen (Chat, Statusmeldungen), spricht sie zuerst, danach geht die Reihe weiter, die aelteste Zeile zuerst. Nur was dabei aelter als 30 Sekunden geworden ist, wird verworfen.

Technisch: Libs/SkuVoice-1.0. C_VoiceChat.StopSpeakingText beendet nur die Aeusserung, die gerade SPIELT. Eine uebergebene, aber noch nicht gestartete erreicht es nicht, und alles, was uebergeben wird, waehrend eine andere noch im Client ist, wird dort geparkt und startet erst beim naechsten natuerlichen PLAYBACK_FINISHED - egal wie viele Stopps dazwischen liegen. Neu: ein gemeinsames Tor (mClientGate) fuer ALLE Uebergaben. Sku uebergibt dem Client hoechstens EINE Aeusserung; die naechste Zeile wartet in Skus eigener Warteschlange auf FINISHED/FAILED mit passender ID, wo queuereset, EndScope und CancelBttsOutput sie noch erreichen. Weil die Zeilen jetzt bei Sku warten, musste die queuereset-Regel ausgesprochen werden, die bisher der Client nebenbei erledigte: eine wartende Overwrite-Zeile ist ueberholt und faellt weg (mSkuVoiceQueueBTTS_Overwrite); eine wartende Zeile ohne queuereset wird hinter die neue Overwrite-Zeile gestellt, solange sie juenger als tBttsKeptMaxAge (30 s) ist. Alle fuenf Stopp-Stellen laufen ueber BttsStop: hat die Aeusserung im Client noch nicht gestartet, wird der Stopp vorgemerkt und 0.1 s nach ihrem STARTED aus OnUpdate zugestellt - nie aus dem STARTED-Handler selbst: ein StopSpeakingText von dort legte im Test die gesamte Sprachausgabe des Clients bis zum Neustart lahm (das alte Kill-Fenster tat genau das). Das ersetzt das Kill-Fenster aus v43.5 (dieselbe Idee mit geschaetzter Zeitspanne, nur an zwei Stellen) und das eigene Tor der Tipp-Echo-Spur. Sicherungen: 0.5 s ohne STARTED gibt das Tor frei (und schickt einen vorgemerkten Stopp trotzdem), nach drei Uebergaben ohne jedes STARTED schaltet das Tor ab, bis wieder eines kommt. Auf der NVDA-Bruecke kommen STARTED und FINISHED im Uebergabe-Frame, das Tor ist dort nie geschlossen - Verhalten unveraendert. Geprueft mit einem Offline-Nachbau des Clients (dev/rework-docs/voice-harness): alter Stand 27-33 verspaetete Aeusserungen in 3 Minuten Zufallslast, neuer Stand 0; Bruecken-Modell alt und neu identisch. Im Log: "stop deferred (handover not started)", "deferred stop fires", "client gate ttl", "queuereset kept", "STALE-DROP".

Folgefehler, im selben Zug behoben: die Taste "Audio Ausgabe beenden" (Strg+V) brach nur noch die gerade gesprochene Zeile ab, die wartenden liefen danach weiter - man musste je Zeile einmal druecken. Frueher lag der ganze Schwall schon im Client, und der eine Stopp traf alles; seit dem Tor warten die Zeilen bei Sku, und StopOutputEmptyQueue leerte diese Warteschlange nie. StopOutputEmptyQueue(true, true) ruft jetzt CancelBttsOutput: wartende Zeilen und wartende Tippzeichen weg, dann der Stopp. Die Aufrufer mit (true, nil) bleiben, wie sie sind - dort sollen wartende Chatzeilen ueberleben. Harness-Szenario "stopkey": alter Stand vier hoerbare Zeilen, neuer Stand eine (abgeschnitten).

Menue: "Ziel Menue" wurde nach dem Inhalt nachgesprochen

Einfach: Oeffnet sich das Menue nicht an der Wurzel, sondern gleich an einer bestimmten Stelle - beim Oeffnen einer Tasche, eines Haendlers oder Briefkastens, bei Umschalt+F9 und Umschalt+F10, bei den Schnellwahltasten -, dann war nach dem eigentlichen Inhalt noch "Ziel Menue" zu hoeren, der erste Eintrag der Menuewurzel. Also etwa "Tasche 1, Ziel Menue". Das ist behoben: du hoerst nur noch, wo du gelandet bist. "Menue geoeffnet" entfaellt bei diesen Oeffnungen; es wurde ohnehin sofort abgeschnitten, und der Oeffnen-Ton bleibt. Das normale Oeffnen des Menues ist unveraendert: "Menue geoeffnet", dann "Ziel Menue".

Technisch: SkuOptions:SlashFunc (SkuZOptions/Core.lua) oeffnet ein geschlossenes Menue ueber den OnClick von OnSkuOptionsMain und laeuft danach den Pfad ab. Der Oeffnen-Zweig sprach "Menue geoeffnet" als Overwrite und stellte Menu[1].name als wartende Zeile dahinter. Die Ansage des Pfadlaufs setzte ein queuereset, und seit dem Client-Tor dieser Version behaelt queuereset wartende Zeilen ohne Overwrite hinter der neuen Zeile

line(s)"). Behoben an der Quelle statt durch Unterdruecken: mit einem Pfad (mindestens zwei Felder) setzt SlashFunc SkuOptions.tOpeningForPathWalk um den Oeffnen-Aufruf, der Oeffnen-Zweig spricht dann nichts. Das Flag wird direkt nach dem Aufruf geloescht, auch bei einem Fehler (pcall, Fehler wird weitergereicht). Findet der Pfad nichts und das Menue steht an der Wurzel, holt SlashFunc die Ansage nach und schreibt "menu: path walk found nothing" ins Debug-Log. Zwischenstationen des Pfads waren schon vorher stumm.

Tastaturecho mit einer echten Windows-Stimme: die lange Pause zwischen den Buchstaben ist weg

Einfach: Wer Sku mit einer echten Windows-Stimme nutzt (nicht mit der NVDA-Bruecke), hoerte beim Tippen im Chat nach jedem Buchstaben eine Pause von einer halben bis ganzen Sekunde - etwa ein Buchstabe pro Sekunde, egal wie schnell die Stimme eingestellt war. Eine langsamere Stimme machte nur den Buchstaben laenger, die Pause blieb gleich. Diese Pause ist jetzt weg, die Buchstaben folgen dicht aufeinander. Es wird weiterhin jeder Buchstabe gesprochen, auch doppelte, und nach Escape kommt kein Buchstabe mehr nach. Dieselbe Pause steckte auch zwischen Zeilen, die hintereinander warten (Teile eines Questtexts, mehrere Chatzeilen); dort faellt sie kaum auf, ist aber ebenfalls verkuerzt. Auf der NVDA-Bruecke aendert sich nichts.

Technisch: Der Client meldet VOICE_CHAT_TTS_PLAYBACK_FINISHED fest 0.5 bis 1 s NACH dem Ende des Tons (Bookmark "End") und startet vorher nichts Neues. Frueher uebergeben hilft nicht (v43.5e: die Aeusserung wird nur geparkt und ist dann nicht mehr abbrechbar). Was den Client sofort freigibt, ist ein Stopp. Neu in Libs/SkuVoice-1.0: kam fuer unsere Aeusserung erst "Start" und dann "End" und wartet etwas (Echo-Spur oder Queue), schickt OnUpdate nach tTailCutDelay (0.03 s) ein StopSpeakingText und uebergibt nach tTailCutHold (0.06 s). Nie aus dem Bookmark-Handler. Ein "End" vor "Start" (kommt bei der ersten Aeusserung nach einem Stopp vor) zaehlt nicht. Wartet nichts, endet die Zeile wie bisher von selbst. Der Schnitt setzt die Bruecken-Marke nicht, sperrt den "#queue > 1"-Bypass einmal und raeumt den Dubletten-Eintrag selbst ab (eine gestoppte Aeusserung meldet kein FINISHED). Gemessen im Nachbau: Buchstabentakt 1.15 s -> 0.73 s. Zum Probieren, nur fuer die Sitzung: /skudebug tts tail <delay> <hold>, /skudebug tts tail off. Im Log: "tail cut -> StopSpeakingText".

Sprache anderer Addons brachte das Tastaturecho durcheinander

Einfach: Sprach ein anderes Addon (oder ein /run-Befehl) ueber die Sprachausgabe des Spiels, waehrend du getippt hast, konnte danach ein Buchstabe nach "abgebrochen" nachkommen, also nach dem Schliessen des Chatfelds. Nur mit einer echten Windows-Stimme. Das ist behoben: solange fremde Sprache laeuft, wartet Sku mit seinen Buchstaben und Chatzeilen; schliesst du das Feld, werden die wartenden Buchstaben verworfen. Ansagen, die ohnehin alles unterbrechen (Menue, "abgebrochen", Prioritaetszeilen), unterbrechen auch die fremde Sprache wie bisher sofort.

Technisch: Das Client-Tor kannte nur Skus eigene Uebergaben. Eine fremde Aeusserung (Mitschnitt: id 403, geparkt, 11 s spaeter unter dem ersten Buchstaben gestartet) liess den naechsten Buchstaben ohne STARTED stehen, die 0.5-s-TTL gab ihn auf, ein zweiter ging in den Client und uebernahm das STARTED des ersten. Neu (mForeign, tMaxSeenId, tClientGateFreedAt): ein STARTED, auf das niemand wartet, oder eines mit einer id unter der hoechsten vor unserer Uebergabe gesehenen, ist fremd - wird nie als unsere id uebernommen, und solange es laeuft, wird nichts uebergeben (Stille-Grenze 8 s; unsere eigenen Stopps beenden es). Auf der Bruecke sind alle ids 0, "aelter" ist deshalb echt-kleiner und greift dort nie. Im Frame, in dem eine unserer Aeusserungen FINISHED meldet, wird nichts uebergeben: eine geparkte fremde startet genau auf dieses FINISHED und muss zuerst gesehen werden. Harness-Szenario "foreign": alter Stand vier Buchstaben nach "abgebrochen", neuer Stand keiner. Im Log: "BTTS foreign utterance", "BTTS foreign cleared".

Einfuegen in ein Eingabefeld: "Eingefuegt" statt Buchstabensalat

Einfach: Wer mit Strg+V Text in die Chatzeile oder in ein Eingabefeld von Sku einfuegte, bekam den ganzen eingefuegten Text Buchstabe fuer Buchstabe vorgelesen. Jetzt sagt Sku einmal "Eingefuegt". Den Inhalt des Feldes liest du wie gewohnt mit Pfeil hoch oder Pfeil runter. Normales Tippen ist unveraendert, auch schnelles. Fuegst du nur ein oder zwei Zeichen ein, werden diese weiterhin als Zeichen gesprochen.

Technisch: Ein Einfuegen liefert die Zwischenablage als einzelne OnChar-Aufrufe, alle im selben Frame. tSpeakTypedChar (SkuZOptions/Core.lua) zaehlt die Zeichen je Frame (GetTime() ist innerhalb eines Frames konstant): ab dem dritten gilt die Folge als Einfuegen - CancelEcho wirft die schon wartenden Zeichen weg (uebergeben ist im selben Frame noch keines, die Pumpe laeuft im OnUpdate), dann einmal SpeakEcho("Eingefuegt"), alle weiteren Zeichen des Frames werden ignoriert. Schwelle 3, weil zwei Anschlaege bei niedriger Bildrate in einen Frame fallen koennen. Gilt fuer AttachInputEcho (Chat) und das Sku-Eingabefeld. Im Log: "inputEcho paste erkannt".