Sku v43.2 - Patchnotes

Ueberblick

Neu

Aenderungen

Fehlerbehebungen

Schwimmen und Fliegen: die Neigungssperre beendet das ungewollte Abtauchen

Einfach: Beim Schwimmen oder Fliegen zog jede automatische Drehung zum Funkfeuer ein kleines Stueck nach unten - ueber eine Strecke summierte sich das, bis man unbemerkt unter Wasser oder am Boden war. Jetzt sperrt Sku die Neigung, sobald du schwimmst oder fliegst: du bewegst dich exakt waagerecht, und Leertaste und X tragen dich weiterhin nach oben und unten. Wenn dich doch etwas schief stellt - etwa der automatische Anflug beim Interagieren mit einem NPC -, richtet Sku dich aktiv wieder gerade: beim Oeffnen des NPC-Fensters, kurz nach jeder Drehung und immer, wenn du Steigen oder Sinken drueckst. Ab Werk an; wer beim Schwimmen mit der Maus per Neigung tauchen will (Restsehvermoegen), schaltet es unter Einstellungen -> Allgemein ab. Dazu der neue Tastenbefehl "Neigungssperre" (Strg+Umschalt+N) zum manuellen Sperren und Loesen.

Technisch: Drei Bausteine. Erstens deckelt die Konsolenvariable pitchlimit 0 die Bewegungsneigung des Charakters (die Technik der Addons LevelFlight und FlightHUD) - dauerhaft gesetzt statt um jeden Dreh-Impuls herum, denn genau dieses Umschalt-Rennen hat fruehere Versuche scheitern lassen. pitchlimit ist beschreibbar, aber nicht lesbar; bei jedem Login wird deshalb blind der Standard 88 wiederhergestellt, damit nie eine Sperre haengenbleibt. Zweitens haelt die Sperre nur, was da ist: engine-gesteuerte Bewegung wie der Interagieren-Anflug neigt den Charakter trotzdem, und danach gibt es keine Tastatur-Eingabe, die die Neigung wieder anhebt. Das aktive Geradestellen benutzt genau den Transfer, der urspruenglich den Fehler verursachte: ResetView/SetView schnappt die Kamera auf die bekannte fast-waagerechte Voreinstellung, ein Mouselook-Impuls uebertraegt sie auf den Charakter, und die Sperre deckelt den kleinen Rest auf null. Ausloeser sind das NPC-Fenster, jede Drehung (um 0,5 s verzoegert, weil die Engine die Gierung erst einen Frame spaeter anwendet - ein sofortiger zweiter Impuls wuerde die Drehung aufheben) und per hooksecurefunc die Steig-/Sinkfunktionen JumpOrAscendStart, AscendStop, SitStandOrDescendStart und DescendStop - unabhaengig davon, auf welchen Tasten sie liegen. Drittens ein Neigungsmesser fuers Log: gemessene Horizontalgeschwindigkeit geteilt durch GetUnitSpeed ist der Kosinus der Bahnneigung - der einzige Messweg, den dieser Client hergibt (GetUnitPitch wurde mit Patch 7.1 entfernt und fehlt auch hier). Er misst die Bahn, nicht die Koerperneigung, und dient nur der Diagnose.

Der Cursor bleibt in der Tasche auf dem Gegenstand

Einfach: Wer in der Taschenliste einen Gegenstand rechts anklickte - benutzen, anlegen, an einen Haendler verkaufen, eine Verzauberung anwenden -, stand danach schlagartig auf dem ersten Eintrag der ganzen Liste. Bei Gegenstaenden, die sofort verschwinden, fiel das kaum auf, weil die Liste sich ohnehin neu sortiert; bei allem anderen war es einfach ein Verlust der Position. Jetzt bleibt der Cursor auf dem Gegenstand, auf dem man gearbeitet hat, und wenn der Gegenstand die Tasche verlaesst, landet man an seinem Platz - also auf dem, was nachgerueckt ist.

Technisch: Ursache war nie ein Verrutschen von Indizes, sondern die dritte Zeile des Rechtsklick-Makros, "/script SkuCore:CheckFrames()". Sie stammte aus der Zeit vor der ereignisgesteuerten Bestaetigung und lief BEIM TASTENDRUCK - also bevor die Aktion ueberhaupt etwas veraendert hatte, bei einer Aktion mit Zauberzeit sogar Sekunden davor. Sie baute damit veraltete Daten neu auf und kostete dabei die Position. Entfernt; die Auffrischung gehoert allein der von BAG_UPDATE getriebenen Bestaetigung, die erst aufbaut, wenn die Taschen wirklich ruhig sind, und den Cursor dann ueber Taschen-Fach und Gegenstands-ID wieder anheftet. Zusaetzlich merkt sich CheckFrames beim Neuaufbau nicht mehr nur die Zeilennummer, sondern auch den Namen des Eintrags, und sucht ihn in der neu gebauten Liste - die Zeilennummer allein stimmt naemlich nicht mehr, sobald die Liste zwischendurch eine andere Form hatte.

Verzauberungen, Koeder und Oele: die Liste aktualisiert sich nach dem Zauber

Einfach: Eine Verzauberung, ein Angelkoeder, ein Waffenoel, ein Ruestungsset oder das Entzaubern veraendern die Taschen erst, wenn der Zauber fertig ist - oft fuenf Sekunden nach dem Klick. Bis dahin hatte Sku laengst aufgegeben: die Liste blieb veraltet, und der Cursor stand irgendwo. Jetzt wartet Sku den Zauber ab, meldet danach den Gegenstand einmal und laesst den Cursor darauf stehen. Wer waehrenddessen selbst weiterblaettert, behaelt seine eigene Position - dann mischt sich Sku nicht mehr ein.

Technisch: Das beim Rechtsklick geoeffnete Bestaetigungsfenster lief nach 2,5 Sekunden ab. UNIT_SPELLCAST_START/-CHANNEL_START schieben seine Frist jetzt bis zum Ende des Zaubers und behalten dabei den beim Klick gemerkten Anker, sodass das Wiederanheften danach genau den behandelten Gegenstand trifft. Bewusst ohne Zauberliste: dass das Fenster offen ist, ist bereits der Beleg, dass der Zauber zu dieser Aktion gehoert. Zwei harte Sperren, beide an einem echten Fall gelernt: der Zauber muss innerhalb einer Sekunde auf den Klick folgen ("/use" startet ihn im selben Frame), und die Verlaengerung greift nur ein einziges Mal. Ohne sie schob das 22 Sekunden lange Angeln die Frist immer weiter vor sich her, und das Fenster starb nie.

Der Bestaetigungsdialog kostet nicht mehr die Position

Einfach: Wer eine Verzauberung auf einen bereits verzauberten Gegenstand anwendet, bekommt von Blizzard die Rueckfrage "Bestehende Verzauberung ersetzen?". Nach "Ja" oder "Nein" stand man anschliessend ganz oben in der Taschenhierarchie, also auf "Tasche 1" statt auf dem Gegenstand. Jetzt fuehrt beide Antworten wieder zum Gegenstand zurueck, und er wird einmal angesagt.

Technisch: Der Dialog ist ein modales Fenster zwischen dem Klick und seiner Wirkung und zerstoerte die Position gleich zweifach: die 2,5-Sekunden-Frist lief waehrend des Dialogs ab, und Sku verankert das Menue IM Dialog, sodass beim Schliessen nichts mehr da war, wohin zurueckgekehrt werden konnte - der allgemeine Einstieg nahm dann das einzige offene Fenster und landete oben in der Taschenliste. SkuBagPostActionPopupGate haelt das Fenster offen, solange der Dialog steht (bis 30 Sekunden), und stoesst beim Schliessen die Bestaetigung an. Genau die ist das richtige Werkzeug, weil sie beide Antworten abdeckt: "Nein" erzeugt weder Zauber noch Taschenaenderung, es gaebe also sonst gar nichts, was den Cursor zuruecklegen koennte. Solange der Dialog steht, haelt sich die Bestaetigung komplett zurueck - sonst risse eine unbeteiligte Taschenaenderung (einsammelnde Beute, ein abgeschlossener Handel) den Cursor mitten aus dem Dialog heraus.

Der Tippfilter in der Taschenliste loest sich wieder

Einfach: Wer in der Taschenliste einen Namen tippt, filtert die Liste auf die Treffer. Dieser Filter loeste sich bisher nicht mehr, sobald man den gefilterten Gegenstand benutzt hatte: auch Pfeil links und wieder rechts brachten die volle Liste nicht zurueck, nur das Schliessen der Taschen half. Jetzt raeumt jede dieser Tasten den Filter wieder ab, so wie man es gewohnt ist. Passt auf den Filter gar nichts, bleibt die Liste weiterhin leer und die Pfeiltasten wiederholen nur den getippten Filter - genau daran hoert man, dass es keinen Treffer gibt.

Technisch: SkuOptions:ClearFilter vergass nur den getippten Text; die von ApplyFilter eingesetzte gefilterte Kinderliste blieb im Baum stehen, bis irgendetwas sie vollstaendig ersetzte - und eine aus Spielfenstern gebaute Ebene wie die Taschen kann sich nicht an Ort und Stelle auffrischen, sie braucht einen kompletten Neuaufbau. Jahrelang verdeckt vom erzwungenen CheckFrames im Makro (siehe oben), fiel es sofort auf, sobald eine Aktion die Taschen gar nicht veraendert. ClearFilter stellt die Liste jetzt wirklich wieder her, samt Vor- und Rueckwaertsverkettung, und zwar an dem Knoten, den sie gefiltert hat, nicht am gerade aktuellen.

Escape schloss das Menue nicht, wenn man direkt auf einem Questobjekt stand

Einfach: Wer mit ungefaehr null Metern Abstand vor einem Questobjekt stand und das Menue mit Escape schloss, bekam das Questfenster sofort wieder aufgezogen - und das endlos. Das Menue liess sich in dieser Lage praktisch nicht mehr schliessen. Jetzt werden erst die offenen Spielfenster geschlossen und danach das Menue selbst.

Technisch: Das Menue versteckte sich zuerst und arbeitete danach die offenen Interaktionsfenster ab. Der Quest-Rahmen wurde dadurch geschlossen, waehrend das Spiel den Gegenstand in Reichweite weiter meldete, und zog sich sofort wieder auf. Die Reihenfolge ist jetzt umgekehrt und durch einen Zaehler abgesichert, den "/skucheck menu" ausliest: eine Verletzung dieser Reihenfolge faellt damit auf, ohne dass jemand zufaellig genau auf diesem Fleck stehen muss.

Weniger doppelte Neuaufbauten beim Fensterschliessen

Einfach: Ein einziges Escape loeste bisher bis zu sechs komplette Neuaufbauten der Menuedaten aus, weil mehrere Fenster gleichzeitig zugehen und Blizzards Questfenster allein schon vier Unterbereiche versteckt. Das kostete spuerbar Zeit. Jetzt laeuft pro Bild genau ein Neuaufbau. Ausserdem konnte die fuer den Kampf vorgehaltene Taschenliste veralten, wenn ein Questfenster geschlossen wurde, waehrend die Taschen offen waren - ein Fehler, der erst spaeter im Kampf aufgefallen waere.

Technisch: Die Hide-Pfade laufen ueber SkuCore:CheckFramesCoalesced, dessen Sperre einmal pro Bild oeffnet; der eigentliche Durchlauf ist ohnehin um 0,01 s verzoegert und liest den Endzustand, sieht also genau das, was der letzte Aufruf der Serie gesehen haette. Die OnShow-Seite bleibt bewusst aussen vor. Die Buchhaltung in GENERIC_OnClose hat eine eigene Sperre bekommen: sie hing vorher am Rueckgabewert derselben geteilten Sperre, und da die Quest-Unterbereiche zuerst feuern, verbrauchten diese sie und die Buchhaltung - unter anderem das Auffrischen der Kampf-Taschenliste - fiel aus.

Sprachausgabe: Ansagen bleiben nicht mehr stumm

Einfach: Beim Navigieren blieb die Sprachausgabe immer wieder fuer eine Weile still - ein Pfeiltastendruck las den Eintrag einfach nicht vor, obwohl es ruhig war und nichts anderes lief. Besonders zuverlaessig passierte das, wenn man eine Liste auf einen einzigen Treffer filterte und dann schnell zwischen dem Filter und diesem Treffer hin und her ging: nach ein paar Wechseln blieb der Treffer dauerhaft stumm, auch wenn man eine Sekunde wartete. Beides ist behoben.

Technisch: Zwei voneinander unabhaengige Ursachen, beide unterhalb der Warteschlange - Sku selbst hatte jede Ansage sauber abgeschickt, in einem Mitschnitt ueber 95 Minuten kam auf jeden Tastendruck genau ein SpeakText mit STARTED. Erstens wurde dieselbe Zeile bis zu viermal innerhalb einer Sekunde erneut ausgegeben, weil eine ueberfluessige Fensterpruefung den Menueeintrag noch einmal ansagt; 95 von 1512 Ausgaben waren solche Wiederholungen. Jede bringt ihr eigenes "queuereset" mit, also ein StopSpeakingText, und das erreicht den Screenreader wirklich - die Zeile wurde also mitten im Wort abgeschnitten und neu begonnen, und wenn dabei die Neuausgabe verlorenging, blieb nichts uebrig. Die vorhandene Dopplungssperre konnte das nicht auffangen: sie haengt an

VOICE_CHAT_TTS_PLAYBACK_FINISHED, und ueber die Screenreader-Bruecke kommen STARTED und FINISHED noch im selben Bild zurueck - dort ist die Sperre also immer leer und kann gar nicht greifen. Neu ist eine zeitbasierte Sperre, die eine unmittelbar folgende identische Zeile innerhalb einer Sekunde verwirft, und zwar samt ihrem queuereset; nur den Text zu verwerfen wuerde die laufende Ansage trotzdem abschneiden und nichts an ihre Stelle setzen. Verglichen wird ausschliesslich mit der direkt davor ausgegebenen Zeile, ein echtes erneutes Vorlesen kann sie also nicht schlucken, und sie greift nur, wenn die erste Ausgabe wirklich zu spielen begonnen hatte.

Zweitens war der Cache-Brecher wirkungslos geworden. Der Client legt erzeugte Sprachdaten nach Text ab und spielt sie bei einer Wiederholung ab, ohne die Stimme erneut aufzurufen - ueber eine Bruecke ist dieses Abspielen still. Dagegen wurde bisher ein wechselndes <bookmark> angehaengt, aber der Client entfernt Auszeichnungen und schluesselt nur ueber den gesprochenen Text: im Mitschnitt trug jede einzelne Ausgabe ihre eigene Markierung und der Treffer verstummte trotzdem.

Der urspruengliche Brecher hatte echte Zeichen variiert und funktionierte; der Wechsel auf eine Markierung sollte die Betonung schonen und hat dabei genau den Fehler wieder hereingeholt, gegen den er geschrieben war. Angehaengt wird jetzt wieder echter Text: eine wechselnde Folge von 1 bis 64 geschuetzten Leerzeichen hinter dem letzten Wort, wo sie weder hoerbar ist noch die Betonung faerben kann.

Satt: nur noch ein Eintrag in der Zauberauswahl

Einfach: Wer eine Aura auf den Satt-Buff bauen wollte, fand in der Zauberauswahl zwei Eintraege, die beide "Satt" gesprochen wurden. Nur einer davon konnte je ausloesen, der andere war eine Karteileiche - welchen man erwischte, war reine Glueckssache und nicht hoerbar. Es gibt jetzt nur noch einen Eintrag, und der ist der richtige. Eine bereits gespeicherte Aura, die auf den falschen zeigte, wird beim naechsten Anmelden einmalig umgehaengt und funktioniert danach.

Technisch: Auren werden seit v43.0 ueber die englische Identitaet eines Zaubers gefuehrt, damit dieselbe Aura in jeder Sprache passt. In der mitgelieferten Zauberdatenbank tragen zehn Zeilen den englischen Namen jedoch in

ANFUEHRUNGSZEICHEN - 44097 bis 44106 sowie 69559 und 65365 fuehren den Namen einschliesslich zweier Anfuehrungszeichen, wo die anderen 65 Zeilen ihn ohne fuehren. Damit entstand eine zweite Identitaet hinter demselben deutschen Namen, und die Menue-Unterscheidung haengt in so einem Fall die englische Identitaet an: der eine Eintrag hiess "Satt (Well Fed)", der andere genauso, nur mit zwei zusaetzlichen Anfuehrungszeichen um Well Fed herum.

Anfuehrungszeichen spricht die Sprachausgabe nicht mit, also klangen beide Eintraege identisch. "Satt" ist der einzige der 26.650 deutschen Namen im Datenbestand, dessen zwei Identitaeten sich in nichts als diesen Zeichen unterscheiden. Der Name wird jetzt beim Bilden der Identitaet entklammert, und zwar auf BEIDEN Seiten - in der Werteliste und bei jeder Aufloesung eines laufenden Ereignisses -, denn nur eine Seite zu aendern wuerde einen gespeicherten Wert erzeugen, den kein Ereignis mehr trifft. Entklammert wird ausschliesslich, was an BEIDEN Enden ein Anfuehrungszeichen traegt; die 17 uebrigen Zeilen mit Anfuehrungszeichen mitten im Namen (etwa "Goblinbummkiste" oder das Parfuem "TRIUMPH") behalten sie, weil sie dort zum Namen gehoeren. Eine einmalige Wanderung haengt gespeicherte Auren um.

Waffenverzauberungen sind in der Zauberauswahl erkennbar

Einfach: Ein Angelkoeder, ein Schaerfstein oder ein Waffenoel sind keine Buffs, sondern eine Verzauberung auf der Waffe. Sie tauchen in keiner Bufliste des Spiels auf und loesen kein Aura-Ereignis aus - eine Aura auf "Ereignis = Aura verloren und Zauber name = Angelfertigkeit +75" konnte deshalb nie ausloesen, obwohl der Eintrag in der Auswahl steht und voellig normal klingt. Solche Eintraege tragen jetzt in allen Auswahllisten den Zusatz "(Waffenverzauberung)", damit hoerbar ist, worum es sich handelt. Wer darauf reagieren will, nimmt entweder das Ereignis

"Waffenverzauberung abgelaufen" oder die Bedingung "Deine Waffenverzauberung Haupthand". In der Ansage einer ausgeloesten Aura wird der Zusatz nicht mitgelesen.

Technisch: Die Werteliste des Attributs "Zauber name" ist die komplette Zauberdatenbank, also auch Zeilen, die den Spieler nur als temporaere Waffenverzauberung erreichen - der Koeder ist Zauber 8084 hinter Verzauberungs-ID 265. Die betroffenen Identitaeten werden jetzt beim Aufbau der Listen ermittelt (jede Zauber-ID der Identitaet wird von der Verzauberungsdatenbank referenziert) und bekommen den Zusatz. Bewusst GEKENNZEICHNET statt entfernt: es sind 395 Identitaeten, und sie sind nicht alle wirkungslos - "Feurige Waffe", "Scharfrichter" und "Unheilige Staerke" sind Prozeduren von Verzauberungen, die sehr wohl unter genau diesem Namen im Kampfprotokoll erscheinen. Sie zu entfernen haette funktionierenden Auren ihre einzige Benennungsmoeglichkeit genommen. Der Zusatz nutzt denselben Mechanismus wie die englische Unterscheidung, faellt also in der Sprachausgabe einer ausgeloesten Aura wieder weg.

Waffenverzauberungen werden angesprochen wie Zauber

Einfach: Fuer einen Schadenszauber ueber Zeit schreibt man "Ereignis gleich aura verloren" und "Zauber name gleich <Zauber>" - das Ereignis sagt selbst, worum es geht. Bei einer Waffenverzauberung ging das nicht: den Angelkoeder konnte man nur ueber "Deine Waffenverzauberung Haupthand" benennen, und das ist eine Zustandsfrage, keine Ereignisfrage. In der Fassung "enthaelt" konnte so eine Aura sogar NIE ausloesen - wenn das Ereignis kommt, ist die Verzauberung bereits weg, also enthaelt die Liste sie nicht mehr. Nur die verdrehte Fassung "enthaelt nicht" funktionierte. Jetzt traegt das Ereignis den Namen der Verzauberung selbst, und die Aura wird genau wie bei einem Zauber geschrieben: "Ereignis gleich Waffenverzauberung abgelaufen" und "Zauber name gleich Angelfertigkeit +75". "enthaelt nicht" funktioniert weiter.

Technisch: Die beiden erzeugten Ereignisse WEAPON_ENCHANT_REMOVED und

WEAPON_ENCHANT_UPDATE legten den Namen der HAND in Feld 13 - und Feld 13 ist das Zauber-name-Feld. Eine Bedingung auf "Zauber name" verglich also gegen "Haupthand", und eine Ausgabe "Zauber name" sagte "Haupthand" statt der Verzauberung. Dort steht jetzt die Verzauberung: Feld 12 bekommt ihre Zauber-ID, Feld 13 ihren Namen, beides ueber dieselben Resolver, aus denen auch die Auswahlliste gebaut wird - der gespeicherte Wert ist derselbe wie bei der Waffenverzauberungs-Bedingung. Beim Entfernen wird die Verzauberung gemeldet, die DA WAR; das ist die Identitaet, die gemeint ist. Bestehende Auren koennen dadurch nicht verstummen: "Haupthand", "Nebenhand", "Main Hand" und "Off hand" kommen in allen 49.117 Zeilen der Zauberdatenbank kein einziges Mal als Zaubername vor, eine Bedingung auf "Zauber name" konnte bei diesem Ereignis also ohnehin nie zutreffen. Die Hand ist nicht verloren, sie zieht in ein eigenes Feld mit eigener Bedingung und eigener Ausgabe um ("Waffenverzauberung Hand"), gespeichert als sprachneutrale Kennung, damit eine geteilte Aura in jeder Sprache dieselbe Hand meint. NICHT gemacht wurde der naheliegende andere Weg - die Zustandsliste beim Entfernen mit der auslaufenden Verzauberung zu fuellen: die Liste ist geteilt, sie wuerde in diesem Durchlauf JEDE andere Aura anluegen, ein "enthaelt nicht"-Gatter wieder scharf schalten und damit doppelte Ansagen erzeugen, und sie wuerde der Restdauer widersprechen, die beim Entfernen bewusst auf 0 gesetzt wird. Zusaetzlich meldet /skucheck auras die Kombination "Entfernt-Ereignis plus enthaelt" jetzt als Aura, die nie ausloesen kann.

Nebenbei behoben: aenderte sich nur die Nebenhand, wurde das Ereignis trotzdem als "Haupthand" gemeldet.

Das Ende einer Waffenverzauberung wird sofort erkannt

Einfach: Dass ein Angelkoeder oder ein Gift ausgelaufen ist, meldet das Spiel nicht - Sku sieht alle 0,25 Sekunden nach. Die Ansage kam deshalb bis zu eine viertel Sekunde zu spaet. Jetzt kommt sie im Moment des Ablaufs.

Technisch: Wie lange eine Verzauberung noch haelt, steht in dem Moment fest, in dem man sie sieht - GetWeaponEnchantInfo liefert die Restzeit in Millisekunden. Der Ticker merkt sich daraus den naechsten Ablaufzeitpunkt, und der Frame-Treiber vergleicht eine Zahl pro Frame und ruft dann genau den normalen Spieler-Ticker auf. Das ist dieselbe Bauart wie der in v43.0 eingefuehrte Dauer-Terminplaner und kostet kein zusaetzliches Abfragen. Doppelte Ansagen sind ausgeschlossen, weil der Ticker nur meldet, wenn sich sein gemerkter Stand wirklich geaendert hat. Bewusst NICHT gemacht: den Ticker auf jeden Frame zu stellen - das waere fuenfzehnmal so viel Abfragerei fuer denselben Gewinn.

Umschalten in einer gefilterten Liste sagt wieder den neuen Zustand an

Einfach: Grenzt man eine Liste per Tippfilter ein und drueckt dann Enter auf einem Ein/Aus-Eintrag, wird der Filter entfernt - das ist so gewollt. Der Eintrag wurde auch richtig umgeschaltet, nur zu hoeren war das nicht: der Cursor sprang dabei an den Anfang der Liste, und angesagt wurde der erste Eintrag statt des neuen Zustands. In den Auren-Ausgaben spielte zusaetzlich die Hoerprobe des ersten Eintrags an. Jetzt bleibt man auf dem Eintrag stehen, den man umgeschaltet hat, und hoert seinen neuen Zustand.

Technisch: Enter entfernt den Filter, BEVOR es die Aktion ausfuehrt - der Menue-Knoten ruft dafuer ApplyFilter("") auf. Dessen Aufraeumen endete mit einem pauschalen OnFirst() auf der Ebene, der Cursor wanderte also in JEDEM Fall an den Listenanfang. Die Umschaltung selbst war nie betroffen: sie arbeitet auf dem Knoten selbst (actionInPlace), nicht auf dem Cursor. Falsch war nur, was danach vorgelesen wurde - und OnFirst loeste beim Landen zusaetzlich das OnEnter des ersten Eintrags aus, was bei den Auren-Toenen die Hoerprobe ist. ApplyFilter("") folgt jetzt derselben Regel, der ClearFilter schon folgt: die wiederhergestellte Liste enthaelt dieselben Knoten-Objekte, ein Cursor auf einem echten Eintrag bleibt also gueltig; nur die kuenstliche Zeile "Filter;<getippt>" hat dort keinen Platz mehr, und allein fuer sie laeuft weiterhin das vollstaendige OnFirst() samt OnEnter, damit die Hoerprobe beim Landen nicht verloren geht. Ohne aktiven Filter war ApplyFilter("") immer schon wirkungslos - deshalb hat das Umschalten in einer ungefilterten Liste nie gefehlt; beide Faelle verhalten sich jetzt gleich. Nebenwirkung derselben Regel: Backspace laesst den Cursor jetzt auf dem Eintrag stehen, auf dem er stand, statt an den Listenanfang zu springen.

Dungeonbrowser: eine angenommene Einladung fuehrt nicht mehr in den Browser

Einfach: Wer im Dungeonbrowser angemeldet war und dann eine Gruppeneinladung annahm, stand danach ohne einen einzigen Tastendruck im Dungeonbrowser: das Menue ging von selbst wieder auf, der Cursor stand auf "Nicht angemeldet". Fuer sehende Spieler passiert an dieser Stelle nichts - Blizzards Gruppensuche-Fenster geht beim Annehmen einer Einladung nie auf. Jetzt bleibt es auch bei Sku still: man bleibt dort, wo man vorher war.

Technisch: Zwei Wege fuehrten dorthin, beide sind jetzt zu. (1) Sobald der Server die eigene Anmeldung loescht - genau das tut er, wenn man einer Gruppe beitritt -, kommt LFG_LIST_ACTIVE_ENTRY_UPDATE, und der Browser baute daraufhin seinen Menuepunkt neu auf. Dieser Neuaufbau endete mit einem SlashFunc auf den eigenen Menuepfad, und der oeffnet ein GESCHLOSSENES Menue wieder und steigt hinein. Er laeuft jetzt nur noch, wenn das Menue offen ist UND der Cursor tatsaechlich im Dungeonbrowser steht - nur dann muessen die neu gebauten Eintraege ueberhaupt wieder unter den Cursor gelegt werden. Faellt er aus, kostet das nichts: der Menuepunkt ist "dynamic" und baut sich beim naechsten Betreten ohnehin neu auf. Damit kann auch keine Anmeldungsaenderung, die man nicht selbst ausgeloest hat (Ablauf, Aenderung durch den Gruppenanfuehrer), einen mehr aus den Taschen in den Browser reissen. (2) Eine drittel Sekunde nachdem das Einladungsfenster verschwunden ist, prueft der Browser, ob er sich wieder oeffnen soll. Er fragte dabei nur "ist gerade irgendein Gruppensuche-Fenster offen?" und machte daraus ein Oeffnen. Jetzt wird beim EINTREFFEN der Einladung gemerkt, was vorher da war, und nur genau das wird wiederhergestellt. Hat die Einladung in eine Gruppe gefuehrt, geschieht gar nichts mehr - weder oeffnen noch schliessen.

Neuer Tastenbefehl: den vollstaendigen Tooltip des Ziels vorlesen

Einfach: Bei einem Zielwechsel sagt Sku eine feste, kurze Auswahl an - Name, Stufe, Elite oder Selten, dazu die zweite Tooltip-Zeile mit der Kreaturenart. Alles, was darunter im Tooltip steht, war bisher gar nicht erreichbar: die Fraktionszeile, die PvP-Kennzeichnung und vor allem das, was die Jaegerfaehigkeit Tierkunde bei einem Wildtier offenlegt - Familie, Nahrung und ob es zaehmbar ist. Der neue Tastenbefehl (Standard: Strg+Umschalt+V) liest auf Wunsch den kompletten Tooltip vor. Er wirkt ausschliesslich auf Tastendruck: die normale Zielansage bleibt unveraendert kurz, und wer die Zusatzinformation nicht braucht, hoert nie etwas davon. Genau deshalb gibt es dafuer auch keine Option - der Tastendruck selbst ist die Nachfrage. Ist kein hartes Ziel vorhanden, gilt der Befehl dem aktuellen Soft-Ziel, sodass sich auch etwas beschreiben laesst, auf das man sich noch gar nicht festgelegt hat. Umzubelegen unter Sku Tastenbelegung, Ziel und Soft Targeting.

Technisch: Idee, Nachweis und Referenzumsetzung stammen von ZenqFR, aus dem Begleit-Addon SkuBeastLore (github.com/ZenqFR/Sku-BeastLore); die Tierkunde-Ausgabe ist dort an einem echten Jaeger getestet worden. Hier ist die Funktion nativ gegen Skus eigene Schnittstellen neu gebaut, damit kein zusaetzliches Addon noetig ist. Die Tierkunde-Zeilen erzeugt der Client selbst im Unit-Tooltip; kein Lua der Blizzard-Oberflaeche baut sie, und keine Programmschnittstelle liefert sie einzeln - den Tooltip zu lesen ist der einzige Weg dorthin. Deshalb ist eine getrennte Option nur fuer die Jaegerinformation auch nicht moeglich: die Zeilen liessen sich nur ueber sprachabhaengigen Textvergleich herausloesen. SkuMob:OutputTargetTooltip loest target, softenemy, softfriend und softinteract der Reihe nach auf und liest ueber Skus gemeinsam genutzten SkuScanningTooltip. Weil dieser Frame geteilt ist - Taschen, Auktionshaus, Chatlinks und Questtexte lesen denselben -, wird davor UND danach geleert und der Besitzer exakt so wiederhergestellt, wie SkuCore ihn beim Anmelden setzt.

Quests verfolgen und wieder abwaehlen

Einfach: Im Menue jeder Quest steht jetzt als letzter Eintrag "Quest verfolgen". Enter schaltet ihn um, der Cursor bleibt stehen, und der neue Zustand wird sofort angesagt

Markierung auf der Mini- und der Weltkarte. Wer noch etwas sieht, findet Questziele damit schneller; wer nichts sieht, hat von den Markern nichts. Deshalb laesst sich der Eintrag komplett abschalten - unter Sku Einstellungen, SkuQuest, "Eintrag Quest verfolgen anzeigen"; ab Werk ist er an. Er erscheint nur bei Quests im eigenen Questlog, denn eine Quest aus der Questdatenbank hat man noch gar nicht. Zwei Grenzen setzt das Spiel selbst: in The Burning Crusade lassen sich hoechstens fuenf Quests gleichzeitig verfolgen, und eine Quest ganz ohne Ziele gar nicht. In beiden Faellen sagt Sku die Meldung des Spiels an und der Zustand bleibt, wie er war.

Technisch: Idee und Referenzumsetzung stammen von ZenqFR, aus dem Begleit-Addon SkuQuestNearby (github.com/ZenqFR/Sku-QuestNearby); hier ist die Funktion mit ZenqFRs Zustimmung nativ gegen Skus eigene Schnittstellen neu gebaut, damit kein zusaetzliches Addon noetig ist. Der Eintrag haengt im chunk-lokalen CreateQuestSubmenu statt an einem Hook auf dem oeffentlichen Wrapper - deshalb bekommt ihn jede Questansicht: Questlog, Questdatenbank und die Questmenues von SkuChat. Auf 2.5.6 gibt es kein C_QuestLog: AddQuestWatch, RemoveQuestWatch und IsQuestWatched nehmen einen Questlog-Index, keine Quest-ID, und dieser Index verschiebt sich bei jeder angenommenen oder abgegebenen Quest. Sku haelt darum eine Zuordnung Quest-ID auf Index, prueft den gemerkten Index bei jedem Lesen nach und verwirft die Zuordnung bei den Questereignissen; ohne diesen Zwischenspeicher liefe die Liste "Questdatenbank, Alle" einen vollen Questlog-Durchlauf pro Quest. Eingeschaltet wird ueber AutoQuestWatch_Insert mit QUEST_WATCH_NO_EXPIRE, damit die Quest in QUEST_WATCH_LIST landet und kein Ablauftimer sie wieder herausnimmt; beim Abwaehlen wird zuerst der Eintrag aus QUEST_WATCH_LIST entfernt und dann RemoveQuestWatch gerufen - genau wie in Blizzards eigenem Klickpfad, sonst zaehlt eine laengst nicht mehr verfolgte Quest weiter gegen das Limit von fuenf. QuestWatch_Update laeuft nur ausserhalb des Kampfes, weil es am Ende geschuetzte Frames verschiebt; das naechste QUEST_LOG_UPDATE holt es ohnehin nach.

Neuer Tastenbefehl "Naechstes Questziel ins Ziel nehmen" (Alt+H)

Einfach: Ein Druck nimmt eine Kreatur ins Ziel, die zu einem noch offenen Questziel gehoert - und zwar auch dann, wenn man sie gar nicht toeten muss, sondern sie nur einen benoetigten Gegenstand fallen laesst. Beispiel: fuer "Essenzen fuer die Motoren" nennt das Questlog nur den Gegenstand; die Taste nimmt trotzdem das Managespenst ins Ziel, das ihn fallen laesst. Passt nichts in Reichweite, sagt Sku "kein Questziel in Reichweite"; ist im Questlog ueberhaupt nichts Passendes, "kein Questziel im Questlog". Die Taste liegt ab Werk auf Alt+H und laesst sich unter Sku Tastenbelegung, "Ziel und Soft Targeting" umlegen.

Technisch: Idee und Referenzumsetzung stammen von ZenqFR, aus dem Begleit-Addon SkuQuestTarget (github.com/ZenqFR/Sku-QuestTarget); hier ist die Funktion mit ZenqFRs Zustimmung nativ neu gebaut, damit kein zusaetzliches Addon noetig ist. Die Kandidaten kommen aus dem eigenen Questlog ueber SkuQuest:GetQuestTargetIds; Gegenstandsziele werden ueber die Fallquelle (npcDrops, eine Ebene tief auch itemDrops) auf die Kreaturen zurueckgefuehrt, die sie fallen lassen. Gesucht wird zuerst in der Zone, in der man selbst steht - wer dort keinen Spawnpunkt hat, kann gar nicht in Zielreichweite sein und darf keinen Platz im Makro belegen; erst wenn in der eigenen Zone nichts hinterlegt ist, wird ueber den ganzen Kontinent sortiert. Die Entfernung nimmt den naechstgelegenen aufgezeichneten Spawnpunkt, nicht den ersten der Liste. Das Makro ist mehrzeilig, und dabei entscheidet eine Eigenheit des Spiels: jede passende Zeile feuert, und jeder Treffer ueberschreibt den vorherigen - es gewinnt also die LETZTE. Aufgenommen wird deshalb von nah nach fern, damit das Laengenbudget nur Weitentferntes kappt, ausgegeben aber umgekehrt, damit der naechstgelegene Kandidat die letzte Zeile ist. Gebaut wird ausserhalb des Kampfes bei jedem Tastendruck; im Kampf feuert der zuletzt gebaute Text.

"Naechster Gegner im Kampf" findet auch, was man nicht anschaut (Strg+H)

Einfach: Die Taste konnte bisher nur finden, was man ohnehin anschaut - stand derselbe Gegner fuenf Meter hinter einem, meldete sie nichts. Das ist keine Einstellung, sondern das Verhalten der Tabulator-Zielsuche des Spiels. Sku merkt sich deshalb jetzt die Namen feindlicher Kreaturen, an denen man vorbeikommt, und probiert sie zusaetzlich ueber den Namen - und ein Name funktioniert in jede Richtung. In der Praxis heisst das: was man einmal gesehen, angegriffen oder ins Ziel genommen hat, bleibt zwei Minuten lang von ueberall aus erreichbar, auch weggedreht. Ausserdem beginnt die Suche jetzt bei jedem Druck beim naechstgelegenen Gegner, statt im Kreis weiterzuspringen. Die Taste liegt ab Werk auf Strg+H.

Technisch: Die Anregung stammt aus ZenqFRs SkuQuestTarget, das denselben Weg fuer seine Nebenfunktion benutzt. /targetenemy ist Tabulator und sucht im Sichtkegel - daran ist nichts zu aendern. "/tar Name" dagegen sucht ueber die Namensliste des Clients und ist richtungsunabhaengig, braucht aber einen Namen, und es gibt keine Schnittstelle, die Einheiten hinter einem aufzaehlt. Sku sammelt die Namen deshalb laufend aus vier Quellen: feindliche Namensplaketten, das eigene Ziel, die Einheit unter dem Mauszeiger und die Gegnerliste der Kampfueberwachung. Das Einsammeln laeuft im Sekundentakt, solange die Taste belegt ist, denn eine Plakette gibt es nur, solange die Kreatur im Blick ist - genau dann braucht man die Taste aber nicht. Dort werden nur Namen gesammelt; die teure Entfernungsmessung laeuft einmal pro Tastendruck. Gemerkte Namen halten zwei Minuten. Das Makro ist "/cleartarget", dann "/targetenemy", dann die gemerkten Namen von fern nach nah - die letzte passende Zeile gewinnt, also der naechstgelegene.

Neue Liste "Quests in der Naehe"

Einfach: Im Questmenue steht als dritter Eintrag, nach "Aktuelle Quests" und "Questdatenbank", jetzt "Quests in der Naehe". Darin liegt das ganze Questlog in EINER Liste - angefangene und fertige gemischt -, sortiert danach, wie weit das weg ist, worum es bei der jeweiligen Quest gerade geht. Jeder Eintrag nennt zuerst die Entfernung, dann die Himmelsrichtung, dann die Art und dann den Questnamen, also etwa "180 Meter; nordost; Questziel; Diebische Kobolde" oder "340 Meter; sued; Questabgabe; Der Wolfsrudelfuehrer".

Bei einer Quest, die noch offene Ziele hat, ist das die Entfernung zum naechsten Ziel; bei einer fertig gemeldeten Quest die Entfernung zur Abgabestelle. "Aktuelle Quests" gruppiert nach den Ueberschriften des Questlogs, sortiert also nach Zone - die neue Liste beantwortet dagegen die Frage "was ist von hier aus das Naechste".

Enter oeffnet dasselbe Questmenue wie ueberall sonst, samt Wegpunkten und dem Eintrag "Quest verfolgen". Die Liste ist ab Werk AUS und wird unter Sku Einstellungen, SkuQuest, "Eintrag Quests in der Naehe anzeigen" eingeschaltet: sie rechnet bei jedem Oeffnen das ganze Questlog gegen Skus Spawn-Datenbank durch, und das soll nur zahlen, wer sie auch benutzt. Wo Skus Daten keinen Ort hergeben, steht statt der Entfernung "Ort unbekannt", und die Quest rutscht ans Ende - sie verschwindet nicht.

Technisch: Idee und Referenzumsetzung stammen von ZenqFR, aus dem Begleit-Addon SkuQuestNearby (github.com/ZenqFR/Sku-QuestNearby); hier ist die Funktion mit ZenqFRs Zustimmung nativ neu gebaut, damit kein zusaetzliches Addon noetig ist - insbesondere ohne Questie und ohne GatherMate2. Die Rechnung liegt in der neuen Datei SkuQuest/Proximity.lua und ist zustandslos. Zwei Stufen, und die Reihenfolge ist der Punkt: zuerst der naechstgelegene aufgezeichnete Spawnpunkt IN DER Zone, in der man selbst steht - die Auswahl laeuft billig in Kartenkoordinaten, nur der Gewinner wird einmal in Weltkoordinaten umgerechnet; erst wenn das nichts hergibt, das Minimum ueber alle Zonen desselben Kontinents. Ein anderer Kontinent ist keine ungenaue Entfernung, sondern gar keine, und bleibt draussen. Gegenstandsziele werden ueber die Fallquelle auf Kreaturen und Weltobjekte zurueckgefuehrt, Erkundungsziele ueber die hinterlegten Koordinaten. Anders als beim Wegpunkt-Pfad werden ALLE Ziellisten einer Quest gelesen, nicht nur die erste nichtleere - eine Quest mit "toete acht Woelfe UND sammle fuenf Felle" haette sonst nur die Woelfe. Gefiltert wird nur nach ZIELART: welche Arten noch offen sind, sagt Blizzards eigene Fortschrittsanzeige ("monster", "item", "object"), und die passt eins zu eins auf die drei Listen; ein Abgleich Zeile gegen einzelnen Datenbankeintrag waere dagegen geraten, weil beide Reihenfolgen nirgends aneinander gebunden sind. Pro Quest und Art werden hoechstens zwoelf IDs durchgerechnet - die Grenze ist das Skript-Budget der Hardcore-Realms, nicht die letzte Nachkommastelle. Die Himmelsrichtung kommt aus denselben Weltkoordinaten, ueber dieselbe Funktion, die auch die Wegpunktlisten und der Minimap-Scanner benutzen. Bewusst die Himmelsrichtung und nicht eine Uhrzeit: eine Uhrzeit gilt relativ zur Blickrichtung und waere falsch, sobald man sich dreht - die Liste wird aber einmal gebaut und dann durchgelesen.

Questdatenbank: "Start in Zone" ohne Zwischenebene

Einfach: Unter "Questdatenbank, Start in Zone" lag bisher noch genau ein Eintrag, "Nach Entfernung", und darin erst die Quests. Eine Ebene, in der es nichts zu waehlen gibt, ist nur ein Tastendruck. Die Liste steht jetzt direkt unter "Start in Zone". Ausserdem war diese Liste kaputt: sie brach nach der ersten Quest ab, man bekam also genau einen Eintrag statt aller Quests der Zone.

Technisch: Die Zwischenebene stammte daher, dass daneben einmal eine zweite Sortierung ("Nach Schwierigkeit") stehen sollte; deren Baustelle stand seit Jahren auskommentiert daneben und wurde nie gebaut. Der Abbruch kam von einer Zeile "tcount = tcount + 1" im Aufbau der Liste: tcount war dort keine lokale Variable, sondern eine nie gesetzte globale, das Hochzaehlen also ein Fehler auf nil. Ein Fehler im Kindaufbau eines Menues wird verschluckt - der Aufbau endete damit stillschweigend nach dem ersten Eintrag. Der Zaehler wurde von nichts gelesen und ist ersatzlos entfernt.

Alles in der Bank in einer Liste, und die Bank wird auch unter Bagnon erkannt

Einfach: Im Taschenmenue gab es "alle taschen" - eine flache Liste ueber alle Taschen hinweg, nach Namen sortiert. Fuer die Bank gab es das nicht: an der offenen Bank standen zwar "Bank" und "Bank Tasche 1" bis "Bank Tasche 7" im Menue, aber wer etwas suchte, musste jedes Fach einzeln durchgehen. Jetzt steht direkt hinter "alle taschen" der Eintrag "alle bank", solange die Bank offen ist: alles, was in der Bank liegt, in einer Liste, mit demselben Tippfilter. Strg+Eingabe holt einen Gegenstand von dort in die Taschen - genau wie bisher schon in den einzelnen Bankfaechern. Ausserdem erkennt Sku jetzt an den Meldungen des Spiels selbst, ob die Bank offen ist, und nicht mehr am Fenster von Blizzard. Wer ein Taschen-Ersatz-Addon wie Bagnon benutzt, das dieses Fenster versteckt, hatte bisher gar keine Bank im Menue - Sku hielt sie fuer geschlossen und liess saemtliche Bankfaecher verschwinden. Dafuer ist jetzt kein Bruecken-Addon mehr noetig.

Technisch: Die Anregung stammt aus ZenqFRs Begleit-Addon SkuBagnonBridge (github.com/ZenqFR/Sku-BagnonBridge), das dieselbe Luecke auf seine Weise schliesst und die Bank ebenfalls ueber die Ereignisse des Spiels erkennt; hier ist mit ZenqFRs Zustimmung der Teil nativ gebaut, der ohne ein weiteres Addon auskommt. Die flache Liste war auf die Taschen 0 bis 4 begrenzt; die Bankbehaelter (-1, -3, 5 bis 11) wurden nie in sie kopiert. Sie sammeln sich jetzt in einer eigenen Liste, absichtlich getrennt von der Taschenliste: aus dieser leitet sich

SkuCore.combatBagOrder ab, die Spiegelung fuer den Kampf, und die kann von Haus aus nur Taschenfaecher benutzen. Die Eintraege der neuen Liste sind Kopien derselben Fach-Eintraege und tragen Tasche und Fach mit, also greifen alle vorhandenen Aktionen unveraendert. Der Zustand der Bank haengt jetzt an BANKFRAME_OPENED und BANKFRAME_CLOSED: beide kommen aus der Interaktion mit dem Bankier selbst und sind unabhaengig davon, wer das Fenster zeichnet. Beim Laden und nach /reload wird der Zustand zurueckgesetzt, und die alte Fensterpruefung bleibt zusaetzlich erhalten - die Erkennung kann dadurch nur mehr Faelle richtig treffen als vorher, keine weniger.

Loeschen eines eigenen Wegpunkts raeumte den falschen Eintrag ab

Einfach: Beim Loeschen eines selbst angelegten Wegpunkts wurde intern nicht dessen eigene Kennung aus einer Nachschlagetabelle entfernt, sondern die eines anderen Wegpunkts. Ausserdem meldete "/skucheck wp" vier Fehler bei den vier Schnellwegpunkten, obwohl mit ihnen alles in Ordnung war.

Technisch: Die wpId ist die Identitaet eines Wegpunkts - die Verbindungstabelle ist ueber sie verschluesselt -, keine Beschreibung seines Ortes. Die in ihr steckende Gebiets-ID stammt aus dem Moment des Cache-Aufbaus und bleibt stehen, wenn ein eigener Wegpunkt umzieht; genau das passiert den vier Schnellwegpunkten bei jedem Ladebildschirm, denn dabei werden sie auf die Spielerposition neu gesetzt. Die Pruefung baute die Kennung aus dem aktuellen areaId des Datensatzes neu auf und verglich - sie rechnet jetzt mit der in der Kennung selbst steckenden Gebiets-ID. Der Loeschpfad baute die Kennung ueber ".areaid" (das Feld heisst areaId), also mit Gebiet 1 statt des echten, und raeumte damit den Eintrag desjenigen Datensatzes ab, dem dieser Schluessel wirklich gehoert; er benutzt jetzt die gespeicherte Kennung.

Die Chateingabe ist bedienbar geworden

Einfach: Die Chatzeile war das einzige Eingabefeld in Sku, in das man blind tippte. Es gab einen Ton beim Oeffnen und einen beim Schliessen, sonst nichts - kein Zeichen-Echo, kein Vorlesen unter dem Cursor, und keine Auskunft darueber, wohin die Nachricht eigentlich ginge. Jetzt verhaelt sie sich wie jedes andere Sku-Eingabefeld. Jedes getippte und geloeschte Zeichen wird gesprochen, Pfeil links und rechts lesen das Zeichen unter dem Cursor und mit Strg das ganze Wort, Pfeil hoch holt die zuletzt gesendeten Nachrichten zurueck - zum erneuten Absenden oder zum Aendern - und sagt dabei den Kanal mit, denn den sieht man einer zurueckgeholten Zeile nicht an. Angesagt wird der Kanal ausserdem beim Oeffnen und bei jedem Wechsel, aber bewusst nicht bei "Sagen": das ist der harmlose Fall, und ihn jedes Mal vorzusagen waere nur Geraeusch. Wem die Kanalansage im eigenen Ablauf nicht passt, schaltet sie in den Chat-Einstellungen unter "Kanal der Chateingabe ansagen" ab, ab Werk ist sie an; das nimmt dann auch den Kanal vor der mit Pfeil hoch zurueckgeholten Zeile weg. Ein Gegenstand im Chat zaehlt beim Lesen als ein einziges Zeichen statt als fuenfundsechzig Zeichen Steuerkram. Und ein vertippter Befehl wie "/tets" sagt jetzt "Unbekannter Befehl", statt einfach nichts zu tun.

Technisch: Das Tastatur-Echo der Sku-eigenen Felder haengt ueber

SkuOptions:AttachInputEcho jetzt auch an fremden. Drei Dinge sind dort anders:

angehaengt wird mit HookScript statt SetScript, weil auf Blizzards Feld dessen eigene Handler fuer Verlauf und Namensvervollstaendigung liegen; die Vorlage traegt ignoreArrows, weshalb schlichte Pfeile an das Spiel gingen und der Textcursor ALT brauchte - das wird zurueckgedreht; und scharf geschaltet wird am Fokus, weil ein fremdes Feld kein Oeffnen-und-Schliessen-Paar hat, an dem das Echo haengen koennte.

Der Kanal wird aus der Kopfzeile der Eingabe gelesen statt aus chatType nachgebaut - die Kopfzeile ist bereits uebersetzt und deckt Fluesterziele, nummerierte Kanaele und Blizzards eigene Umschaltungen mitten im Aufruf ab. Ihre Ansage laeuft verzoegert und in einem einzigen Slot, denn jeder Kanalwechsel wird durch einen Tastendruck ausgeloest, und dessen Zeichen-Echo hatte die Ansage sonst jedes Mal aus der Warteschlange geworfen, bevor sie ueberhaupt gesprochen war.

Gegenstandslinks werden als Name gelesen, nicht als Farbcode

Einfach: Ein Gegenstand - im Chat, in der Post, in der Beute - wurde als lange Folge aus Farbcodes, Kennungen und Doppelpunkten vorgelesen statt schlicht als sein Name.

Technisch: In der Sprachausgabe wurden erst alle senkrechten Striche durch Leerzeichen ersetzt und DANACH die Funktion gerufen, die Farbcodes, Links und Texturen entfernt. Deren Muster suchen alle nach einem senkrechten Strich, den es zu dem Zeitpunkt nicht mehr gab - sie liefen also seit jeher ins Leere. Reihenfolge getauscht; der pauschale Ersatz ist jetzt nur noch ein Auffangnetz dahinter.

Questdatenbank: "Start in Zone" nennt auch die Himmelsrichtung

Einfach: Die Liste der Quests, die in dieser Zone beginnen, sagte bisher nur, wie weit der Questgeber entfernt ist. Jetzt sagt sie wie die Liste "Quests in der Naehe" auch, in welcher Richtung er liegt - erst die Entfernung, dann die Himmelsrichtung.

Technisch: Die Weltkoordinaten des Questgebers lagen in dieser Liste ohnehin schon vor; die Richtung kommt aus derselben Funktion, die auch die Wegpunktlisten benutzen. Bewusst die Himmelsrichtung und nicht die Uhrzeit: eine Uhrzeit gilt relativ zur Blickrichtung und waere falsch, sobald man sich dreht, waehrend diese Liste einmal gebaut und dann durchgelesen wird. Die Quest-ID eines Eintrags kommt jetzt direkt aus der Zeile statt aus einer Nachschlagetabelle, deren Schluessel der alte Beschriftungstext ohne Richtung war.

Tastatur-Echo: Zeichen kommen sofort

Einfach: Beim Tippen in ein Eingabefeld kamen die Buchstaben nicht im Takt der Finger: manche wurden verschluckt, andere kamen deutlich zu spaet, und Doppelbuchstaben wie in "Wasser" oder "alle" waren regelmaessig nur einmal zu hoeren. Jetzt kommt jedes getippte Zeichen sofort, und ein zweimal gedrueckter Buchstabe wird auch zweimal gesprochen.

Technisch: Das Echo lief bisher durch dieselbe Warteschlange wie jede Menueansage, und die ist fuer Ansagen gebaut, nicht fuer Tastendruecke. Sie sammelte Zeichen eine Zehntelsekunde lang und sprach sie ueberschreibend - und Ueberschreiben heisst hier: erst StopSpeakingText, dann noch einmal eine Zehntelsekunde warten, damit dieser Stop nicht ausgerechnet die Ansage abraeumt, fuer die er Platz machen soll. Beides nacheinander sind rund 0.2 Sekunden je Anschlag, und der Stop des einen Anschlags landete regelmaessig auf dem naechsten. Dazu kam die in dieser Version neu eingefuehrte Dublettensperre der Sprachausgabe, fuer die ein einzelnes Zeichen als Aeusserung mit sich selbst identisch ist - daher die verschluckten Doppelbuchstaben. Getippte Zeichen laufen jetzt ueber eine eigene Schnellspur: ein einziger Platz, in dem der neueste Anschlag gewinnt, Ausgabe im selben Frame, der Stop nur noch einmal zu Beginn einer Tippfolge statt bei jedem Anschlag, und die Dublettensperre sieht getippte Zeichen gar nicht mehr. Hintergrund: ein Bildschirmleser braucht so etwas nie, weil seine Schnittstelle das Abbrechen als Teil des Sprechbefehls anbietet - eine einzige Operation. Die Schnittstelle des Spiels kann das nicht, also muss Sku sie aus zwei Aufrufen nachbauen, die einander ueberholen koennen. Neu ist, das nur noch einmal je Tippfolge zu tun.

Eine per Taste erneut angeforderte Zeile wird wieder gesprochen

Einfach: Wer eine Menuezeile per Tastendruck noch einmal hoeren wollte, bekam gelegentlich Stille - die Sprachausgabe hielt die Wiederholung fuer ueberfluessig.

Technisch: Die Dublettensperre verwirft eine Zeile, die innerhalb einer Sekunde genauso schon einmal gesprochen wurde. Das ist richtig fuer den ueberfluessigen Nachschlag eines Menue-Neuaufbaus und falsch fuer denselben Text, den der Nutzer gerade per Taste angefordert hat. Am Text sind die beiden nicht zu unterscheiden, und keine Zeitspanne trennt sie - nur der Ausloeser. Die Tastenauswertung des Menues markiert ihre Ansage deshalb jetzt als tastenausgeloest, und die Sperre laesst markierte Zeilen immer durch. Ueberfluessige Wiederholungen werden weiterhin verworfen, jetzt unabhaengig davon, wie schnell sie eintreffen.

Quests mit gemischten Zielen zeigen alle Zielarten

Einfach: Bei einer Quest wie "toete 8 Woelfe UND sammle 5 Felle" zeigte der Eintrag "Ziel" im Questmenue nur die erste Zielart - meist die Gegner; die Fundorte des Sammelgegenstands oder ein Erkundungspunkt fehlten still. Betroffen waren 95 Quests. Jetzt stehen alle Zielarten nebeneinander in einer Liste, und auch der Tastenbefehl "Naechstes Questziel ins Ziel nehmen" kennt bei solchen Quests beide Haelften. Nebenbei behoben: eine Quest, die nur einen Erkundungspunkt und sonst keine Zieldaten hat, bekommt ueberhaupt erst einen "Ziel"-Eintrag, und ein nicht aufloesbarer Erkundungspunkt erzeugt keinen Eintrag mehr, der nur noch "leer" ansagt.

Technisch: SkuQuest:GetQuestTargetIds war eine elseif-Kette ueber die Ziellisten der Questdatenbank (Kreaturen, sonst Objekte, sonst Gegenstaende, ...) und konnte schon per Signatur nur EINE Liste mit EINEM Typ zurueckgeben. Ersetzt durch GetQuestTargetGroups: ein Feld von Gruppen {targets, type} - Kreaturen samt deduplizierten Toetungs-Credits, Objekte, Gegenstaende und, nur fuer die objectives-Aufrufer, der triggerEnd-Punkt der Quest. Alle sieben Aufrufer sind umgestellt (Questmenue, Wegpunkt-Cache, Questmarker, Questziel-Taste); der alte Name bleibt als Erste-Gruppe-Wrapper fuer den WowVision-Port stehen. Dazu ist der item-Zweig von GetResultingWps gegen unbekannte Gegenstands-IDs abgesichert: der indizierte bisher ungeprueft und liess den verschluckten Menueaufbau als stilles "Liste leer" sterben.

Questdatenbank auf den aktuellen Questie-Stand gebracht

Einfach: Skus eingebaute Questdatenbank stammt von Questie und war rund zwei Jahre alt. Nach dem Abgleich haben 33 Quests, deren "Ziel" bisher leer blieb, echte Ziele (die Dunkelmond-Kartensets, die wiederholbaren Ogri'la- und

Violettes-Auge-Quests, "Den Schluesselmeister finden"), die sechs "Untersucht die Geissel"-Quests haben jetzt Erkundungspunkte, fuenf fehlende Quests sind ergaenzt, und rund 2000 Datensaetze tragen kleinere Korrekturen an Namen, Stufen, Questgebern und Vorquest-Ketten. Geprueft: die Korrekturen sind fuer Era und TBC identisch, die Aktualisierung ist auf beiden sicher.

Technisch: Semantischer Abgleich statt Byte-Kopie (neues Werkzeug

dev/rework-docs/_refresh_questdata_from_questie.py, danach _db_convert.py):

Questies Schema divergiert ab Feld 27, uebernommen werden nur die Felder 1-26;

Skus eigene Felder extraObjectives und skuData bleiben je Datensatz erhalten.

Die requiredRaces-Konvention (alte Alle-Rassen-Maske 2047, neu 0 - fuer Skus Logik dasselbe) gilt beim Vergleich als gleich, sonst haetten 2117 Datensaetze ohne inhaltliche Aenderung im Diff gestanden. Jede referenzierte Kreatur-, Objekt- und Gegenstands-ID wurde gegen die mitgelieferten Datenbanken (Basis + WotLK) validiert; ein Datensatz blieb deshalb beim alten Stand.

Ereignisquests tauchen direkt nach dem Laden nicht mehr auf

Einfach: In den ersten Sekunden nach einem /reload konnten in "Start in Zone" Quests inaktiver Weltereignisse auftauchen - etwa Sonnenwendquests im August. Sobald Questie fertig geladen war, verschwanden sie von selbst wieder; jetzt sind sie auch in diesem Zeitfenster ausgeblendet.

Technisch: Die beiden Verfuegbarkeits-Tore fragten Questie erst ab Questie.started, und das Flag kippt ganz am Ende von Questies Initialisierung. Questies statische Ausschlussliste QuestieCorrections.hiddenQuests - entfernte Quests plus ALLE Ereignisquests; die aktiven werden erst nach der Kalender-Antwort des Servers freigeschaltet - existiert aber viel frueher. IsQuestieUnavailable liest sie vor started jetzt direkt: das ist ein reiner Tabellenzugriff, die

Memoize-Vergiftungsgefahr hinter dem started-Tor betrifft nur IsDoable. Der Wert "HIDE_ON_MAP" wird wie bei Questie selbst uebersprungen, und jede Vor-Start-Ausblendung schreibt eine dprint-Zeile ins Log.

Quests in Dungeons fuehren zum Eingang statt ins Leere

Einfach: Bei rund 300 Quests liegt der Questgeber, das Ziel oder die Abgabe in einem Dungeon - "Rache fuer Vorrel" beginnt im Scharlachroten Kloster, "Willix der Importeur" endet im Kral von Rasierklingenfarn. Annahme, Ziel und Abgabe waren dort bisher leer, weil es in Instanzen keine Weltkarte gibt. Jetzt steht dort stattdessen der Eintrag "NPC, Eingang, Dungeonname, Zone" mit Route zum Dungeoneingang - auch bei Schlachtfeldquests (Alteractal je Fraktion am richtigen Eingang). Fundquellen eines GEGENSTANDS im selben Dungeon werden dabei zu einem einzigen Eintrag "Dungeonname, Eingang, Zone" zusammengefasst - "Ramaladnis Schicksal" nannte sonst 29 Naxxramas-Trashmobs einzeln, die alle zum selben Tor fuehren; Toetungsziele behalten ihre einzelnen Mobnamen.

Technisch: Neue generierte Tabelle SkuDB.InstanceEntrances (aus Questies Dungeon-Tabelle, Werkzeug dev/rework-docs/_gen_instance_entrances.py): Instanz-AreaId -> Eingaenge {Elternzone, x, y, ggf. Fraktion}, inklusive der Nebenfluegel-IDs und einem GetBuildInfo-Tor fuer die WotLK-Verschiebungen. Die Spawn-Aufloeser (CreatureIdHelper, Objekt- und Gegenstands-Zweig von GetResultingWps) ueberspringen kartenlose Gebiete nicht mehr, sondern beantworten sie wie der triggerEnd-Umweg von v43.2: Eingangskoordinaten in Weltkoordinaten wandeln, naechsten Routen-Wegpunkt nehmen. Memoisiert je Wegpunktcache-Generation; der Fraktionsfilter liest UnitFactionGroup.

77 Feldziel-Quests haben jetzt ein echtes Questziel

Einfach: Fuer 77 Quests, deren Ziel ein Ort oder Gegenstand im Feld ist (die Wasserbrunnen von Mulgore, der Mondfederstein der Druiden, die Kristallpylonen im Krater von Un'Goro, Rolfs Leichnam, die vier Draenei-Totems, die Tierzaehmungs-Questreihe der Jaeger und viele mehr), gab es bisher keinerlei Zieldaten - der Eintrag "Ziel" fehlte einfach. Jetzt haben alle ein echtes, routbares Questziel. Wichtig: Die Objekte und Kreaturen kommen aus Skus eigenen Spawndaten, aber 26 Ortsangaben stammen aus Webquellen

(warcraft.wiki.gg, Wowhead) und konnten nicht alle im Spiel geprueft werden.

Sie sind mit Bedacht gewaehlt, koennen aber im Einzelfall danebenliegen - eine Rueckmeldung, ob so ein Ziel stimmt oder nicht, hilft sehr. Auch ein ungenauer Punkt ist besser als gar keiner: die Route fuehrt in die richtige Gegend.

Technisch: Ergebnis der Pruefliste dev/rework-docs/QUEST-TARGET-PROPOSALS.txt (Abschnitte 1-3, von Hand geprueft): 27 Objekt- und 24 Kreaturenziele als objectives-Eintraege in quests_fixes.lua (IDs gegen die eigenen Datenbanken validiert, Spawnzonen verifiziert, keine -1,-1-Positionen im Freiland) plus 26 triggerEnd-Koordinaten aus der Webrecherche. Zwei Quests (9410, 10166) trugen die richtige Objekt-ID schon in extraObjectives, das die Zielmenues nicht lesen - dort ist das objectives-Feld ergaenzt.

Dreizehn Sprich-mit-Quests haben wieder eine Abgabe

Einfach: Dreizehn Quests - vor allem die alten Priester-Zauberquests (Sterne Elunes, Elunes Anmut, Furchtlosigkeit, Schwaechungsfluch), dazu unter anderem "Der Foliant des Adels" und "Verbuendeter des Netherschwingenclans" - standen ohne Abgabepunkt in den Daten: weder Ziel noch Abgabe, nichts war routbar. Jetzt fuehrt die Abgabe zu dem NPC, den der Questtext selbst nennt.

Technisch: finishedBy-Eintraege in quests_fixes.lua; die Kreatur-IDs sind aus dem Questtext gegen die Kreaturdatenbank aufgeloest (jeder Name ist dort eindeutig, die Spawns liegen in der im Text genannten Zone). Die Kandidaten stammen aus dem neuen Werkzeug dev/rework-docs/_quest_target_candidates.py, das alle zielllosen Quests klassifiziert und fuer die restlichen (echte Feldziele ohne Koordinatenquelle) die Pruefliste QUEST-TARGET-CANDIDATES.txt schreibt.

Experimentell: Sammelrouten

Einfach: Du waehlst eine Ressource - ein Erz, ein Kraut, eine Gaswolke oder eine Truhensorte - und Sku fuehrt dich durch die Zone, Vorkommen fuer Vorkommen, immer das naechstgelegene zuerst. Wo Wegedaten vorliegen, geht es ueber eine echte Route; ist keine da, gibt es einen direkten Peilton, und Sku sagt das dazu - ein Peilton kann durch eine Wand zeigen, eine Route nicht. Im Flug wird nie geroutet: dort ist die Gerade der richtige Weg, nicht der Notbehelf. Am Vorkommen wartet Sku kurz, waehrend du abbaust, und geht dann weiter. Der Tastenbefehl "naechster Routenwegpunkt" (ab Werk Strg+Umschalt+W) ueberspringt waehrend einer Sammelroute das aktuelle Vorkommen - es braucht also keine neue Taste.

Ist die passende Suche aktiv (Mineralien finden, Kraeuter finden), prueft der Minikartenscanner beim Herangehen, ob das Vorkommen ueberhaupt noch da ist, und ueberspringt abgebaute mit einer eigenen Ansage. Ohne Suche laeuft die Route trotzdem, nur eben ohne diese Pruefung.

Zu finden unter Einstellungen -> Scan -> ressourcen scan -> Sammelrouten; dort liegen auch Pruefradius, Anzahl der Vorkommen je Route und der Schalter fuer die Pruefung. Fuer Erze, Kraeuter und Truhen muss "Wegpunkte fuer Kraeuter und Bergbau anzeigen" in den Navigationseinstellungen an sein - sonst liegen diese Vorkommen gar nicht als Wegpunkte vor, und Sku sagt beim Start genau das, statt die Zone faelschlich fuer leer zu erklaeren. Gaswolken brauchen die Einstellung nicht.

Wichtig: Diese Funktion ist ausdruecklich experimentell. Sie ist im Spiel erst in Ansaetzen erprobt, und die Pruefung "ist das Vorkommen ueberhaupt noch da" konnte gar nicht unter echten Bedingungen laufen, weil hier kein Charakter einen Sammelberuf hat - ohne Mineralien finden oder Kraeuter finden gibt es keine Punkte auf der Minikarte, die der Scanner lesen koennte. Wer Bergbau oder Kraeuterkunde spielt: bitte ausprobieren und berichten, was schiefgeht.

Technisch: Idee und Referenzumsetzung stammen von ZenqFR, aus dem Begleit-Addon SkuGatherRoute (github.com/ZenqFR/Sku-GatherRoute); die Routenmechanik ist dort erdacht und vorgefuehrt worden - eine Wegpunktfamilie unter einem gemeinsamen Basisnamen, jedes Vorkommen ueber eine nahe Route, eine eigene Ansage fuer jeden Uebergang, und der vorhandene Tastenbefehl als Ueberspringer. Hier ist die Funktion mit ZenqFRs Zustimmung nativ neu gebaut, damit kein zusaetzliches Addon noetig ist.

Ein Unterschied ist bewusst: das Original setzt GatherMate2 voraus, diese Fassung nicht. Wir sehen darin keinen Vorteil - die Vorkommen stehen samt Weltkoordinaten laengst in SkuNavs Wegpunkt-Cache, und zwar so benannt, dass die Ressource der Basisname des Wegpunkts ist; eine zweite Datenquelle und ein zweites Addon wuerden dem nichts hinzufuegen, kosteten aber jeden Nutzer eine weitere Installation. Sollte GatherMate2 etwas leisten, das wir uebersehen haben - das Selbstaufzeichnen tatsaechlich abgebauter Knoten waere der Kandidat -, dann sagt uns bitte wofuer, und wir sehen es uns an.

Die Praesenzpruefung haengt sich in MinimapScanner:MinimapScanFastStop, den Punkt, durch den jeder Scan laeuft. Ist "bei Ressourcen benachrichtigen" an, reicht der ohnehin laufende Scan; sonst scannt die Route selbst, gedrosselt und nur in Reichweite des Ziels, und diese Scans bleiben stumm. Ein Treffer bestaetigt, ein Fehlschlag beweist nichts - ein Scan meldet immer nur einen Namen und kann einen anderen Punkt erwischt haben. Erst nach mehreren erfolglosen Scans in Reichweite gilt ein Vorkommen als weg. Im Zweifel wird nie uebersprungen: ein zu Unrecht behaltenes Vorkommen kostet ein paar Schritte, ein zu Unrecht uebersprungenes faellt gar nicht auf.

Das Menue bleibt beim Gehen bedienbar

Einfach: Oeffnete man das Menue waehrend man lief, stand es zwar da und sagte "Menue geoeffnet", aber keine Taste tat noch etwas - keine Pfeiltaste, kein Buchstabe, kein Eingabe. Nur Escape kam durch. Bedienbar wurde es erst, wenn man stehen blieb. Das ist behoben: ein offenes Menue nimmt Tasten jetzt entgegen, egal ob man geht, laeuft oder autolaeuft.

Technisch: Es gab zwei Bewegungssperren, nicht eine. Die erste verhindert das OEFFNEN, waehrend eine Bewegungstaste gedrueckt gehalten wird - die bleibt, sie ist noetig: die Tastenbelegungen des Menues wuerden das Loslassen schlucken und man liefe endlos weiter. Autolaufen ist davon seit v42.00 ausgenommen (eigenes Flag AutoRun, das IsPlayerMoving bewusst nicht liest). Die zweite sass im Tastenhandler des Menues selbst und liess, solange eine Bewegungssperre stand, jeden Tastendruck ausser Escape verfallen. Diese zweite Sperre kauft nichts: ist das Menue erst offen, gehoeren ihm die Tasten ohnehin schon, das Verwerfen stoppt keine Bewegung - es macht nur das Menue taub und setzt zu allem Ueberfluss das Merkzeichen "spaeter oeffnen" auf ein laengst offenes Menue, das die Wiederoeffnungs-Schleife dann wieder abraeumen muss. Sie greift jetzt nur noch, wenn das Menue NICHT offen ist. Die vier verbliebenen Oeffnungssperren schreiben ausserdem eine Zeile ins Debug-Log, die die haltende Bewegungstaste beim Namen nennt - vorher waren sie stumm, und ein Bericht "das Menue ging beim Laufen nicht auf" hatte keinerlei Spur.

Navigation: "Aktuelle Karte Entfernung" steht jetzt vorn

Einfach: Unter "Direkter Wegpunkt" stand "Letzte" an erster und "Aktuelle Karte Entfernung" an zweiter Stelle. Die beiden sind getauscht - die Liste der Wegpunkte in der aktuellen Zone ist der haeufigere Einstieg und liegt jetzt direkt unter dem Cursor.

Technisch: Reine Reihenfolge der Injektionen in SkuNav:MenuBuilder. "Letzte" bleibt an eine nicht leere Liste zuletzt benutzter Wegpunkte gebunden; ist sie leer, steht "Aktuelle Karte Entfernung" ohnehin an erster Stelle, wie vorher auch.

Der Tippfilter ignoriert Akzente

Einfach: In jeder Liste, die sich durch Tippen einengen laesst, wurden Akzente wie Zeichen einer anderen Sprache behandelt. Auf einem franzoesischen Client fand "general" nichts, obwohl "Fournitures generales" dastand, und "ingenieur" fand "Ingenieur" nicht - "ing" dagegen schon. Das traf auch Deutsch: ein Eintrag, der mit einem grossen Umlaut beginnt, war ueber den Filter nie erreichbar. Jetzt zaehlt der Buchstabe, nicht der Akzent. Dazu tippt auf einer franzoesischen AZERTY-Tastatur die Taste ù jetzt ebenfalls in den Filter - sie ist der einzige akzentuierte Buchstabe, den diese Tastatur als echtes Tastenereignis liefert.

Technisch: string.lower ist in Lua bytweise und bildet ausschliesslich A-Z ab, es faltet also auf keiner Seite des Vergleichs je ein akzentuiertes Zeichen. SkuMenuFilterMatch (benutzt von ApplyFilter und JumpToFilterMatch) und SettingsSearchMatch falten Eintragsnamen und Suchtext jetzt vorher auf akzentfreies ASCII; nur 2-Byte-Sequenzen aus Latin-1 Supplement und Latin Extended-A werden angefasst, reines ASCII nimmt den schnellen Weg. Streng durchlaessiger als vorher: was frueher passte, passt weiterhin. Ausserdem laufen die beiden string.find jetzt mit plain=true - der Suchtext wurde als Lua-Suchmuster gelesen, weshalb eine Eingabe wie "50%" oder "(lang" nichts fand oder mit einem Fehler abbrach.

Die Akzentfaltung stammt aus PR #9 (ZenqFR), die ù-Taste aus PR #13 (Naxedim).

Aktionsleisten: der Zauber-Tooltip wird wieder vorgelesen

Einfach: Im Aktionsleisten-Menue (Umschalt+F11) las Umschalt+Ab auf einem Zauber der Zuweisungsliste gar nichts mehr vor. Jetzt kommt der Tooltip wieder - ebenso bei der aktuellen Belegung einer Taste und bei den beiden

Begleiter-Faehigkeiten daneben, die dieselbe Schwaeche hatten.

Technisch: Zwei unabhaengige Ursachen, beide behoben, weil sich aus dem Code keine ausschliessen liess. Erstens wird SkuScanningTooltip einmalig beim Login ohne Vorlage erzeugt und von jedem Modul geteilt; wer ihn zuletzt benutzt hat, kann ihn ohne brauchbaren Besitzer zuruecklassen, und danach fuellt jeder Set*-Aufruf nichts mehr - lautlos, ohne Fehler. Er wird jetzt unmittelbar vor dem Fuellen neu in Besitz genommen. Zweitens bekam SetSpellByID den dritten Rueckgabewert von GetSpellBookItemName, der auf diesem Client der Classic-Signatur folgt und nur (name, rank) liefert - die Id ist eine Retail-Ergaenzung und war nil. Die Id kommt jetzt aus

GetSpellBookItemInfo, gefuellt wird mit SetSpellBookItem, das gar keine Id braucht. Der Lesevorgang laeuft zusaetzlich in einem pcall, weil er bei jeder Cursorbewegung ausgeloest wird. Aus PR #10 (ZenqFR).

Questziel: der Ort stand in den Daten, gefunden wurde er nie

Einfach: 174 Quests, bei denen man einen Ort erkunden oder dort etwas benutzen soll, antworteten unter "Questziel" nur "Leer". Jetzt fuehrt der Eintrag zum naechstgelegenen Routenwegpunkt an diesem Ort.

Technisch: GetTriggerEndWps setzte einen Wegpunkt-NAMEN zusammen

("<Quest>;<Zone>;<Questziel>;<x>;<y>") und liess ihn ueber die exakte Namenssuche im Wegpunkt-Cache aufloesen. Einen Wegpunkt unter diesem Namen erzeugt aber nichts - anders als bei Kreaturen- und Objektvorkommen -, er traf also nur, wenn jemand ihn von Hand in die Routendaten geschrieben hatte:

genau einer existiert (Quest 10211, Shattrath). Der zusammengesetzte Name wird weiter benutzt, wenn er aufloest; sonst uebernimmt jetzt die Geometrie - Kartenkoordinaten in Weltkoordinaten, dann der naechste echte ROUTEN-Wegpunkt.

GetNearestWpToCoords2 bekam dafuer einen optionalen typeId-Filter, damit die Ersatzsuche nicht in den rund 145000 erzeugten Vorkommenspunkten landet, und eine Absicherung gegen einen fehlenden Kontinent-Eimer, wo pairs(nil) warf.

Ausserdem werden jetzt alle Koordinatenpaare jeder Zone gelesen statt nur des ersten, und das Ergebnis wird pro Cache-Generation gemerkt.

Franzoesisch: die Wegpunktkommentare sprechen wieder - und jetzt franzoesisch

Einfach: Die Kommentare an Wegpunkten - darunter die sicherheitsrelevanten wie "Vorsicht, ab hier fuehrt die Route am Rand einer Schlucht entlang", "hier auf den Zeppelin warten" oder "dieser NPC bewegt sich" - blieben auf einem franzoesischen Client seit v42.11 restlos stumm. Sie sprechen wieder, und sie sprechen jetzt Franzoesisch: 207 Texte, die auf 546 Wegpunkten sitzen.

Technisch: Die Routendaten fuehren lComments nur fuer enUS und deDE (rund 296 Wegpunkte). SkuNav:PlayWpComments las comments[Sku.Loc] ohne Rueckfall. Bis v42.11 war Sku.Loc auf einem franzoesischen Client "enUS", weil es keine frFR-Locale gab, und man hoerte die englischen Texte; seit locales/frFR.lua existiert, ist Sku.Loc "frFR", die Suche liefert nil, und die Funktion kehrt wortlos zurueck. Neu ist Sku.locList (SkuUtil.lua), das Listengegenstueck zu Sku.locStr: es liefert die erste NICHT LEERE Liste aus Sku.Loc / enUS / deDE. "Nicht leer" ist entscheidend, weil SkuMM.lua an jedem gezeichneten Wegpunkt ein leeres comments[Sku.Loc] anlegt - eine einfache oder-Kette bliebe daran haengen. Die Uebersetzung ist aus dem DEUTSCHEN Original gemacht, nicht ueber das Englische: das Englische hat auf genau diesen Sicherheitstexten Details verloren (die Schlucht-Warnung ohne "du gehst am Rand" und ohne Laufrichtung, "extrem schmale Bruecke mit Schlucht" zu "extrem schmale Bruecke"), und mehrere englische Eintraege sind leer, darunter die Warnung vor toedlichen Aufzuegen auf acht Wegpunkten.

Franzoesisch: Ressourcennamen und die Hoehle der Nebel

Einfach: Zwei Fehler, die nur einen franzoesischen Client trafen. Erstens waren 22 der 94 Ressourcennamen des Minikartenscanners falsch - der Scanner vergleicht sie mit dem Tooltip des Spiels, ein falscher Name heisst also, dass dieses Vorkommen nie angesagt wird, ohne Fehlermeldung. Zweitens blieb in der Hoehle der Nebel die Wegpunktliste leer, waehrend eine draussen gestartete Route weiterlief.

Technisch: Die 22 Namen wurden einzeln gegen eine von beiden Addons unabhaengige Quelle entschieden: 19 ueber SkuDBs eigene frFR-Tabellen (aus Questies Blizzard-Strings), drei ueber die Tooltip-Schnittstelle von Wowhead. Bei der Hoehle vergleicht Geo.lua GetMinimapZoneText() woertlich mit L["Hoehle der Nebel"]; die generierte frFR-Locale trug "Grotte des Brumes", eine freie Uebersetzung - der Client sagt "Caverne des Brumes". Der Vergleich lief also ins Leere, uiMap blieb auf dem Kontinent, GetAreaIdFromUiMapId antwortete -1 und GetCurrentAreaId nil, worauf ListWaypoints2 aufgab. Der Wert wurde mit /szp in der Zone gelesen, nicht uebersetzt, und liegt jetzt sowohl in der generierten Datei als auch in der TSV-Ablage, aus der sie zusammengebaut wird

Aus den PRs #14 und #16 (Naxedim).

Zum Beacon drehen: genauer, und mit Vorhalt

Einfach: Die automatische Drehung zum Funkfeuer (T) sitzt jetzt deutlich genauer. Vorher lief sie so schnell, dass allein das framegenaue Stoppen je nach Bildrate zwanzig Grad und mehr Ueberdreh kosten konnte. Jetzt richtet sich das Tempo nach der Groesse der Drehung, und keine Drehung dauert laenger als eine Viertelsekunde. Waehrend man sich bewegt, wird ausserdem vorgehalten: gezielt wird dorthin, wo der Wegpunkt am Ende der Drehung liegen wird - das beendet das Im-Kreis-Laufen um nahe Wegpunkte, das vor allem beritten und im Flug auftrat. Und ein Druck waehrend einer laufenden Drehung wird verworfen statt die Drehung mittendrin abzubrechen; gewohntes Mehrfachdruecken verfeinert weiter wie bisher.

Technisch: Vier Teile, die zusammen getestet wurden. Der Schnappschuss auf die Standardkamera vor der Drehung bleibt - er ist fuer die Gierung tragend, ohne ihn stimmt der Winkel nicht. Die Drehgeschwindigkeit wird aus dem Restwinkel gedeckelt, statt fest zu laufen. Der Vorhalt rechnet aus der aktuellen Geschwindigkeit und der voraussichtlichen Dauer der Drehung, wo der Wegpunkt am Ende steht. Dazu eine Absicherung gegen den Fehler, dass nach schnell hintereinander ausgeloesten Drehungen die Drehgeschwindigkeit der Kamera- Tasten dauerhaft vervierfacht haengenblieb.

Das Installationsprogramm merkt sich, wo WoW liegt

Einfach: Das Installationsprogramm sucht das Spiel an den ueblichen Stellen - Programme, dazu eine Handvoll wahrscheinlicher Ordner auf C, D und E. Wer sein WoW woanders hat, musste den Ordner von Hand suchen, und das nicht einmal, sondern bei JEDEM Update: das Installationsprogramm vergass die Antwort in dem Moment, in dem es sich schloss. Jetzt schreibt es den Ordner auf, sobald eine Installation durchgelaufen ist, und faengt beim naechsten Mal dort an. Zeigt man ihm einen Client, findet es auch den zweiten daneben - eine Classic Era neben einer Anniversary auf demselben ungewoehnlichen Laufwerk wird von selbst mitgenommen. Zieht das Spiel spaeter um oder wird deinstalliert, wird die Notiz verworfen und es wird gesucht wie vorher. Das Installationsprogramm steht damit auf Version 4.5.

Technisch: Neue Datei PathMemory.cs. Das Installationsmanifest taugt dafuer nicht - SkuInstall.json liegt IM AddOns-Ordner, es zu lesen setzt also voraus, den Ordner schon gefunden zu haben, den man sich merken will. Der Ordner jedes Clients wird deshalb als einfache Zeile "produkt=pfad" in SkuPaths.txt geschrieben, und zwar an zwei Stellen: %LOCALAPPDATA%\SkuUpdater, neben der dauerhaften Kopie des Updaters, die die Verknuepfung "Sku Updater" startet, und %ProgramData%\SkuUpdater als maschinenweite Spiegelung. Die Spiegelung ist kein Selbstzweck: das Installationsprogramm fordert Adminrechte an, ein Standardbenutzer, der die UAC-Abfrage mit den Adminzugangsdaten eines anderen beantwortet, laeuft also komplett unter jenem Profil und wuerde die Notiz sonst in ein LOCALAPPDATA schreiben, das er nie wiedersieht. Beim naechsten Start schlaegt ein gemerkter Ordner die Erkennung - er ist eine Entscheidung, die Erkennung nur eine Vermutung ueber eine kurze Laufwerksliste - und sein Basisverzeichnis wird der Suchliste vorangestellt; genau das macht das Merken eines Clients fuer den anderen bezahlt. Absicherungen gegen eine veraltete Notiz: der Ordner muss noch existieren, und seine .flavor.info darf nicht inzwischen einen anderen Client melden - sonst wird die Notiz ignoriert, statt eine Installation ins Leere zu schicken. Geschrieben wird erst, nachdem ein Client sauber installiert wurde, ein abgebrochener oder fehlgeschlagener Lauf hinterlaesst also nichts. Klartext mit Absicht - die Datei laesst sich vorlesen und im Editor korrigieren, und wer eine Zeile loescht, bekommt fuer diesen Client die automatische Erkennung zurueck. Neue Pruefung ohne Oberflaeche, "SkuSelfTest pathmemory": sie gibt aus, was auf diesem Rechner vermerkt ist, und spielt Schreiben, Lesen und die Faelle veralteter Notizen gegen einen Wegwerfspeicher durch, ohne den echten anzufassen.

Das Lesefenster laesst sich einstellen

Einfach: Questtexte, Tooltips, der Chatverlauf und die Wiki-Seiten landen alle im selben Lesefenster. Wie dieses Fenster aussieht, stand bisher fest im Code: Playfair Display in 12 Punkt, eine duenne Schrift mit Serifen in der kleinsten Groesse, die das Addon ueberhaupt verwendet. Fuer jemanden mit Restsehvermoegen war das ausgerechnet die wichtigste Flaeche im Addon und zugleich die am schlechtesten lesbare. Unter Einstellungen -> Visuelle Hilfen -> Textfenster stehen jetzt Schriftgroesse von 14 bis 44 Punkt, vier Schriftarten, vier Farbkombinationen (weiss auf schwarz, gelb auf schwarz, schwarz auf weiss, weiss auf blau), die Deckkraft des Hintergrunds und ein Umriss zur Wahl. Ab Werk laeuft das Fenster jetzt serifenlos in 18 Punkt. Wer nichts umstellt, bekommt also trotzdem eine deutlich besser lesbare Flaeche als vorher.

Technisch: Die Flaeche selbst gehoert Libs/SkuTTS-1.0 (Frame SkuTTSMainFrame samt FontString .FS); dort stand die Darstellung als ein einziger harter SetFont-Aufruf. Die Einstellungen liegen jetzt in SkuCore VisualAids unter visualAids.textWindow, und SkuTTS:Output ruft vor jedem Anzeigen VisualAids:TextWindowLayout auf - pcall- gesichert und in derselben Richtung, in der SkuZOptions schon den Lesebalken fuettert. Die Lib muss so nichts ueber die Optionen wissen, und ein abgeschaltetes Modul Visuelle Hilfen laesst das Fenster einfach beim alten Aussehen. Jede Schriftzuweisung ist geprueft und faellt auf die Client-Standardschrift zurueck, statt eine leere Flaeche zu hinterlassen - die beiden mitgelieferten Familien Raleway und Playfair liegen unter Libs/SkuTTS-1.0/fonts und kommen nur ueber das Release-ZIP mit. Die Groessenstufen sind bewusst kleiner als beim Lesebalken: hier steht ein ganzer Questtext, und das Fenster hat keinen Rollbalken, schneidet also unten umso frueher ab, je groesser die Schrift ist. Gesprochen wird weiterhin alles, die Anzeige ist die Zweitspur.

Der Lesebalken zeigt, was Sku sagt - und er funktioniert im Kampf

Einfach: Zwei Dinge auf einmal. Erstens blieb der Balken im Kampf leer, also genau dann, wenn Vorlesen und Mitlesen am wichtigsten sind. Zweitens zeigte er nur den Namen eines Menueeintrags: bei einem Ein/Aus-Schalter stand dort der Name, aber nicht der Zustand, bei einer Taschenzeile der Name, aber nicht die Anzahl - alles, was Sku zusaetzlich vorliest, fehlte auf dem Balken. Beides ist behoben; der Balken zeigt jetzt dieselbe Zeile, die Sku spricht, und er tut es auch mitten im Kampf. Ausserdem sind Schriftart und Farbkombination jetzt auch fuer ihn waehlbar, mit eigenen Werten neben denen des Textfensters.

Technisch: Die Kampf-Sperre war eine Verwechslung von sichtbar und offen: die Pruefung haengte an SkuOptions:IsMenuOpen(), und das testet OnSkuOptionsMain:IsVisible(). Dieser Frame ist Vorfahr der sicheren ENTER-Buttons und damit geschuetzt, sein Show() ist im Kampf blockiert - das Kampfmenue laeuft absichtlich headless und meldet sich stattdessen ueber SkuOptions.combatMenuActive. Genau dieses Paar pruefen templates.lua und SkuZOptions ohnehin schon; der Lesebalken kannte es nur nicht. Er selbst ist ein gewoehnlicher Frame ohne sichere Kinder, sein Show() war im Kampf nie das Problem. Weil das Kampfmenue nur logisch schliesst (der Frame-Hide ist dort geschuetzt) und das an sechs Stellen tut, blendet sich der Balken jetzt selbst aus: ein OnUpdate prueft alle 0,25 s, ob das Menue noch offen ist - WoW ruft OnUpdate ausschliesslich bei sichtbaren Frames auf, im ausgeblendeten Zustand kostet das also nichts. Der Inhalt war schlicht ein weggeworfener Parameter: der Aufrufer uebergab immer schon den vollstaendigen Sprechstring, angezeigt wurde trotzdem currentMenuPosition.name. Jetzt hat der uebergebene String Vorrang, die Semikolons der Sprechtrennung werden fuer die Anzeige zu Bindestrichen.

Namensplaketten: die Einstellungen, die das Spiel versteckt

Einfach: Der Client kann seine Namensplaketten laengst groesser, farbiger und kontrastreicher darstellen - er bietet es nur nirgends an. Blizzards eigenes Optionsfenster zeigt in Classic keine einzige dieser Einstellungen; die Checkbox fuer groessere Plaketten, die es im aktuellen WoW gibt, ist in Classic ausdruecklich leer gelassen. Ohne Sku kaeme man nur ueber Konsolenbefehle heran. Das neue Menue unter Einstellungen -> Visuelle Hilfen -> Namensplaketten macht sie zugaenglich: Plakettengroesse, Hervorhebung des Ziels, Abschwaechung aller uebrigen Plaketten, Klassenfarben fuer Gegner und Verbuendete sowie nur Namen bei freundlichen Spielern. Anders als die aelteren Plaketten-Farben faerbt das nicht etwas hinter die Plakette, sondern veraendert die echte Plakette selbst. Ab Werk steht alles so, wie der Client es ausliefert - wer nichts auswaehlt, sieht keine Veraenderung.

Technisch: Reine CVar-Einstellungen, kein eigener Frame, kein Taint. Plakettengroesse setzt nameplateMinScale und nameplateMaxScale gemeinsam (getrennt ergaebe das eine entfernungsabhaengige Skalierung, die hier niemand will), Hervorhebung setzt nameplateSelectedScale, Abschwaechung nameplateMinAlpha, dazu nameplateShowClassColor, nameplateShowFriendlyClassColor und nameplateShowOnlyNameForFriendlyPlayerUnits. Alle Werte und die Existenz jeder einzelnen CVar wurden am lebenden Client 2.5.6.69546 gemessen, die Obergrenze 2.0 gegen die Klemmung des Clients geprueft. Wichtig fuer kuenftige Arbeit: die entpackte BlizzardInterfaceCode im Client-Ordner ist ein Abzug von Maerz/April 2026 und damit aelter als die Plaketten-Umstellung vom Juli; sie nennt Retail-Namen wie NamePlateVerticalScale oder ShowClassColorInNameplate, die es in dieser exe gar nicht gibt. Massgeblich sind die Strings der exe. Schreibzugriffe auf CVars sind im Kampf gesperrt und scheitern still, eine dort gemachte Aenderung wird deshalb vorgemerkt und bei PLAYER_REGEN_ENABLED nachgeholt. Beim Login zieht Sku die Werte nach, aber erst, nachdem im Menue wirklich einmal etwas ausgewaehlt wurde - wer seine Plaketten frueher von Hand per Konsole eingestellt hat, behaelt sie unangetastet.

Die Plaketten-Farben ueberleben einen Neustart

Einfach: Wer die Plaketten-Faerbung einschaltete, hatte sie genau so lange, bis er sich neu einloggte oder die Oberflaeche neu lud. Danach stand der Schalter weiter auf an, gefaerbt wurde aber nichts mehr. Wieder in Gang brachte man es nur, indem man den Schalter von Hand aus- und wieder einschaltete - und das in jeder Sitzung erneut. Das ist behoben; die Einstellung wirkt jetzt einfach.

Technisch: Das Scharfschalten des Ereignis-Treibers (NAME_PLATE_UNIT_ADDED, _REMOVED und PLAYER_TARGET_CHANGED) haengte ausschliesslich am OnAction des Menue-Schalters. Der gespeicherte Wert wurde beim Laden zwar gelesen, aber nirgends angewandt, also war nach jedem Login kein einziges Ereignis registriert. Das Armieren sitzt jetzt in VisualAids:OnEnable, wo die Folgen-Warnung und der Naechster-Gegner-Button schon immer armiert wurden, mit einem verzoegerten zweiten Versuch fuer den Fall, dass das Profil beim ersten Durchlauf noch nicht steht.

Ein geschlossenes Fenster wird nicht mehr nachtraeglich angesagt

Einfach: Wer beim Lehrer schnell mehrere Zauber lernte, das Fenster zuegig schloss und dann sein Berufsfenster oeffnete, hoerte nach einer Weile wieder das Lehrerfenster - manchmal erst, nachdem er einen Tooltip gelesen hatte. Sku merkte sich, wohin es im Menue eigentlich noch springen wollte, und holte das spaeter nach, ohne zu pruefen, ob es dieses Fenster ueberhaupt noch gibt.

Technisch: Der aufgeschobene Menuesprung besteht aus drei Feldern (openMenuAfterCombat, openMenuAfterMoving, openMenuAfterPath), die bisher unabhaengig voneinander beschrieben wurden. SlashFunc setzt Merker UND Pfad gemeinsam; andere Stellen setzten nur den Merker - und erbten damit den Pfad, der noch herumlag. Geloescht wurde der Pfad ausserdem nur im verzoegerten Teil von CheckFrames, der in Bewegung abbricht und erst eine halbe Sekunde spaeter nachfasst, waehrend die Freigabe im Bild-Takt genau in dem Moment feuert, in dem man stehen bleibt - ein Rennen, das die Freigabe gewann. Die drei Felder sind jetzt eine Einheit (SkuCore:ClearDeferredMenuOpen), das Setzen eines Merkers loescht den Pfad, und geleert wird im Hide-Hook des Fensters (SkuCore:GENERIC_OnClose) - also genau dann, wenn der Sprung ungueltig wird. Bewusst ohne Verfallszeit und ohne Sichtbarkeitspruefung: der Zustand wird dort geloescht, wo er falsch wird, statt einem Fehler davonzulaufen.

Das Menue oeffnet nicht mehr von selbst die oberste Ebene

Einfach: Ab und zu ging das Menue von allein auf - und dann auch noch ganz oben, statt dort, wo man hinwollte.

Technisch: SkuCoreControlOption1 haelt Tastenbelegungen (Zielentfernung, Panikmodus, Minikartenscan, Flug abbrechen, zu Einheit drehen) und hat mit dem Menue nichts zu tun. Sein OnShow bricht ab, solange man sich bewegt oder im Kampf ist, weil SetOverrideBindingClick dort nicht erlaubt ist und einer gehaltenen Bewegungstaste das Loslassen wegnehmen wuerde - es brach aber ab, indem es openMenuAfterMoving setzte, und die Freigabe machte daraus mangels Pfad ein Menue-Oeffnen auf der Wurzel. Der Frame hat jetzt seinen eigenen Merker (rebindControlKeysAfterBlock) und bekommt nur noch seine Tasten zurueck.

Das Schliessen eines zweiten offenen Fensters wird wieder bemerkt

Einfach: Waren zwei Fenster gleichzeitig offen - etwa Haendler und Taschen -, wurde nur das erste Schliessen bemerkt. Beim zweiten baute sich das Menue nicht neu auf und schloss sich nicht.

Technisch: Einer der beiden Hook-Installateure klammerte Show und Hide um einen einzigen gemeinsamen Schalter (SkuDropdownlistGenericFlag): jedes Show setzte ihn, und nur das erste Hide danach verbrauchte ihn. Welcher Installateur ein Fenster erwischte, war reine Zeitfrage - dieser nimmt alles, was eine Sekunde nach dem Betreten der Welt existiert, waehrend Fenster wie Lehrer, Beruf und Auktionshaus erst spaeter entstehen und dem anderen zufallen. Der Schalter ist weg; GENERIC_OnClose fasst ohnehin selbst zusammen.

Kein Inhalt eines geschlossenen Fensters mehr unter "Lokal"

Einfach: Nach dem Schliessen eines Fensters konnten dessen Eintraege unter "Lokal" stehenbleiben und beim naechsten Oeffnen des Menues noch einmal auftauchen.

Technisch: SkuCore.GossipList ist die Datenquelle des Lokal-Menues, wurde aber nur geleert, wenn das Menue in genau diesem Moment offen war. Beim Schliessen per Escape ist es das nie: der Menue-Frame geht absichtlich vor den Fenstern zu, und der zustaendige Programmteil laeuft ein Bild spaeter. Jetzt wird geleert, sobald kein Fenster mehr offen ist.

Lehrer: nach dem Schliessen ist Ruhe

Einfach: Wer mehrere Zauber schnell hintereinander lernte und das Fenster gleich danach schloss, hoerte die Ansagen des Lehrers noch weiter.

Technisch: Jeder Klick auf "Erlernen" stellte eine Neuerfassung nach einer halben Sekunde und eine Ansage nach 0,85 Sekunden in die Warteschlange, ohne Abbruchmoeglichkeit. Beide Schritte pruefen jetzt, ob ClassTrainerFrame ueberhaupt noch sichtbar ist. Die Sperre aus v43.1, die nicht in ein geschlossenes Menue hineinspricht, half hier nicht: sobald das naechste Fenster das Menue wieder oeffnete, war sie offen. Ausserdem verlor die Wiederholung stiller Neuerfassungen in Bewegung ihren Stumm-Auftrag und wurde je Klick einmal eingeplant - sie traegt ihre Argumente jetzt mit und laeuft nur noch einmal.

Auktionshaus: die Trefferliste ist wirklich sortiert

Einfach: Wer nach "Level absteigend" sortierte, bekam trotzdem eine Liste, die mit niedrigstufigem Kram anfing. Sortiert wurde naemlich nur innerhalb einer Seite - und eine Seite sind die 50 billigsten Auktionen. Ganz oben stand also das Hoechststufige unter dem billigsten Graugut, waehrend die Stufe-70-Sachen Hunderte Eintraege weiter unten lagen. Auch nach dem Fertig-Ton, denn nachsortiert wurde nie. Jetzt sortiert der Server die Trefferliste selbst nach Stufe; bei gleicher Stufe entscheidet der Preis je Stueck.

Technisch: Jede Abfrage ging mit fest verdrahteter Server-Sortierung "unitprice" raus, und die Ergebnisliste wird seitenweise und nur anhaengend aufgebaut (neue Gegenstaende kommen ans Ende, damit der Cursor des Nutzers nicht springt). Die Reihenfolge der Liste ist damit immer die des Servers, die eigene Sortierung wirkt nur je Seite. Bei "Level auf-" und "absteigend" wird die Server-Antwort jetzt nach der Spalte "level" sortiert - genau die Spalte, die auch Blizzards eigener Stufen-Sortierknopf setzt. Kauf und Strategiekauf bleiben auf "unitprice", die brauchen den guenstigsten Treffer auf Seite 0. Eine Namenssuche ebenfalls: dort haben alle Treffer dieselbe Stufe, der Server haette nach einem Feld sortiert, in dem sich nichts unterscheidet, und die Seiten kaemen in seiner Zufallsreihenfolge statt der billigsten zuerst. Zusaetzlich haben die Stufen-Vergleiche jetzt den Stueckpreis als zweiten Schluessel; Nur-Gebot-Auktionen zaehlen dabei mit ihrem Gebot je Stueck statt mit einem Kaufpreis von 0.

Auktionshaus: "Stufe" heisst ueberall Stufenanforderung

Einfach: Die Stufe in den Ergebnissen war mal die Stufenanforderung, mal die Gegenstandsstufe - je nachdem, aus welcher Liste sie kam und ob der Gegenstand ueberhaupt eine Anforderung hat. Ein Stapel Netherstoff (Anforderung 0, Gegenstandsstufe 55) stand damit ueber einem Stufe-40-Schwert. Jetzt ist es immer die Stufenanforderung, also die Spalte, die auch das Auktionshaus selbst "Stufe" nennt. Und sie wird nur noch dort vorgelesen, wo sie die Eintraege unterscheidet: in einer Kategorie oder in der Komplettscan-Liste. Eine Suche nach einem Gegenstandsnamen liefert lauter Auktionen desselben Gegenstands - dort war es 800 Mal dieselbe Zahl. Wer nach Stufe filtert, bekommt sie weiterhin ueberall angesagt.

Technisch: Ein gemeinsamer Leser fuer beide Ergebnislisten: Feld 6 der Server-Antwort, sonst der Wert aus SkuDB. Feld 7 wird beachtet - bei Rezepten steht in Feld 6 der geforderte Berufs-Skill, bei Behaeltern die Zahl der Taschenplaetze, beides keine Stufe. Die Gegenstandsstufe wird nie mehr ersatzweise eingesetzt. 0 heisst jetzt "keine Anforderung" statt "unbekannt", weshalb auch kein "Level 0" mehr angesagt wird (0 ist in Lua wahr, deshalb kam es ueberhaupt heraus).

Auktionshaus: "Nur benutzbare" versteckt nichts mehr

Einfach: In der Komplettscan-Liste liess dieser Filter in manchen Kategorien nur noch niedrigstufiges Zeug uebrig - ausgerechnet das Hochstufige, nach dem man sucht, war weg. In der normalen Suche war das nie so.

Technisch: In der Live-Liste filtert der Server. Der Komplettscan holt alles ungefiltert, Sku entscheidet selbst - bisher stur nach dem Feld canUse aus der Scan-Antwort. Das kann der Client nur fuellen, wenn er die Gegenstandsdaten der Zeile schon hatte; beim Komplettscan hat er sie fuer den Grossteil der Zeilen nicht. Es sind genau dieselben Zeilen, fuer die Name, Stufe und Qualitaet nachgetragen werden muessen - nur fuer canUse gab es keine Nachbesserung. Damit verschwand, was der Spieler noch nie gesehen hat, und das ist ueberwiegend das Hochstufige. Jetzt zaehlt ein "nicht benutzbar" nur bei vollstaendiger Zeile; sonst entscheidet die Stufenanforderung aus SkuDB. Klassen- und Rassenbeschraenkungen kennt die Datenbank nicht - im Zweifel wird lieber ein Gegenstand zu viel gezeigt als der gesuchte verschwiegen.

Auktionshaus: ohne Filter wird nicht gefiltert

Einfach: Die Komplettscan-Liste liess auch ohne gesetzten Filter alles weg, was keine Stufenanforderung hat - Handelswaren, Materialien, viele Rezepte - und ausserdem alles Graue, obwohl das Qualitaetsmenue unveraendert "Arm" anzeigte, also "keine Einschraenkung".

Technisch: Die Vorgaben der ungesetzten Filter waren je eine 1 statt einer 0, und die Stufe wurde roh aus der Scan-Antwort gelesen. Eine Zeile, deren Stufe der Client beim Scan nicht kannte, kam als 0 zurueck und fiel damit unter die Mindeststufe 1; die Reparatur aus der Datenbank sprang nur bei einem fehlenden, nicht bei einem 0-Wert an. Beide Vorgaben sind jetzt 0, die Stufe kommt aus dem gemeinsamen Leser, und die Nachbesserung beim Einlesen behandelt 0 als "fehlt". Der frueher als letzter Ausweg eingesetzte eigene Mindeststufen-Wert ist weg: eine Zeile bestand damit immer ihren eigenen Filter und wurde auch noch mit dieser Stufe angesagt.

Auktionshaus: Kategorien ohne Unterkategorien zeigen wieder Gegenstaende

Einfach: Unter "Auktionen nach Gegenstand" gab es Kategorien, die ausser "Alle" nichts enthielten - zum Beispiel Questgegenstaende.

Technisch: Die Gegenstandsliste verglich die Unterklasse auch dann, wenn es gar keine gibt. Eine Kategorie ohne Unterkategorien wird ohne Unterklasse aufgebaut, und der Vergleich ist dann fuer jeden Gegenstand falsch. Der Komplettscan-Zwilling hatte die Absicherung von Anfang an, die Gegenstandsliste jetzt auch.

Auktionshaus: ein abgebrochener Kauf bleibt abgebrochen

Einfach: Wer einen Kauf abbrach und danach etwas anderes tat, konnte aus dem Nichts wieder den Kauf-Dialog bekommen - und die naechste Eingabetaste, die eigentlich das Suchfeld oeffnen sollte, kaufte. Gekauft wurde immerhin das Richtige, aber ungefragt.

Technisch: Der Abbruch loeste Timer und Tastenbelegungen, loeschte aber das Kaufziel nicht. Die Abfragefunktion erkennt ihren Modus genau daran - es gibt ein Kaufziel, also ist das eine Kauf-Abfrage -, und so lief die naechste, voellig fremde Abfrage des Nutzers in den Kauf-Pfad: der fand das alte Ziel in der frischen Liste wieder, baute den Dialog auf und schaltete die Eingabetaste scharf. Im Log vom 01.09.2026 liegen Abbruch (18:45:40), neue Suche (18:46:12, sofort "MATCH FOUND, showing popup") und der Kauf (18:46:16, "Gebot akzeptiert") nur vier Menue-Tastendruecke auseinander. Das Kaufziel wird jetzt an den drei Stellen geloescht, an denen der Kaufwunsch endet: Abbruch des Dialogs (auch durch die 30-Sekunden-Sicherung), Start einer neuen Suche oder Liste, und Schliessen des Auktionshauses. Der Kaufweg selbst bleibt unangetastet - er laeuft nicht ueber den Sucheinstieg, und die Wiederholung nach einem verlorenen Wettlauf behaelt ihr Ziel.

Auktionshaus: eine abgebrochene Suche sagt es

Einfach: Bricht eine Suche ab, weil der Server nicht mehr antwortet, blieb die halb gefuellte Trefferliste stehen und sah aus wie ein fertiges Ergebnis. Jetzt kommt "Suche abgebrochen, Liste unvollstaendig".

Technisch: Der Waechter beendet eine seitenweise Suche nach 60 Sekunden ohne Server-Antwort bzw. nach 180 Sekunden Gesamtdauer - bisher lautlos. Der Fertig-Ton ist das Signal fuer "vollstaendig", sein Ausbleiben aber hoert man nicht. Angesagt wird nur, wenn der Nutzer auch wirklich in dieser Ergebnisliste steht; laeuft die Suche im Hintergrund, bleibt es still.