Sku v43.2 - notes de version

Aperçu

Nouveautés

Changements

Corrections

Nage et vol : le verrouillage de l'inclinaison met fin à la plongée involontaire

Simple : En nageant ou en volant, chaque virage automatique vers la balise tirait un peu vers le bas - sur une longue distance, cela s'additionnait jusqu'à se retrouver sous l'eau ou au sol sans s'en apercevoir. Désormais Sku verrouille l'inclinaison dès que vous nagez ou volez : vous vous déplacez parfaitement à l'horizontale, et Espace et X continuent de vous porter vers le haut et vers le bas. Et si quelque chose vous incline malgré tout - par exemple l'approche automatique en interagissant avec un PNJ - Sku vous redresse activement : à l'ouverture de la fenêtre du PNJ, peu après chaque virage, et à chaque appui sur monter ou descendre. Activé par défaut ; qui veut plonger à la souris en inclinant la vue (vision résiduelle) le désactive sous Paramètres -> Général. S'y ajoute le nouveau raccourci « verrouillage de l'inclinaison » (Ctrl+Maj+N) pour verrouiller et libérer manuellement.

Technique : Trois éléments. Premièrement, la variable console pitchlimit 0 plafonne l'inclinaison de déplacement du personnage (la technique des addons LevelFlight et FlightHUD) - posée durablement plutôt qu'autour de chaque impulsion de virage, car c'est exactement cette course au basculement qui a fait échouer les tentatives précédentes. pitchlimit s'écrit mais ne se lit pas ; chaque connexion rétablit donc aveuglément la valeur par défaut 88, pour qu'un verrouillage ne reste jamais coincé. Deuxièmement, le verrouillage ne fait que conserver ce qui est : un déplacement piloté par le moteur, comme l'approche d'interaction, incline quand même le personnage, et ensuite aucune touche du clavier ne permet de relever l'inclinaison. Le redressement actif utilise précisément le transfert qui causait le bug à l'origine : ResetView/SetView cale la caméra sur le préréglage par défaut connu, presque horizontal, une impulsion mouselook le transfère au personnage, et le verrouillage plafonne le petit reste à zéro. Les déclencheurs sont la fenêtre du PNJ, chaque virage (différé de 0,5 s, car le moteur n'applique le transfert de cap qu'une frame plus tard - une seconde impulsion immédiate annulerait le virage) et, via hooksecurefunc, les fonctions monter/descendre JumpOrAscendStart, AscendStop, SitStandOrDescendStart et DescendStop - quelles que soient les touches où elles sont assignées. Troisièmement, un inclinomètre pour le journal : la vitesse horizontale mesurée divisée par GetUnitSpeed donne le cosinus de l'angle de trajectoire - la seule mesure que ce client offre (GetUnitPitch a été retiré au patch 7.1 et manque ici aussi). Il mesure la trajectoire, pas l'inclinaison du corps, et ne sert qu'au diagnostic.

Le curseur reste sur l'objet dans le sac

Simple : Faire un clic droit sur un objet de la liste des sacs - l'utiliser, l'équiper, le vendre à un marchand, appliquer un enchantement - vous déposait sur la première entrée de toute la liste. Pour les objets qui disparaissent aussitôt, cela se voyait à peine, puisque la liste se réordonne de toute façon ; pour tout le reste, c'était simplement une position perdue. Désormais le curseur reste sur l'objet sur lequel vous avez travaillé, et quand l'objet quitte le sac, vous atterrissez sur son emplacement, c'est-à-dire sur ce qui a pris sa place.

Technique : La cause n'a jamais été un décalage d'indices, mais la troisième ligne de la macro de clic droit, « /script SkuCore:CheckFrames() ». Elle datait d'avant la confirmation pilotée par les événements et s'exécutait AU MOMENT DE LA TOUCHE - donc avant que l'action ait changé quoi que ce soit, et pour une action avec temps d'incantation, plusieurs secondes avant. Elle reconstruisait donc des données périmées et coûtait la position pour rien. Supprimée ; le rafraîchissement appartient à la seule confirmation pilotée par BAG_UPDATE, qui ne reconstruit qu'une fois les sacs réellement stabilisés et réaccroche alors le curseur par emplacement de sac et identifiant d'objet. De plus, CheckFrames ne retient plus seulement le numéro de ligne de l'entrée à travers une reconstruction, mais aussi son nom, qu'il recherche dans la liste reconstruite - le numéro de ligne seul cesse d'être juste dès que la liste a eu une autre forme entre-temps.

Enchantements, appâts et huiles : la liste se rafraîchit après l'incantation

Simple : Un enchantement, un appât de pêche, une huile d'arme, un kit d'armure ou un désenchantement ne modifient les sacs qu'une fois l'incantation terminée, souvent cinq secondes après le clic. Sku avait depuis longtemps renoncé : la liste restait périmée et le curseur se trouvait quelque part. Désormais Sku attend la fin de l'incantation, annonce ensuite l'objet une fois et y laisse le curseur. Si vous naviguez vous-même entre-temps, vous gardez votre propre position - Sku ne s'en mêle plus.

Technique : La fenêtre de confirmation ouverte par le clic droit expirait au bout de 2,5 secondes. UNIT_SPELLCAST_START/-CHANNEL_START repoussent maintenant son échéance jusqu'à la fin de l'incantation tout en conservant l'ancre saisie au clic, de sorte que le réaccrochage retombe exactement sur l'objet traité. Volontairement sans liste de sorts : une fenêtre ouverte est en elle-même la preuve que cette incantation appartient à l'action. Deux garde-fous stricts, tous deux appris d'un cas réel : l'incantation doit suivre le clic dans la seconde (« /use » la déclenche dans la même image), et le report n'a lieu qu'une seule fois. Sans eux, une pêche de 22 secondes repoussait l'échéance devant elle sans fin et la fenêtre ne mourait jamais.

La boîte de dialogue de confirmation ne coûte plus la position

Simple : Appliquer un enchantement sur un objet déjà enchanté déclenche la question de Blizzard « Remplacer l'enchantement existant ? ». Après « Oui » ou « Non », on se retrouvait tout en haut de la hiérarchie des sacs, sur « Sac 1 » au lieu de l'objet. Désormais, les deux réponses ramènent à l'objet, et il est annoncé une fois.

Technique : La boîte de dialogue est une fenêtre modale entre le clic et son effet, et elle cassait la position doublement : l'échéance de 2,5 secondes expirait pendant qu'elle était affichée, et Sku ancre le menu DANS la boîte, si bien qu'à sa fermeture il ne restait rien où revenir - l'entrée générique prenait alors la seule fenêtre ouverte et atterrissait en haut de la liste des sacs. SkuBagPostActionPopupGate maintient la fenêtre ouverte tant que la boîte est affichée (jusqu'à 30 secondes) et déclenche la confirmation à sa fermeture. C'est le bon outil précisément parce qu'il couvre les deux réponses : « Non » ne produit ni incantation ni changement de sac, rien d'autre ne pourrait donc jamais replacer le curseur. Tant que la boîte est affichée, la confirmation s'abstient entièrement - sinon un changement de sac sans rapport (du butin qui arrive, un échange qui se conclut) arracherait le curseur hors de la boîte.

Le filtre de saisie de la liste des sacs se lève à nouveau

Simple : Taper un nom dans la liste des sacs la filtre sur les correspondances. Ce filtre ne se levait plus dès que vous aviez utilisé l'objet filtré : même flèche gauche puis droite ne ramenait pas la liste complète, seule la fermeture des sacs y parvenait. Désormais, chacune de ces touches lève à nouveau le filtre, comme vous en avez l'habitude. Quand rien ne correspond au filtre, la liste reste vide comme avant et les flèches ne font que répéter le filtre saisi - c'est précisément ainsi que l'on entend qu'il n'y a aucun résultat.

Technique : SkuOptions:ClearFilter n'oubliait que le texte saisi ; la liste d'enfants filtrée installée par ApplyFilter restait dans l'arbre jusqu'à ce que quelque chose la remplace intégralement - et un niveau construit à partir des fenêtres du jeu, comme les sacs, ne peut pas se rafraîchir sur place, il lui faut une reconstruction complète. Masqué pendant des années par le CheckFrames forcé de la macro (voir ci-dessus), cela est apparu dès qu'une action ne modifie pas du tout les sacs. ClearFilter restaure maintenant réellement la liste, chaînages avant et arrière compris, et ce sur le nœud qu'il a filtré et non sur celui qui a le focus.

Échap ne fermait pas le menu lorsqu'on se tenait juste sur un objet de quête

Simple : Se tenir à environ zéro mètre devant un objet de quête et fermer le menu avec Échap faisait aussitôt remonter la fenêtre de quête - sans fin. À cet endroit, le menu ne pouvait pratiquement plus être fermé. Désormais les fenêtres de jeu ouvertes sont fermées d'abord, et le menu lui-même ensuite.

Technique : Le menu se cachait d'abord et traitait ensuite les fenêtres d'interaction ouvertes. Le cadre de quête était donc fermé alors que le jeu signalait toujours l'objet à portée, et il se rouvrait immédiatement. L'ordre est maintenant inversé et protégé par un compteur que « /skucheck menu » relit : une violation de cet ordre se remarque sans que quiconque ait à se tenir par hasard exactement à cet endroit.

Moins de reconstructions en double à la fermeture d'une fenêtre

Simple : Un seul Échap déclenchait jusqu'à six reconstructions complètes des données du menu, parce que plusieurs fenêtres se ferment en même temps et que la fenêtre de quête de Blizzard à elle seule masque quatre sous-panneaux. Cela coûtait un temps perceptible. Désormais, exactement une reconstruction s'exécute par image. Par ailleurs, la liste des sacs tenue pour le combat pouvait se périmer lorsqu'une fenêtre de quête était fermée alors que les sacs étaient ouverts - un défaut qui ne serait apparu que plus tard, en combat.

Technique : Les chemins de masquage passent par SkuCore:CheckFramesCoalesced, dont le verrou s'ouvre une fois par image ; le passage effectif est de toute façon différé de 0,01 s et lit l'état vivant, il voit donc exactement ce qu'aurait vu le dernier appel de la rafale. Le côté OnShow est volontairement laissé de côté. La comptabilité de GENERIC_OnClose a reçu son propre verrou : elle dépendait auparavant de la valeur de retour de ce même verrou partagé, et comme les sous-panneaux de quête se déclenchent en premier, ils le consommaient et la comptabilité - dont le rafraîchissement de la liste des sacs de combat - était sautée.

Synthèse vocale : les annonces ne restent plus muettes

Simple : Pendant la navigation, la voix se taisait régulièrement pendant un moment - une touche fléchée ne lisait tout simplement pas l'entrée, dans le calme et sans que rien d'autre ne tourne. C'était le plus reproductible quand on filtrait une liste jusqu'à un seul résultat puis qu'on allait vite et venait entre le filtre et ce résultat : après quelques passages, le résultat restait définitivement muet, même en attendant une seconde. Les deux sont corrigés.

Technique : Deux causes indépendantes, toutes deux sous la file d'attente - Sku avait transmis proprement chaque annonce ; sur une capture de 95 minutes, chaque appui produisait exactement un SpeakText avec un STARTED.

D'abord, la même ligne était réémise jusqu'à quatre fois en une seconde, parce qu'une vérification de fenêtre superflue réannonce l'entrée de menu ; 95 des 1512 énoncés étaient de telles répétitions. Chacune apporte son propre « queuereset », donc un StopSpeakingText, et celui-ci atteint bel et bien le lecteur d'écran - la ligne était donc coupée en plein mot puis reprise, et quand le renvoi se perdait en chemin il ne restait rien. Le garde-fou anti-doublon existant ne pouvait rien y faire : il dépend de VOICE_CHAT_TTS_PLAYBACK_FINISHED, et via le pont vers le lecteur d'écran STARTED et FINISHED reviennent dans la même image - il y est donc toujours vide et ne peut jamais se déclencher. Un garde-fou temporel a été ajouté : il écarte une ligne identique immédiatement suivante dans la seconde, avec son queuereset ; n'écarter que le texte annulerait quand même la ligne en cours sans rien mettre à sa place.

Il ne se compare qu'à la ligne transmise juste avant, il ne peut donc pas avaler une vraie relecture, et il ne s'applique que si la première copie a réellement commencé à être jouée.

Ensuite, le casseur de cache ne fonctionnait plus. Le client range la parole synthétisée par texte et la rejoue lors d'une répétition sans rappeler la voix - via un pont, cette relecture est silencieuse. La parade était jusqu'ici un <bookmark> tournant, mais le client retire le balisage et n'indexe que sur le texte parlé : dans la capture, chaque énoncé portait sa propre marque et le résultat se taisait quand même. Le casseur d'origine faisait varier de vrais caractères et fonctionnait ; le passage à une marque devait ménager la prosodie et a discrètement ramené le défaut même contre lequel il avait été écrit. On rajoute donc du vrai texte : une suite tournante de 1 à 64 espaces insécables après le dernier mot, où elle n'est ni audible ni capable de colorer la prosodie.

Rassasié : une seule entrée dans le sélecteur de sorts

Simple : Qui voulait bâtir une aura sur le buff Rassasié trouvait dans le sélecteur de sorts deux entrées prononcées toutes deux « Rassasié ». Une seule pouvait se déclencher, l'autre était une fiche morte - laquelle on attrapait relevait du pur hasard et ne s'entendait pas. Il n'y a plus qu'une entrée, et c'est la bonne. Une aura déjà enregistrée pointant sur la mauvaise est basculée une fois à la prochaine connexion et fonctionne ensuite.

Technique : Depuis la v43.0, les auras sont tenues par l'identité anglaise d'un sort, afin que la même aura convienne dans toutes les langues. Or, dans la base de sorts livrée, dix lignes portent le nom anglais ENTRE GUILLEMETS - 44097 à 44106 ainsi que 69559 et 65365 portent le nom entouré de deux guillemets, là où les 65 autres le portent sans. Cela

créait une seconde identité derrière un seul et même nom localisé, et la désambiguïsation du menu ajoute dans ce cas l'identité anglaise : une entrée se lisait « Rassasié (Well Fed) », l'autre pareil mais avec deux guillemets supplémentaires autour de Well Fed. La synthèse vocale ne lit pas les guillemets : les deux entrées sonnaient donc à l'identique. Rassasié est le seul des 26 650 noms localisés du jeu de données dont les deux identités ne diffèrent que par ces caractères. Le nom est désormais déguillemeté lors de la formation de l'identité, et des DEUX côtés - dans la liste de valeurs et à chaque résolution d'un événement en cours - car ne changer qu'un côté produirait une valeur enregistrée qu'aucun événement ne peut plus atteindre. Seuls les noms encadrés de guillemets aux DEUX extrémités sont traités ; les 17 lignes restantes avec des guillemets à l'intérieur du nom (Goblin "Boom" Box, parfum « TRIUMPH ») les conservent, car ils y font partie du nom. Une migration unique bascule les auras enregistrées.

Les enchantements d'arme sont reconnaissables dans le sélecteur de sorts

Simple : Un appât de pêche, une pierre à aiguiser ou une huile d'arme n'est pas un buff mais un enchantement posé sur l'arme. Il n'apparaît dans aucune liste de buffs du jeu et ne déclenche aucun événement d'aura - une aura sur « événement = aura perdue et nom du sort = Compétence Pêche +75 » ne pouvait donc jamais se déclencher, alors même que l'entrée figure dans le sélecteur et sonne tout à fait normalement. De telles entrées portent désormais la mention « (enchantement d'arme) » dans tous les sélecteurs, afin que l'on entende de quoi il s'agit. Pour y réagir, on prend soit l'événement « Enchantement d'arme expiré », soit la condition « Ton enchantement d'arme main droite ». La mention n'est pas lue dans l'annonce d'une aura déclenchée.

Technique : La liste de valeurs de l'attribut « nom du sort » est la base de sorts complète, y compris les lignes qui n'atteignent le joueur que sous forme d'enchantement d'arme temporaire - l'appât est le sort 8084 derrière l'identifiant d'enchantement 265. Les identités concernées sont maintenant déterminées lors de la construction des listes (chaque identifiant de sort de l'identité est référencé par la base des enchantements) et reçoivent la mention. Volontairement SIGNALÉES plutôt que retirées : elles sont 395 et ne sont pas toutes inertes - Arme enflammée, Bourreau et Force impie sont des procédures d'enchantement qui apparaissent bel et bien sous ce nom exact dans le journal de combat. Les retirer aurait privé des auras fonctionnelles de leur seul moyen de les nommer. La mention emprunte le même mécanisme que la désambiguïsation anglaise et disparaît donc de nouveau dans l'énoncé d'une aura déclenchée.

Les enchantements d'arme s'adressent comme des sorts

Simple : Pour un sort de dégâts sur la durée, on écrit « événement égale aura perdue » et « nom du sort égale <sort> » - l'événement dit lui-même de quoi il s'agit. Pour un enchantement d'arme, c'était impossible : l'appât ne pouvait être nommé que par « ton enchantement d'arme main droite », qui est une question d'état et non d'événement. Sous la forme « contient », une telle aura ne pouvait même jamais se déclencher - quand l'événement arrive, l'enchantement a déjà disparu, la liste ne le contient donc plus. Seule la forme inversée « ne contient pas » fonctionnait. L'événement porte maintenant lui-même le nom de l'enchantement, et l'aura s'écrit exactement comme pour un sort : « événement égale Enchantement d'arme expiré » et « nom du sort égale Compétence Pêche +75 ». « ne contient pas » continue de marcher.

Technique : Les deux événements générés WEAPON_ENCHANT_REMOVED et WEAPON_ENCHANT_UPDATE plaçaient le nom de la MAIN dans le champ 13 - et le champ 13 est celui du nom du sort. Une condition sur « nom du sort » se comparait donc à « Main droite », et une sortie « nom du sort » annonçait la main au lieu de l'enchantement. C'est désormais l'enchantement qui s'y trouve : le champ 12 reçoit son identifiant de sort, le champ 13 son nom, l'un et l'autre par les mêmes résolveurs qui construisent la liste de valeurs - la valeur enregistrée est la même que pour la condition d'enchantement. Une expiration signale l'enchantement qui ÉTAIT là, c'est l'identité visée. Les auras existantes ne peuvent pas devenir muettes : « Main droite », « Main gauche », « Haupthand » et « Nebenhand » n'apparaissent pas une seule fois comme nom de sort dans les 49 117 lignes de la base de sorts ; une condition sur « nom du sort » ne pouvait donc de toute façon jamais correspondre sur cet événement. La main n'est pas perdue, elle passe dans son propre champ avec sa propre condition et sa propre sortie (« main de l'enchantement d'arme »), enregistrée sous forme de jeton neutre afin qu'une aura partagée désigne la même main dans toutes les langues. Ce qui n'a volontairement PAS été fait, c'est l'autre voie évidente - remplir la liste d'état lors d'une expiration avec l'enchantement sortant : la liste est partagée, elle mentirait à toutes les autres auras durant ce passage, réarmerait une barrière « ne contient pas » et produirait ainsi des annonces en double, et elle contredirait la durée restante, délibérément forcée à 0 lors d'une expiration. De plus, /skucheck auras signale désormais la combinaison « événement d'expiration plus contient » comme une aura qui ne peut jamais se déclencher. Corrigé au passage : lorsque seule la main gauche changeait, l'événement était tout de même signalé comme la main droite.

La fin d'un enchantement d'arme est détectée immédiatement

Simple : Le jeu n'annonce pas qu'un appât de pêche ou un poison a expiré - Sku regarde toutes les 0,25 seconde. L'annonce arrivait donc jusqu'à un quart de seconde trop tard. Elle arrive maintenant au moment de l'expiration.

Technique : La durée restante d'un enchantement est connue dès l'instant où on le voit - GetWeaponEnchantInfo renvoie le temps restant en millisecondes. Le ticker en retient la prochaine expiration, et le pilote de frame compare un nombre par frame puis appelle exactement le ticker joueur habituel. C'est la même construction que le planificateur d'échéances de durée introduit en v43.0 et cela ne coûte aucune interrogation supplémentaire. Les annonces en double sont exclues, car le ticker n'émet que si son état mémorisé a réellement changé. Volontairement NON fait : passer le ticker à chaque frame - ce serait quinze fois plus d'interrogations pour le même gain.

Basculer un réglage dans une liste filtrée annonce de nouveau le nouvel état

Simple : Restreindre une liste avec le filtre de saisie puis appuyer sur Entrée sur une entrée activé/désactivé retire le filtre - c'est voulu. L'entrée était bien basculée, mais on ne l'entendait pas : le curseur sautait en tête de liste et c'est la première entrée qui était annoncée, pas le nouvel état. Dans les sorties d'auras, l'aperçu sonore de la première entrée se déclenchait en plus. On reste désormais sur l'entrée que l'on vient de basculer et on entend son nouvel état.

Technique : Entrée retire le filtre AVANT d'exécuter l'action - le nœud de menu appelle ApplyFilter("") pour cela. Son nettoyage se terminait par un OnFirst() systématique sur le niveau, le curseur partait donc en tête de liste dans TOUS les cas. La bascule elle-même n'a jamais été en cause : elle agit sur le nœud lui-même (actionInPlace), pas sur le curseur. Seul ce qui était lu ensuite était faux - et OnFirst déclenchait au passage le OnEnter de la première entrée, c'est-à-dire l'aperçu sonore pour les sons d'auras. ApplyFilter("") suit maintenant la même règle que ClearFilter : la liste restaurée contient les MÊMES objets de nœud, un curseur posé sur une vraie entrée reste donc valide ; seule la ligne artificielle « Filter;<saisie> » n'y a plus sa place, et c'est pour elle seule que le OnFirst() complet, OnEnter compris, continue de s'exécuter, afin de ne pas perdre l'aperçu sonore à l'arrivée. Sans filtre actif, ApplyFilter("") n'a toujours rien fait - d'où le fait que basculer dans une liste non filtrée n'a jamais posé problème ; les deux cas se comportent désormais de la même façon. Effet de bord de la même règle : Retour arrière laisse maintenant le curseur sur l'entrée où il se trouvait au lieu de sauter en tête de liste.

Navigateur de donjons : accepter une invitation ne mène plus au navigateur

Simple : Si vous étiez inscrit dans le navigateur de donjons et acceptiez ensuite une invitation de groupe, vous vous retrouviez dans le navigateur sans avoir appuyé sur la moindre touche : le menu se rouvrait tout seul et le curseur se posait sur « Non inscrit ». Pour les joueurs voyants, rien ne se passe à ce moment-là - la fenêtre de recherche de groupe de Blizzard ne s'ouvre jamais lorsqu'on accepte une invitation. Sku reste désormais silencieux lui aussi : vous restez là où vous étiez.

Technique : Deux chemins y menaient, tous deux sont fermés. (1) Dès que le serveur supprime votre inscription - c'est exactement ce qu'il fait lorsque vous rejoignez un groupe -, LFG_LIST_ACTIVE_ENTRY_UPDATE arrive, et le navigateur reconstruisait alors son entrée de menu. Cette reconstruction se terminait par un SlashFunc vers son propre chemin de menu, et celui-ci rouvre un menu FERMÉ et y descend. Elle ne s'exécute plus que si le menu est ouvert ET que le curseur se trouve réellement dans le navigateur de donjons - ce n'est qu'alors qu'il faut replacer les entrées fraîchement construites sous le curseur. L'omettre ne coûte rien : l'entrée de menu est « dynamic » et se reconstruit de toute façon à la prochaine descente. Ainsi, aucun changement d'inscription que vous n'avez pas provoqué (expiration, modification par le chef de groupe) ne peut plus vous arracher à vos sacs pour vous jeter dans le navigateur. (2) Un tiers de seconde après la disparition de la fenêtre d'invitation, le navigateur vérifie s'il doit se rouvrir. Il demandait seulement « une fenêtre de recherche de groupe est-elle ouverte en ce moment ? » et en faisait une ouverture. Désormais, l'état présent à l'ARRIVÉE de l'invitation est mémorisé, et c'est exactement lui - et rien d'autre - qui est restauré. Si l'invitation vous a fait rejoindre un groupe, il ne se passe plus rien du tout : ni ouverture, ni fermeture.

Nouveau raccourci : lire l'infobulle complète de la cible

Simple : lors d'un changement de cible, Sku annonce un ensemble fixe et court - nom, niveau, élite ou rare, plus la deuxième ligne de l'infobulle avec le type de créature. Tout ce qui se trouve en dessous dans l'infobulle était jusqu'ici inaccessible : la ligne de faction, le marqueur JcJ et surtout ce que la compétence de chasseur Connaissance des bêtes révèle d'une bête - sa famille, son régime et si elle est apprivoisable. Le nouveau raccourci (par défaut : Ctrl+Maj+V) lit l'infobulle complète à la demande. Il n'agit que lorsqu'on appuie dessus : l'annonce de cible habituelle reste aussi courte qu'avant, et qui n'a pas besoin de ce détail ne l'entend jamais. C'est aussi pourquoi il n'y a pas d'option pour cela - appuyer sur la touche EST la demande. Sans cible fixe, la touche décrit la cible souple actuelle, ce qui permet aussi de décrire quelque chose sur quoi on ne s'est pas encore engagé. Réassignable dans Raccourcis clavier Sku, cible et ciblage souple.

Technique : l'idée, la démonstration et l'implémentation de référence viennent de ZenqFR, dans l'addon compagnon SkuBeastLore (github.com/ZenqFR/Sku-BeastLore) ; la sortie Connaissance des bêtes y a été testée sur un vrai chasseur. Ici la fonction est reconstruite nativement sur les interfaces de Sku, pour qu'aucun addon supplémentaire ne soit nécessaire. Les lignes de Connaissance des bêtes sont produites par le client lui-même dans l'infobulle d'unité ; aucun Lua de l'interface Blizzard ne les construit et aucune API ne les renvoie séparément - lire l'infobulle est le seul moyen d'y accéder. C'est aussi pourquoi une option distincte pour la seule information de chasseur n'est pas possible : ces lignes ne pourraient être isolées que par une comparaison de texte dépendante de la langue. SkuMob:OutputTargetTooltip résout target, softenemy, softfriend puis softinteract dans cet ordre et lit via le SkuScanningTooltip partagé de Sku. Comme ce frame est partagé - sacs, hôtel des ventes, liens de discussion et textes de quête lisent le même -, il est vidé avant ET après, et son propriétaire restauré exactement comme SkuCore le règle à la connexion.

Suivre une quête et retirer le suivi

Simple : le menu de chaque quête se termine désormais par une entrée « Suivre la quête ». Entrée la bascule, le curseur reste en place et le nouvel état est annoncé aussitôt - « Suivre la quête;Activé » ou « Suivre la quête;Désactivé ». Suivie signifie : le marqueur propre à WoW sur la minicarte et la carte du monde. Qui garde un reste de vue trouve ainsi ses objectifs plus vite ; qui ne voit rien n'en tire rien. L'entrée peut donc être désactivée entièrement - sous Réglages Sku, SkuQuest, « afficher l'entrée Suivre la quête » ; elle est active par défaut. Elle n'apparaît que pour les quêtes de votre propre journal, car une quête de la base de données de quêtes n'est pas encore la vôtre. Deux limites viennent du jeu lui-même : The Burning Crusade n'autorise que cinq quêtes suivies à la fois, et une quête sans aucun objectif ne peut pas être suivie. Dans les deux cas, Sku annonce le message du jeu et l'état reste inchangé.

Technique : l'idée et l'implémentation de référence viennent de ZenqFR, dans l'addon compagnon SkuQuestNearby (github.com/ZenqFR/Sku-QuestNearby) ; avec l'accord de ZenqFR, la fonction est ici reconstruite nativement sur les interfaces propres à Sku, afin qu'aucun addon supplémentaire ne soit nécessaire. L'entrée est placée dans le CreateQuestSubmenu local au fichier plutôt que sur un hook du wrapper public - c'est pourquoi toutes les vues de quête en bénéficient : journal de quêtes, base de données de quêtes et menus de quête de SkuChat. Il n'y a pas de C_QuestLog sur 2.5.6 : AddQuestWatch, RemoveQuestWatch et IsQuestWatched prennent un INDEX du journal de quêtes, pas un identifiant de quête, et cet index se décale à chaque quête acceptée ou rendue. Sku tient donc une correspondance identifiant vers index, revérifie l'index mémorisé à chaque lecture et abandonne la correspondance lors des événements de quête ; sans ce cache, la liste « base de données de quêtes, toutes » ferait un parcours complet du journal pour chaque quête. L'activation passe par AutoQuestWatch_Insert avec QUEST_WATCH_NO_EXPIRE, pour que la quête entre dans QUEST_WATCH_LIST et qu'aucun minuteur d'expiration ne l'en retire ; la désactivation supprime d'abord la ligne de QUEST_WATCH_LIST puis seulement appelle RemoveQuestWatch - exactement comme le chemin de clic de Blizzard, sinon une quête depuis longtemps non suivie continue de compter dans la limite de cinq. QuestWatch_Update ne s'exécute qu'en dehors du combat, car il finit par déplacer des cadres protégés ; le prochain QUEST_LOG_UPDATE s'en charge de toute façon.

Nouveau raccourci « Cibler la créature de quête la plus proche » (Alt+H)

Simple : Une pression cible une créature liée à un objectif de quête encore ouvert - y compris une créature qu'on n'a pas à tuer, mais qui se contente de faire tomber un objet requis. Exemple : pour « Essences pour les moteurs », le journal ne nomme que l'objet ; la touche cible malgré tout le Spectre de mana qui le fait tomber. Si rien ne correspond à portée, Sku annonce « aucune cible de quête à portée » ; si le journal ne contient rien de pertinent, « aucune cible de quête dans le journal ». La touche est sur Alt+H par défaut et se réassigne dans les raccourcis Sku, « Ciblage et ciblage souple ».

Technique : L'idée et l'implémentation de référence viennent de ZenqFR, dans l'addon compagnon SkuQuestTarget (github.com/ZenqFR/Sku-QuestTarget) ; la fonction a été reconstruite nativement avec l'accord de ZenqFR, pour qu'aucun addon supplémentaire ne soit nécessaire. Les candidats proviennent du journal de quêtes via SkuQuest:GetQuestTargetIds ; les objectifs de type objet sont remontés jusqu'aux créatures qui les font tomber (npcDrops, et un niveau plus loin itemDrops). La recherche commence par la zone où l'on se trouve - une créature sans point d'apparition sur place ne peut pas être à portée de ciblage et ne doit pas occuper une place dans la macro ; ce n'est que si rien n'est enregistré pour la zone que le tri se fait sur tout le continent. La distance retient le point d'apparition enregistré le plus proche, et non le premier de la liste. La macro est multiligne, et une particularité du jeu décide du résultat : chaque ligne qui correspond s'exécute et chaque correspondance écrase la précédente - c'est donc la DERNIÈRE qui gagne. Les candidats sont donc retenus du plus proche au plus lointain, afin que le budget de longueur ne coupe que le lointain, mais écrits à l'envers, pour que le plus proche soit la dernière ligne. La macro est reconstruite à chaque pression hors combat ; en combat, c'est le dernier texte construit qui part.

« Ennemi suivant en combat » trouve aussi ce qu'on ne regarde pas (Ctrl+H)

Simple : La touche ne trouvait que ce que l'on regardait déjà - le même ennemi à cinq mètres derrière soi ne donnait rien. Ce n'est pas un réglage, c'est le fonctionnement du ciblage par tabulation du jeu. Sku retient donc désormais les noms des créatures hostiles croisées et les essaie en plus par leur nom - et un nom fonctionne dans toutes les directions. En pratique : ce que l'on a vu, combattu ou ciblé une fois reste accessible de partout pendant deux minutes, même dos tourné. La recherche repart par ailleurs de l'ennemi le plus proche à chaque pression au lieu de continuer le cycle. La touche est sur Ctrl+H par défaut.

Technique : L'approche est reprise du SkuQuestTarget de ZenqFR, qui emprunte la même voie pour sa fonction secondaire. /targetenemy est la tabulation et cherche dans le cône de vue - rien ne peut changer cela. « /tar nom » interroge en revanche la liste de noms du client et ne dépend pas de l'orientation, mais il lui faut un nom, et aucune interface ne permet d'énumérer les unités situées derrière soi. Sku collecte donc les noms en continu depuis quatre sources : les plaques hostiles, sa propre cible, l'unité sous le curseur et la liste d'ennemis du moniteur de combat. La collecte tourne à la seconde tant que la touche est assignée, car une plaque n'existe que tant que la créature est en vue - c'est-à-dire précisément quand on n'a pas besoin de la touche. Seuls les noms y sont collectés ; la mesure de distance, coûteuse, ne tourne qu'une fois par pression. Les noms retenus durent deux minutes. La macro est « /cleartarget », puis « /targetenemy », puis les noms retenus du plus lointain au plus proche - la dernière ligne qui correspond l'emporte, donc la plus proche.

Nouvelle liste « Quêtes à proximité »

Simple : Le menu de quête possède désormais une troisième entrée, après « Quêtes actuelles » et « Base de données des quêtes » : « Quêtes à proximité ». Elle contient tout le journal de quêtes en UNE seule liste - quêtes en cours et quêtes terminées mélangées - triée selon la distance de ce qui compte actuellement pour chaque quête. Chaque entrée annonce d'abord la distance, puis le point cardinal, puis le type, puis le nom de la quête : « 180 Mètre ; nordest ; objectif de quête ; Kobolds voleurs » ou « 340 Mètre ; sud ; Rendre la quête ; Le chef de la meute ». Pour une quête aux objectifs encore

ouverts, c'est la distance jusqu'à l'objectif le plus proche ; pour une quête signalée terminée, la distance jusqu'au lieu de remise. « Quêtes actuelles »

regroupe selon les en-têtes du journal et trie donc par zone - la nouvelle liste répond à l'autre question : qu'est-ce qui est le plus proche d'ici. Entrée ouvre le même menu de quête que partout ailleurs, points de passage et entrée « Suivre la quête » compris. La liste est DÉSACTIVÉE par défaut et s'active sous Paramètres Sku, SkuQuest, « afficher l'entrée Quêtes à proximité » : elle recalcule tout le journal de quêtes contre la base de données de spawns de Sku à chaque ouverture, et seul celui qui s'en sert devrait le payer. Là où les données de Sku ne donnent aucun lieu, l'entrée indique « Lieu inconnu » au lieu d'une distance et passe en fin de liste - elle ne disparaît pas.

Technique : Idée et implémentation de référence de ZenqFR, tirées de l'addon compagnon SkuQuestNearby (github.com/ZenqFR/Sku-QuestNearby) ; reconstruite ici nativement avec l'accord de ZenqFR afin qu'aucun addon supplémentaire ne soit nécessaire - en particulier sans Questie et sans GatherMate2. Le calcul vit dans le nouveau fichier sans état SkuQuest/Proximity.lua. Deux étages, et l'ordre est l'essentiel : d'abord le point de spawn enregistré le plus proche DANS la zone où l'on se trouve - la sélection tourne à bas coût en coordonnées de carte, seul le gagnant est converti une fois en coordonnées du monde ; ensuite seulement, si cela ne donne rien, le minimum sur toutes les zones du même continent. Un autre continent n'est pas une distance imprécise, c'est une absence de distance, et il reste dehors. Les objectifs d'objet sont ramenés aux créatures et objets du monde qui les font tomber, les objectifs d'exploration à leurs coordonnées enregistrées. Contrairement au chemin des points de passage, TOUTES les listes d'objectifs d'une quête sont lues, pas seulement la première non vide - une quête « tuez huit loups ET récoltez cinq peaux » n'afficherait sinon que les loups. Le filtrage porte uniquement sur le TYPE d'objectif : quels types sont encore ouverts vient de l'affichage de progression de Blizzard lui-même (« monster », « item », « object »), et il correspond exactement aux trois listes ; comparer une ligne de progression à une entrée de base de données précise relèverait de la devinette, car aucun des deux ordres n'est lié à l'autre. Douze identifiants au maximum sont évalués par quête et par type - la limite ici est le budget de script des royaumes hardcore, pas la dernière décimale. Le point cardinal provient des mêmes coordonnées du monde, via la même fonction qu'utilisent les listes de points de passage et le scanner de minicarte. Volontairement un point cardinal et non une position horaire : une position horaire est relative à l'orientation du regard et serait fausse dès qu'on se tourne - or la liste est construite une fois puis parcourue.

Base de données des quêtes : « Commence dans la zone » sans niveau intermédiaire

Simple : Sous « Base de données des quêtes, Commence dans la zone » se trouvait exactement une entrée, « Par distance », et seulement à l'intérieur les quêtes. Un niveau où il n'y a rien à choisir n'est qu'une pression de touche. La liste se trouve désormais directement sous « Commence dans la zone ». Cette liste était par ailleurs cassée : elle s'interrompait après la première quête, on obtenait donc exactement une entrée au lieu de toutes les quêtes de la zone.

Technique : Le niveau intermédiaire venait de ce qu'un second tri (« par difficulté ») devait un jour s'installer à côté ; ce chantier est resté commenté à côté pendant des années et n'a jamais été construit. L'interruption venait d'une ligne « tcount = tcount + 1 » dans la construction de la liste : tcount n'y était pas une variable locale mais une globale jamais définie, l'incrémentation levait donc une erreur sur nil. Une erreur dans la construction des enfants d'un menu est avalée - la construction se terminait donc silencieusement après la première entrée. Le compteur n'était lu par rien ; il est supprimé plutôt qu'initialisé.

Tout le contenu de la banque en une seule liste, et la banque reconnue aussi sous Bagnon

Simple : Le menu des sacs avait « tous les sacs » - une liste à plat sur l'ensemble des sacs, triée par nom. La banque n'avait pas d'équivalent : devant une banque ouverte le menu affichait bien « Banque » et « Banque Sac 1 » à « Banque Sac 7 », mais chercher quelque chose obligeait à entrer dans chaque compartiment l'un après l'autre. Désormais, tant que la banque est ouverte, une nouvelle entrée « toute la banque » se place juste après « tous les sacs » : tout ce qui se trouve dans la banque en une seule liste, avec le même filtre à la frappe. Ctrl+Entrée y déplace un objet vers vos sacs - exactement comme il le faisait déjà dans chaque sac de banque. De plus, Sku détermine maintenant si la banque est ouverte à partir des messages du jeu lui-même, et non plus de la fenêtre de Blizzard. Qui utilise un addon de remplacement des sacs comme Bagnon, lequel masque cette fenêtre, n'avait jusqu'ici aucune banque dans le menu - Sku la croyait fermée et faisait disparaître tous les compartiments de banque. Aucun addon-pont n'est plus nécessaire pour cela.

Technique : La suggestion vient de l'addon compagnon SkuBagnonBridge de ZenqFR (github.com/ZenqFR/Sku-BagnonBridge), qui comble la même lacune à sa manière et reconnaît lui aussi la banque via les événements du jeu ; avec l'accord de ZenqFR, la part qui se passe de tout addon supplémentaire est construite ici nativement. La liste à plat se limitait aux sacs 0 à 4 ; les conteneurs de banque (-1, -3, 5 à 11) n'y étaient jamais copiés. Ils sont désormais rassemblés dans une liste propre, délibérément séparée de celle des sacs : SkuCore.combatBagOrder en dérive - le miroir utilisé en combat - et celui-ci ne peut utiliser que des emplacements de sac. Les entrées de la nouvelle liste sont des copies des mêmes entrées par emplacement et emportent le sac et l'emplacement, si bien que toutes les actions existantes fonctionnent sans changement. L'état de la banque tient maintenant à BANKFRAME_OPENED et BANKFRAME_CLOSED : tous deux proviennent de l'interaction avec le banquier elle-même et sont indépendants de qui dessine la fenêtre. Il est réinitialisé au chargement et après /reload, et l'ancienne vérification de la fenêtre est conservée à côté - la détection ne peut donc que reconnaître plus de cas qu'avant, jamais moins.

La suppression d'un point de passage personnel effaçait la mauvaise entrée

Simple : supprimer un point de passage que vous aviez créé vous-même ne retirait pas son propre identifiant d'une table de recherche interne, mais celui d'un autre point de passage. Et « /skucheck wp » signalait quatre erreurs sur les quatre points de passage rapides alors que tout allait bien pour eux.

Technique : le wpId d'un point de passage est son identité - la table des liaisons est indexée dessus -, pas une description de l'endroit où il se trouve. L'identifiant de zone qui y est encodé date du moment de la construction du cache et ne bouge plus quand un point de passage personnel se déplace ; c'est exactement ce qui arrive aux quatre points de passage rapides à chaque écran de chargement, puisqu'ils sont alors replacés sur la position du joueur. La vérification reconstruisait l'identifiant à partir de l'areaId actuel de l'enregistrement et comparait - elle utilise désormais la zone encodée dans l'identifiant lui-même. Le chemin de suppression construisait l'identifiant à partir de « .areaid » (le champ s'appelle areaId), donc avec la zone 1 au lieu de la vraie, et effaçait ainsi l'entrée de l'enregistrement à qui cette clé appartient réellement ; il utilise maintenant l'identifiant stocké.

La saisie du chat est devenue utilisable

Simple : La ligne de chat était le seul champ de saisie de Sku dans lequel on tapait à l'aveugle. Il y avait un son à l'ouverture et un à la fermeture, rien d'autre - pas d'écho des caractères, pas de lecture sous le curseur, et aucune indication sur la destination réelle du message. Elle se comporte désormais comme tout autre champ de saisie de Sku. Chaque caractère tapé ou effacé est prononcé, les flèches gauche et droite lisent le caractère sous le curseur et, avec Ctrl, le mot entier, la flèche haut rappelle les derniers messages envoyés - pour les renvoyer ou les modifier - et annonce le canal avec eux, car une ligne rappelée ne montre pas où elle irait. Le canal est aussi annoncé à l'ouverture et à chaque changement, mais volontairement pas pour « Dire » : c'est le cas inoffensif, et l'annoncer chaque fois ne serait que du bruit. Si l'annonce ne convient pas à votre façon de faire, elle se désactive dans les réglages du chat ; elle est activée par défaut. La désactiver retire aussi le canal devant une ligne rappelée avec la flèche haut.

Un objet dans le chat compte pour un seul caractère à la lecture au lieu de soixante-cinq caractères de balisage. Et une commande mal tapée comme « /tets » dit maintenant « commande inconnue » au lieu de ne rien faire.

Technique : L'écho clavier des champs propres à Sku s'attache maintenant aussi aux champs étrangers via SkuOptions:AttachInputEcho. Trois choses y diffèrent : l'attache se fait avec HookScript et non SetScript, car le champ de Blizzard porte ses propres gestionnaires d'historique et de complétion de noms ; le modèle pose ignoreArrows, d'où des flèches simples envoyées au jeu et un curseur de texte exigeant ALT - ce qui est inversé ; et l'armement se fait sur le focus, car un champ étranger n'a pas de paire ouverture-fermeture à laquelle accrocher l'écho. Le canal est lu dans l'en-tête de la saisie plutôt que reconstruit depuis chatType - l'en-tête est déjà traduit et couvre les cibles de chuchotement, les canaux numérotés et les bascules propres à Blizzard en plein appel. Son annonce est différée et tient dans un seul emplacement, car tout changement de canal est déclenché par une frappe, et l'écho de cette frappe éjectait sinon l'annonce de la file avant même qu'elle ne soit prononcée.

Les liens d'objet sont lus par leur nom, pas en codes de couleur

Simple : Un objet - dans le chat, dans le courrier, dans le butin - était lu comme une longue suite de codes de couleur, d'identifiants et de deux-points au lieu de son nom.

Technique : La sortie vocale remplaçait d'abord chaque barre verticale par une espace, PUIS appelait la fonction qui retire les codes de couleur, les liens et les textures. Tous ses motifs cherchent une barre verticale, qui n'existait plus à ce moment - ils ne correspondaient donc à rien depuis toujours. Ordre inversé ; le remplacement général n'est plus qu'un filet de sécurité derrière.

Base de données des quêtes : « Commence dans la zone » indique aussi le point cardinal

Simple : La liste des quêtes qui commencent dans cette zone ne donnait jusqu'ici que la distance du donneur de quête. Elle indique maintenant aussi, comme la liste « Quêtes à proximité », dans quelle direction elle se trouve - d'abord la distance, puis le point cardinal.

Technique : Les coordonnées mondiales du donneur de quête figuraient déjà dans cette liste ; la direction vient de la même fonction que celle qu'utilisent les listes de points de passage. Volontairement le point cardinal et non l'heure : un relèvement horaire dépend de l'orientation du regard et serait faux dès qu'on tourne, alors que cette liste est construite une fois puis parcourue. L'identifiant de quête d'une entrée provient désormais directement de la ligne, au lieu d'une table de correspondance indexée sur l'ancien libellé sans direction.

Écho clavier : les caractères sont annoncés immédiatement

Simple : En tapant dans un champ de saisie, les lettres ne suivaient pas les doigts : certaines étaient avalées, d'autres arrivaient nettement en retard, et les lettres doubles comme dans « aller » ou « pomme » n'étaient souvent entendues qu'une fois. Chaque caractère tapé arrive maintenant immédiatement, et une touche pressée deux fois est prononcée deux fois.

Technique : L'écho passait jusqu'ici par la même file d'attente que chaque annonce de menu, et cette file est conçue pour des annonces, pas pour des frappes. Elle regroupait les caractères pendant un dixième de seconde et les prononçait en mode écrasement - et écraser signifie ici : d'abord StopSpeakingText, puis attendre encore un dixième de seconde pour que cet arrêt ne supprime pas justement la ligne à laquelle il devait faire place. Les deux à la suite font environ 0,2 seconde par frappe, et l'arrêt d'une frappe atterrissait régulièrement sur la suivante. S'y ajoutait le nouveau garde-fou anti-doublon de cette version, pour lequel un caractère isolé est un énoncé identique à lui-même - d'où les lettres doubles avalées. Les caractères tapés empruntent désormais leur propre voie rapide : une seule place où la frappe la plus récente l'emporte, transmission dans la même image, l'arrêt émis une seule fois au début d'une série de frappes au lieu d'une fois par touche, et le garde-fou anti-doublon ne voit plus du tout les caractères tapés. Contexte : un lecteur d'écran n'a jamais besoin de tout cela, car son interface propose l'interruption comme partie intégrante de la commande de parole - une seule opération. L'interface du jeu ne le permet pas, Sku doit donc la reconstituer à partir de deux appels qui peuvent se doubler. La nouveauté est de ne le faire qu'une fois par série de frappes.

Une ligne redemandée par une touche est de nouveau prononcée

Simple : Redemander une ligne de menu par une touche produisait parfois du silence - la synthèse vocale considérait la répétition comme superflue.

Technique : Le garde-fou anti-doublon écarte une ligne déjà prononcée à l'identique dans la seconde précédente. C'est juste pour la reprise superflue d'une reconstruction de menu, et faux pour le même texte que l'utilisateur vient de demander par une touche. Les deux sont indiscernables par leur texte, et aucun délai ne les sépare - seul leur déclencheur diffère. La gestion des touches du menu marque donc maintenant son annonce comme déclenchée par une touche, et le garde-fou laisse toujours passer les lignes marquées. Les répétitions superflues restent écartées, désormais quelle que soit leur rapidité.

Les quêtes à objectifs mixtes montrent tous les types d'objectifs

Simple : Pour une quête comme « tuez 8 loups ET ramassez 5 peaux », l'entrée « Cible de quête » du menu de quête ne montrait que le premier type d'objectif - le plus souvent les ennemis ; les sources de l'objet à ramasser, ou un point d'exploration, manquaient en silence. 95 quêtes étaient concernées. Tous les types d'objectifs figurent désormais côte à côte dans une seule liste, et le raccourci « Cibler la créature de quête la plus proche » connaît lui aussi les deux moitiés de ces quêtes. Corrigé au passage : une quête qui n'a qu'un point d'exploration et aucune autre donnée d'objectif reçoit enfin une entrée « Cible de quête », et un point d'exploration irrésoluble ne produit plus une entrée qui se contente d'annoncer « vide ».

Technique : SkuQuest:GetQuestTargetIds était une chaîne de elseif sur les listes d'objectifs de la base de données (créatures, sinon objets, sinon objets à ramasser, ...) et ne pouvait, par sa signature même, renvoyer qu'UNE liste avec UN type. Remplacée par GetQuestTargetGroups : un tableau de groupes {targets, type} - créatures fusionnées avec les crédits de mise à mort dédupliqués, objets, objets à ramasser et, pour les seuls appelants objectives, le point triggerEnd de la quête. Les sept sites d'appel sont convertis (menu de quête, cache des points de passage, marqueurs de quête, touche de cible de quête) ; l'ancien nom demeure comme enveloppe premier-groupe pour le port WowVision. La branche item de GetResultingWps est en outre protégée contre les identifiants d'objets inconnus - elle indexait sans vérification et laissait la construction du menu mourir en un silencieux « liste vide ».

Base de données des quêtes mise au niveau actuel de Questie

Simple : La base de données de quêtes intégrée à Sku provient de Questie et datait d'environ deux ans. Après la synchronisation, 33 quêtes dont la « Cible de quête » restait vide ont de vraies cibles (les jeux de cartes de Sombrelune, les quêtes répétables d'Ogri'la et de l'Œil pourpre, « Trouver le maître des clés »), les six quêtes « Enquêter sur le Fléau » ont désormais des points d'exploration, cinq quêtes manquantes ont été ajoutées, et environ 2000 enregistrements portent de petites corrections de noms, niveaux, donneurs de quête et chaînes de prérequis. Vérifié : les corrections sont identiques pour Era et TBC, la mise à jour est sûre sur les deux.

Technique : Une fusion sémantique, pas une copie d'octets (nouvel outil dev/rework-docs/_refresh_questdata_from_questie.py, puis _db_convert.py) : le schéma de Questie diverge à partir du champ 27, seuls les champs 1-26 sont repris ; les champs propres à Sku, extraObjectives et skuData, sont préservés par enregistrement. La convention requiredRaces (ancien masque toutes-races 2047, désormais 0 - identique pour la logique de Sku) compte comme égale dans la comparaison, sans quoi 2117 enregistrements sans changement de contenu auraient encombré le diff. Chaque identifiant de créature, d'objet et d'objet à ramasser référencé a été validé contre les bases livrées (base + WotLK) ; un enregistrement est resté à son ancien état pour cette raison.

Les quêtes d'événement n'apparaissent plus juste après le chargement

Simple : Dans les premières secondes après un /reload, des quêtes d'événements mondiaux inactifs pouvaient apparaître dans « Commence dans la zone » - des quêtes du Solstice d'été en août, par exemple. Une fois Questie complètement chargé, elles disparaissaient d'elles-mêmes ; elles sont désormais masquées aussi dans cette fenêtre.

Technique : Les deux barrières de disponibilité n'interrogeaient Questie qu'à partir de Questie.started, et ce drapeau ne bascule qu'à la toute FIN de l'initialisation de Questie. La liste noire statique de Questie,

QuestieCorrections.hiddenQuests - quêtes retirées du jeu plus TOUTES les quêtes d'événement ; les actives ne sont dévoilées qu'après la réponse du calendrier du serveur - existe pourtant bien plus tôt. IsQuestieUnavailable la lit désormais directement avant started : une simple lecture de table ; le risque d'empoisonnement de mémoïsation derrière la barrière started ne concerne que IsDoable. La valeur « HIDE_ON_MAP » est ignorée comme le fait Questie lui-même, et chaque masquage d'avant-démarrage écrit une ligne dprint dans le journal.

Les quêtes de donjon mènent à l'entrée au lieu de nulle part

Simple : Pour environ 300 quêtes, le donneur, la cible ou la remise se trouve dans un donjon - « La vengeance de Vorrel » commence au Monastère écarlate, « Willix l'importateur » se termine au Kraal de Tranchebauge. Début de quête, Cible de quête et Livraison y restaient vides, car les instances n'ont pas de carte du monde. Ces entrées affichent désormais « PNJ, entrée, nom du donjon, zone » avec une route vers l'entrée du donjon - quêtes de champ de bataille comprises (la vallée d'Alterac choisit la bonne entrée selon la faction). Les sources d'un OBJET dans le même donjon sont regroupées en une seule entrée « nom du donjon, entrée, zone » - « Le destin de Ramaladni » énumérait sinon un à un 29 monstres de Naxxramas menant tous à la même porte ; les objectifs d'élimination gardent leurs noms de monstres individuels.

Technique : Nouvelle table générée SkuDB.InstanceEntrances (depuis la table des donjons de Questie, outil dev/rework-docs/_gen_instance_entrances.py) : areaId d'instance -> entrées {zone parente, x, y, faction éventuelle}, y compris les identifiants des ailes et une barrière GetBuildInfo pour les déplacements d'entrées de WotLK. Les résolveurs de spawns (CreatureIdHelper, branches objet et objet-ramassé de GetResultingWps) ne sautent plus les zones sans carte ; ils répondent comme le détour triggerEnd de la v43.2 : convertir les coordonnées de l'entrée en coordonnées du monde, prendre le point de passage de route le plus proche. Mémoïsé par génération du cache de points de passage ; le filtre de faction lit UnitFactionGroup.

77 quêtes à objectif de terrain ont désormais une vraie cible

Simple : 77 quêtes dont l'objectif est un lieu ou un objet sur le terrain (les puits de Mulgore, la pierre de sélénien des druides, les pylônes de cristal du cratère d'Un'Goro, la dépouille de Rolf, les quatre totems draeneï, la série Dressage de bêtes des chasseurs et bien d'autres) n'avaient aucune donnée de cible - l'entrée « Cible de quête » manquait tout simplement. Toutes ont désormais une vraie cible routable. Important : les objets et créatures viennent des données d'apparition propres de Sku, mais 26 lieux proviennent de sources web (warcraft.wiki.gg, Wowhead) et n'ont pas tous pu être vérifiés en jeu. Ils ont été choisis avec soin mais peuvent être inexacts dans certains cas - un retour indiquant si une telle cible est juste ou non aide beaucoup. Même un point imprécis vaut mieux que rien : la route mène dans la bonne région.

Technique : Résultat de la liste de relecture

Treize quêtes de dialogue ont retrouvé leur point de remise

Simple : Treize quêtes - surtout les anciennes quêtes de sorts de prêtre (Étoiles d'Élune, Grâce d'Élune, Sans peur, Maléfice de faiblesse), plus entre autres « Le tome de noblesse » et « Allié des Aile-du-Néant » - n'avaient aucun point de remise dans les données : ni cible ni livraison, rien n'était routable. L'entrée Livraison mène désormais au PNJ que le texte de la quête nomme lui-même.

Technique : Entrées finishedBy dans quests_fixes.lua ; les identifiants de créature ont été résolus depuis le texte de quête contre la base de données des créatures (chaque nom y est unique, et les points d'apparition se trouvent dans la zone que le texte nomme). Les candidats proviennent du nouvel outil dev/rework-docs/_quest_target_candidates.py, qui classe toutes les quêtes sans cible et écrit la liste de relecture QUEST-TARGET-CANDIDATES.txt pour les restantes (vrais objectifs de terrain sans source de coordonnées).

Expérimental : itinéraires de récolte

Simplement : Vous choisissez une ressource - un minerai, une herbe, un nuage de gaz ou une sorte de coffre - et Sku vous guide à travers la zone, gisement après gisement, toujours le plus proche d'abord. Là où les données de chemin couvrent le gisement, il emprunte un véritable itinéraire ; sinon vous obtenez une balise directe et Sku vous le dit - une balise peut pointer à travers un mur, un itinéraire non. En vol, il n'y a jamais d'itinéraire : là-haut la ligne droite est la bonne réponse, pas le pis-aller.

Au gisement, Sku attend brièvement pendant que vous récoltez, puis poursuit. Le raccourci « point de passage suivant de l'itinéraire » (Ctrl+Maj+W par défaut) ignore le gisement courant pendant un itinéraire de récolte ; aucune nouvelle touche n'est donc nécessaire.

Si le pistage correspondant est actif (Détection des minerais, Détection des herbes), l'analyseur de minicarte vérifie à l'approche si le gisement est encore là, et ignore ceux déjà récoltés avec une annonce propre. Sans pistage l'itinéraire fonctionne quand même, simplement sans cette vérification.

À trouver sous Réglages -> Scan -> analyse des ressources -> Itinéraires de récolte, avec le rayon de vérification, le nombre de gisements par itinéraire et l'interrupteur de la vérification. Pour les minerais, les herbes et les coffres, « Afficher les points de passage d'herbes et de filons » doit être activé dans les réglages de navigation - sinon ces gisements n'existent pas du tout en tant que points de passage, et Sku le dit précisément au démarrage au lieu de déclarer la zone vide à tort. Les nuages de gaz n'ont pas besoin de ce réglage.

Important : Cette fonction est expressément expérimentale. Elle n'a été essayée en jeu que dans les grandes lignes, et la vérification « le gisement est-il encore là » n'a pas pu être exercée dans des conditions réelles, car aucun personnage ici n'a de métier de récolte - sans Détection des minerais ni Détection des herbes, il n'y a aucun point sur la minicarte que l'analyseur puisse lire. Si vous jouez Minage ou Herboristerie : essayez et signalez ce qui ne va pas.

Technique : L'idée et l'implémentation de référence viennent de ZenqFR, de l'addon compagnon SkuGatherRoute (github.com/ZenqFR/Sku-GatherRoute) ; la mécanique d'itinéraire y a été conçue et démontrée - une famille de points de passage sous un nom de base commun, chaque gisement atteint par un itinéraire proche, une annonce distincte pour chaque transition, et le raccourci existant comme touche pour ignorer. Ici la fonction est reconstruite nativement avec l'accord de ZenqFR, afin qu'aucun addon supplémentaire ne soit nécessaire.

Une différence est délibérée : l'original nécessite GatherMate2, cette version non. Nous n'y voyons aucun avantage - les gisements se trouvent depuis longtemps dans le cache de points de passage de SkuNav, coordonnées mondiales comprises, et nommés de telle sorte que la ressource EST le nom de base du point de passage ; une deuxième source de données et un deuxième addon n'y ajouteraient rien tout en coûtant une installation de plus à chaque utilisateur. Si GatherMate2 fait quelque chose qui nous a échappé - l'enregistrement automatique des gisements réellement récoltés serait le candidat -, dites-nous alors à quoi cela sert, et nous y regarderons.

La vérification de présence s'accroche à MinimapScanner:MinimapScanFastStop, le point unique par lequel passe chaque analyse. Si « notifier les ressources »

est activé, l'analyse déjà en cours suffit ; sinon l'itinéraire analyse lui-même, de manière limitée et uniquement à portée de la cible, et ces analyses restent silencieuses. Une correspondance confirme, un échec ne prouve rien - une analyse ne rapporte jamais qu'un seul nom et peut avoir attrapé un autre point. Ce n'est qu'après plusieurs analyses infructueuses à portée qu'un gisement est considéré comme disparu. Dans le doute, rien n'est jamais ignoré :

un gisement conservé à tort coûte quelques pas, un gisement ignoré à tort ne se remarque pas du tout.

Le menu reste utilisable pendant la marche

Simple : Si vous ouvriez le menu en marchant, il s'affichait et annonçait « menu ouvert », mais plus aucune touche ne faisait quoi que ce soit - ni flèche, ni lettre, ni Entrée. Seule Échap passait. Il ne redevenait utilisable qu'une fois à l'arrêt. C'est corrigé : un menu ouvert accepte désormais les touches que vous marchiez, couriez ou soyez en course automatique.

Technique : Il y avait deux verrous de mouvement, pas un. Le premier empêche l'OUVERTURE tant qu'une touche de déplacement est maintenue - il reste, et il est nécessaire : les raccourcis du menu avaleraient le relâchement de la touche et vous courriez sans fin. La course automatique en est exemptée depuis la v42.00 (son propre indicateur AutoRun, que IsPlayerMoving ne lit délibérément pas). Le second se trouvait dans le gestionnaire de touches du menu lui-même et, tant qu'un verrou de mouvement était posé, laissait expirer chaque appui sauf Échap. Ce second verrou n'apporte rien : une fois le menu ouvert, les raccourcis lui appartiennent déjà, écarter l'appui n'arrête aucun mouvement - il ne fait que rendre le menu sourd, et marque de surcroît « ouvrir plus tard » sur un menu déjà ouvert, que la boucle de réouverture doit ensuite défaire. Il ne s'applique plus que si le menu n'est PAS ouvert. Les quatre verrous d'ouverture restants écrivent en outre une ligne dans le journal de débogage nommant la touche de déplacement qui les retient - auparavant ils étaient muets, et un rapport « le menu ne s'ouvrait pas en marchant » ne laissait aucune trace.

Navigation : « Carte actuelle par distance » vient désormais en premier

Simple : Sous « Point de passage direct », « Récent » était en première position et « Carte actuelle par distance » en deuxième. Les deux sont permutés - la liste des points de passage de la zone actuelle est l'entrée la plus fréquente, et elle se trouve maintenant directement sous le curseur.

Technique : Uniquement l'ordre des injections dans SkuNav:MenuBuilder. « Récent » reste conditionné à une liste non vide de points de passage récents ; si elle est vide, « Carte actuelle par distance » est de toute façon en tête, comme avant.

Le filtre de saisie ignore les accents

Simple : Dans chaque liste que l'on peut restreindre en tapant, les lettres accentuées étaient traitées comme des caractères d'une autre langue. « general » ne trouvait rien alors que « Fournitures générales » était là, et « ingenieur » ne trouvait pas « Ingénieur » - alors que « ing » y parvenait. C'est maintenant la lettre qui compte, pas l'accent. De plus, la touche ù d'un clavier AZERTY alimente désormais aussi le filtre : c'est la seule lettre accentuée que ce clavier livre comme véritable événement de touche.

Technique : string.lower en Lua travaille octet par octet et ne transpose que A-Z ; il ne replie donc jamais un caractère accentué, d'aucun côté de la comparaison. SkuMenuFilterMatch (utilisé par ApplyFilter et JumpToFilterMatch) et SettingsSearchMatch replient désormais le nom de l'entrée et le texte tapé en ASCII sans accents avant de comparer ; seules les séquences de 2 octets du supplément Latin-1 et du latin étendu A sont touchées, l'ASCII pur emprunte une voie rapide. Strictement plus permissif qu'avant : ce qui correspondait correspond toujours. Les deux appels string.find passent en outre plain=true - le texte tapé était lu comme un motif Lua, si bien qu'une saisie comme « 50% » ou « (long » ne trouvait rien ou levait une erreur.

Le repli des accents vient de la PR #9 (ZenqFR), la touche ù de la PR #13 (Naxedim).

Barres d'action : l'infobulle du sort est de nouveau lue

Simple : Dans le menu des barres d'action (Maj+F11), Maj+Bas sur un sort de la liste d'affectation ne lisait plus rien du tout. L'infobulle est de retour - de même que pour le contenu actuel d'une touche et pour les deux lectures de capacités du familier voisines, qui présentaient la même faiblesse.

Technique : Deux causes indépendantes, toutes deux traitées car aucune ne pouvait être écartée à la seule lecture du code. D'abord, SkuScanningTooltip est créé une fois à la connexion, sans modèle, et partagé par tous les modules ; celui qui l'a utilisé en dernier peut le laisser sans propriétaire exploitable, après quoi chaque appel Set* ne remplit plus rien - en silence, sans erreur. Il est désormais réapproprié juste avant d'être rempli. Ensuite, SetSpellByID recevait la troisième valeur de retour de GetSpellBookItemName, qui suit sur ce client la signature Classic et ne renvoie que (name, rank) - l'identifiant est un ajout retail et valait nil. L'identifiant provient maintenant de

GetSpellBookItemInfo, et l'infobulle est remplie par SetSpellBookItem, qui n'a besoin d'aucun identifiant. La lecture est en outre encapsulée dans un pcall, puisqu'elle se déclenche à chaque déplacement du curseur. Issu de la PR #10 (ZenqFR).

Objectif de quête : le lieu figurait dans les données, mais restait introuvable

Simple : 174 quêtes qui demandent d'explorer un endroit ou d'y utiliser quelque chose ne répondaient que « Vide » sous « Objectif de quête ». L'entrée mène désormais au point de passage de route le plus proche de ce lieu.

Technique : GetTriggerEndWps composait un NOM de point de passage

(« <quête>;<zone>;<objectif>;<x>;<y> ») et le résolvait via la recherche par nom exact dans le cache des points de passage. Or rien ne génère de point de passage sous ce nom - contrairement aux apparitions de créatures et d'objets - il ne trouvait donc quelque chose que si quelqu'un en avait écrit un à la main dans les données de route : il en existe exactement un (quête 10211, Shattrath). Le nom composé reste utilisé lorsqu'il se résout ; sinon la géométrie prend le relais - coordonnées de carte vers coordonnées monde, puis le point de passage de ROUTE réel le plus proche. GetNearestWpToCoords2 a reçu pour cela un filtre typeId optionnel, afin que le repli n'atterrisse pas parmi les quelque 145 000 points d'apparition générés, plus une protection contre un seau de continent manquant, où pairs(nil) levait une erreur. Toutes les paires de coordonnées de chaque zone sont désormais lues au lieu de la première seule, et le résultat est mémorisé par génération du cache.

Français : les commentaires de points de passage reparlent - et en français

Simple : Les commentaires attachés aux points de passage - dont ceux qui touchent à la sécurité, comme « attention, à partir d'ici la route longe le bord d'un ravin », « attendre le zeppelin ici » ou « ce PNJ se déplace » - étaient totalement muets sur un client français depuis la v42.11. Ils reparlent, et ils parlent désormais français : 207 textes répartis sur 546 points de passage.

Technique : Les données de route ne portent lComments que pour enUS et deDE (environ 296 points de passage). SkuNav:PlayWpComments lisait

comments[Sku.Loc] sans repli. Jusqu'à la v42.11, Sku.Loc valait « enUS » sur un client français faute de locale frFR, et l'on entendait les textes anglais ;

depuis que locales/frFR.lua est livré, Sku.Loc vaut « frFR », la recherche renvoie nil et la fonction sort sans un mot. Nouveauté : Sku.locList (SkuUtil.lua), le pendant liste de Sku.locStr, renvoie la première liste NON VIDE parmi Sku.Loc / enUS / deDE. « Non vide » est déterminant, car SkuMM.lua matérialise un comments[Sku.Loc] vide sur chaque point de passage qu'il dessine

l'original ALLEMAND, non via l'anglais : l'anglais avait perdu du détail sur précisément ces textes de sécurité, et plusieurs entrées anglaises sont vides, dont l'avertissement sur les ascenseurs mortels qui figure sur huit points de passage.

Français : noms de ressources et la Caverne des Brumes

Simple : Deux défauts qui ne touchaient qu'un client français. D'abord, 22 des 94 noms de ressources du scanner de minicarte étaient erronés - le scanner les compare à l'infobulle du jeu, un nom faux signifie donc que ce gisement n'est jamais annoncé, sans message d'erreur. Ensuite, dans la Caverne des Brumes la liste des points de passage restait vide, alors qu'une route lancée à l'extérieur continuait de fonctionner.

Technique : Chacun des 22 noms a été tranché à l'aide d'une source indépendante des deux addons : 19 par les tables frFR de SkuDB (importées des chaînes Blizzard de Questie), trois par l'API d'infobulle de Wowhead. Pour la caverne, Geo.lua compare GetMinimapZoneText() mot pour mot à L["Caverne des Brumes"] ; la locale frFR générée portait « Grotte des Brumes », une traduction libre - le client dit « Caverne des Brumes ». La comparaison était donc morte, uiMap restait sur le continent, GetAreaIdFromUiMapId répondait -1 et GetCurrentAreaId nil, si bien que ListWaypoints2 abandonnait. La valeur a été relevée avec /szp dans la zone, non traduite, et figure désormais tant dans le fichier généré que dans le magasin TSV à partir duquel il est assemblé - avec la note interdisant de la traduire librement. Issu des PR #14 et #16 (Naxedim).

Tourner vers la balise : plus précis, et avec anticipation

Simple : La rotation automatique vers la balise (T) tombe désormais bien plus juste. Auparavant elle allait si vite que le seul arrêt à la frontière d'une image pouvait coûter vingt degrés de dépassement ou plus, selon la fréquence d'images. La vitesse suit maintenant l'ampleur de la rotation, et aucune rotation ne dure plus d'un quart de seconde. En mouvement, elle anticipe également : elle vise là où se trouvera le point de passage à la fin de la rotation - ce qui met fin aux tours en rond autour des points de passage proches, surtout monté et en vol. Et un appui pendant une rotation en cours est écarté au lieu d'interrompre celle-ci en plein milieu ; les appuis répétés habituels affinent toujours comme avant.

Technique : Quatre éléments, testés ensemble. Le calage sur la caméra par défaut avant la rotation reste - il porte le lacet, sans lui l'angle est faux. La vitesse de rotation est plafonnée d'après l'angle restant au lieu de tourner à plein régime. L'anticipation calcule, à partir de la vitesse actuelle et de la durée prévue de la rotation, où sera le point de passage à la fin. S'y ajoute une protection contre le défaut par lequel, après des rotations déclenchées coup sur coup, la vitesse de rotation des touches de caméra pouvait rester quadruplée définitivement.

Le programme d'installation retient où se trouve votre WoW

Simple : Le programme d'installation cherche le jeu aux endroits habituels - Program Files, plus une poignée de dossiers probables sur C, D et E. Qui a son WoW ailleurs devait chercher le dossier à la main, et pas une fois mais à CHAQUE mise à jour : le programme oubliait la réponse au moment même où il se fermait. Il note maintenant le dossier dès qu'une installation a abouti, et recommence là la fois suivante. Lui montrer un client permet aussi de trouver l'autre à côté : une Classic Era voisine d'une Anniversary sur le même disque inhabituel est prise en compte toute seule. Si le jeu déménage plus tard ou est désinstallé, la note est abandonnée et la recherche se déroule comme avant. Le programme d'installation passe ainsi en version 4.5.

Technique : Nouveau fichier PathMemory.cs. Le manifeste d'installation ne pouvait pas servir à cela - SkuInstall.json se trouve DANS le dossier AddOns, le lire suppose donc d'avoir déjà trouvé le dossier que l'on veut retenir. Le dossier de chaque client est donc écrit sous forme d'une simple ligne « produit=chemin » dans SkuPaths.txt, à deux endroits : %LOCALAPPDATA%\SkuUpdater, à côté de la copie permanente de l'updater que lance le raccourci « Sku Updater », et %ProgramData%\SkuUpdater comme miroir valable pour toute la machine. Ce miroir n'est pas une redondance gratuite : le programme demande l'élévation, un utilisateur standard qui répond à l'invite UAC avec les identifiants administrateur de quelqu'un d'autre exécute donc tout sous cet autre profil et écrirait sinon la note dans un LOCALAPPDATA qu'il ne reverra jamais. Au démarrage suivant, un dossier retenu l'emporte sur la détection - c'est une décision, alors que la détection n'est qu'une supposition sur une courte liste de disques - et son répertoire de base est placé en tête de la liste sondée, ce qui est précisément ce qui fait que retenir un client profite à l'autre. Garde-fous contre une note périmée : le dossier doit exister encore, et son .flavor.info ne doit pas annoncer entre-temps un autre client ; sinon la note est ignorée plutôt que d'envoyer une installation dans le vide. L'écriture n'a lieu qu'après l'installation propre d'un client : une exécution annulée ou échouée ne laisse donc rien. Du texte brut à dessein - le fichier se laisse lire à voix haute et corriger dans le Bloc-notes, et supprimer une ligne rend la détection automatique à ce client. Nouveau contrôle sans interface, « SkuSelfTest pathmemory » : il affiche ce qui est noté sur cette machine et déroule l'écriture, la lecture et les cas de note périmée sur un stockage jetable, sans jamais toucher au vrai.

La fenêtre de lecture devient configurable

Simple : Les textes de quête, les infobulles, l'historique de discussion et les pages du wiki aboutissent tous dans la même fenêtre de lecture. Son apparence était figée dans le code : Playfair Display en 12 points, une police à empattements fine, dans la plus petite taille utilisée par l'addon. Pour une personne ayant une vision résiduelle, c'était à la fois la surface la plus importante de l'addon et la moins lisible. Réglages -> Aides visuelles -> Fenêtre de texte propose désormais des tailles de 14 à 44 points, quatre polices, quatre combinaisons de couleurs (blanc sur noir, jaune sur noir, noir sur blanc, blanc sur bleu), l'opacité du fond et un contour. Par défaut la fenêtre s'affiche maintenant sans empattement en 18 points : même sans rien changer, elle est nettement plus lisible qu'avant.

Technique : La surface appartient à Libs/SkuTTS-1.0 (cadre SkuTTSMainFrame et son FontString .FS), où l'apparence tenait en un seul appel SetFont codé en dur. Les réglages vivent désormais dans SkuCore VisualAids sous visualAids.textWindow, et SkuTTS:Output appelle VisualAids:TextWindowLayout avant chaque affichage - protégé par pcall et dans le même sens que SkuZOptions alimente déjà la barre de lecture. La bibliothèque n'a ainsi rien à savoir des options, et un module Aides visuelles désactivé laisse simplement la fenêtre telle quelle. Chaque attribution de police est vérifiée et retombe sur la police standard du client au lieu de laisser une surface vide - les deux familles fournies, Raleway et Playfair, se trouvent sous Libs/SkuTTS-1.0/fonts et ne sont livrées que par l'archive de version. Les paliers de taille sont volontairement plus petits que ceux de la barre : un texte de quête entier tient ici, et la fenêtre n'a pas d'ascenseur, donc elle coupe d'autant plus tôt que la police est grande. Tout reste lu intégralement ; l'affichage est la seconde piste.

La barre de lecture affiche ce que Sku dit - et fonctionne en combat

Simple : Deux choses à la fois. D'abord, la barre restait vide en combat, c'est-à-dire précisément quand suivre le texte compte le plus. Ensuite, elle n'affichait que le nom d'une entrée de menu : sur un interrupteur on avait le nom mais pas l'état, sur une ligne de sac le nom mais pas la quantité - tout ce que Sku lit en plus manquait sur la barre. Les deux sont corrigés ; la barre affiche maintenant la même ligne que Sku prononce, y compris en plein combat. Sa police et ses couleurs sont en outre réglables, avec des valeurs propres à côté de celles de la fenêtre de texte.

Technique : Le blocage en combat venait d'une confusion entre visible et ouvert : le test s'appuyait sur SkuOptions:IsMenuOpen(), qui interroge OnSkuOptionsMain:IsVisible(). Ce cadre est un ancêtre des boutons ENTER sécurisés, donc protégé, et son Show() est bloqué en combat - le menu de combat tourne volontairement sans affichage et se signale via SkuOptions.combatMenuActive. templates.lua et SkuZOptions testent déjà exactement ce couple ; la barre de lecture ne le connaissait pas. Elle-même est un cadre ordinaire sans enfant sécurisé : son Show() n'a jamais posé problème en combat. Comme le chemin de combat ne ferme le menu que logiquement (le Hide du cadre y est protégé) et le fait à six endroits, la barre se masque désormais d'elle-même : un OnUpdate vérifie toutes les 0,25 s si le menu est encore ouvert - WoW n'appelle OnUpdate que sur les cadres visibles, cela ne coûte donc rien une fois masquée. Le contenu, lui, était un paramètre jeté : l'appelant transmettait depuis toujours la chaîne parlée complète, mais c'est currentMenuPosition.name qui était affiché. La chaîne transmise est désormais prioritaire, et les points-virgules du séparateur de parole deviennent des tirets à l'affichage.

Barres de nom : les réglages que le jeu cache

Simple : Le client sait depuis longtemps afficher ses barres de nom plus grandes, plus colorées et plus contrastées - simplement, il ne le propose nulle part. La fenêtre d'options de Blizzard n'affiche aucun de ces réglages sous Classic ; la case pour des barres de nom plus grandes qui existe dans le WoW actuel est explicitement laissée vide sous Classic. Sans Sku, on n'y accédait que par des commandes console. Le nouveau menu sous Réglages -> Aides visuelles -> Barres de nom les rend accessibles : taille des barres, mise en évidence de la cible, atténuation de toutes les autres, couleurs de classe pour les ennemis et les alliés, et noms seuls pour les joueurs alliés. Contrairement à l'ancienne coloration, cela ne peint pas quelque chose derrière la barre mais modifie la vraie barre. Par défaut, tout reste tel que le client le livre : si vous ne choisissez rien, rien ne change.

Technique : Uniquement des réglages de CVar, aucun cadre propre, aucune contamination. La taille écrit nameplateMinScale et nameplateMaxScale ensemble (les séparer produirait une mise à l'échelle dépendante de la distance, dont personne ne veut ici), la mise en évidence écrit nameplateSelectedScale, l'atténuation nameplateMinAlpha, auxquels s'ajoutent nameplateShowClassColor, nameplateShowFriendlyClassColor et nameplateShowOnlyNameForFriendlyPlayerUnits. Toutes les valeurs et l'existence de chaque CVar ont été mesurées sur le client vivant 2.5.6.69546, et le plafond de 2.0 vérifié contre l'écrêtage du client. Important pour la suite : le dossier BlizzardInterfaceCode extrait dans le répertoire du client date de mars/avril 2026 et est donc antérieur au changement des barres de nom de juillet ; il cite des noms de CVar de la version actuelle comme NamePlateVerticalScale ou ShowClassColorInNameplate qui n'existent pas du tout dans cet exécutable. Ce sont les chaînes de l'exécutable qui font foi. Les écritures de CVar sont bloquées en combat et échouent en silence : une modification faite là est donc mémorisée et appliquée à PLAYER_REGEN_ENABLED. Sku réapplique les valeurs à la connexion, mais seulement une fois qu'un choix a réellement été fait dans le menu - qui a réglé ses barres de nom à la main par la console les conserve intactes.

La coloration des barres de nom survit à un redémarrage

Simple : Qui activait la coloration des barres de nom l'avait exactement jusqu'à sa prochaine connexion ou au prochain rechargement de l'interface. Ensuite l'interrupteur indiquait toujours « activé », mais plus rien n'était coloré. Le seul moyen de la relancer était de basculer l'interrupteur à la main, à chaque session. C'est corrigé ; le réglage fonctionne désormais simplement.

Technique : L'armement du pilote d'événements (NAME_PLATE_UNIT_ADDED, _REMOVED et PLAYER_TARGET_CHANGED) ne tenait qu'au OnAction de l'interrupteur du menu. La valeur enregistrée était bien lue au chargement mais appliquée nulle part : après chaque connexion, aucun événement n'était donc enregistré. L'armement se trouve maintenant dans VisualAids:OnEnable, là où l'avertissement de suivi et le bouton du prochain ennemi ont toujours été armés, avec une seconde tentative différée au cas où le profil ne serait pas encore prêt au premier passage.

Une fenêtre fermée n'est plus annoncée après coup

Simple : Apprendre plusieurs sorts chez un maître, fermer la fenêtre rapidement puis ouvrir sa fenêtre de métier ramenait la fenêtre du maître au bout d'un moment - parfois seulement après la lecture d'une infobulle. Sku retenait où il comptait encore sauter dans le menu et le faisait plus tard, sans vérifier si cette fenêtre existait toujours.

Technique : Le saut de menu différé tient en trois champs (openMenuAfterCombat, openMenuAfterMoving, openMenuAfterPath) qui étaient jusqu'ici écrits indépendamment. SlashFunc arme le drapeau ET le chemin ensemble ; d'autres endroits n'armaient que le drapeau - et héritaient donc du chemin qui traînait encore. Le chemin n'était d'ailleurs effacé que dans la partie différée de CheckFrames, qui abandonne tant qu'on se déplace et ne reprend qu'une demi-seconde plus tard, alors que la libération s'exécute à chaque image et se déclenche à l'instant où l'on s'arrête - une course que la libération gagnait. Les trois champs forment désormais un tout

(SkuCore:ClearDeferredMenuOpen), armer un drapeau efface le chemin, et l'effacement a lieu dans le hook Hide de la fenêtre (SkuCore:GENERIC_OnClose) - exactement au moment où le saut devient caduc. Délibérément sans délai d'expiration ni contrôle de visibilité : l'état est effacé là où il devient faux, au lieu d'être distancé.

Le menu n'ouvre plus son niveau le plus haut tout seul

Simple : De temps en temps le menu s'ouvrait de lui-même - et tout en haut, au lieu de là où l'on voulait aller.

Technique : SkuCoreControlOption1 porte des raccourcis clavier (distance de la cible, mode panique, scan de la minicarte, annuler le vol, se tourner vers une unité) et n'a rien à voir avec le menu. Son OnShow abandonne tant qu'on se déplace ou qu'on est en combat, car SetOverrideBindingClick y est interdit et avalerait le relâchement d'une touche de déplacement maintenue - mais il abandonnait en posant openMenuAfterMoving, et la libération, faute de chemin, en faisait une ouverture du menu à sa racine. Ce cadre a maintenant son propre drapeau (rebindControlKeysAfterBlock) et ne récupère que ses touches.

La fermeture d'une seconde fenêtre ouverte est de nouveau remarquée

Simple : Avec deux fenêtres ouvertes en même temps - un marchand et les sacs, par exemple

reconstruisait pas et ne se fermait pas.

Technique : L'un des deux installateurs de hooks enveloppait Show et Hide autour d'un unique interrupteur partagé (SkuDropdownlistGenericFlag) : tout Show le posait, et seul le premier Hide suivant le consommait. Quel installateur prenait une fenêtre était une pure question de temps - celui-ci prend tout ce qui existe une seconde après l'entrée dans le monde, tandis que des fenêtres comme le maître, le métier et l'hôtel des ventes naissent plus tard et reviennent à l'autre. L'interrupteur a disparu ; GENERIC_OnClose regroupe de toute façon lui-même.

Plus de contenu d'une fenêtre fermée sous « Local »

Simple : Après la fermeture d'une fenêtre, ses entrées pouvaient rester sous « Local » et réapparaître à la prochaine ouverture du menu.

Technique : SkuCore.GossipList est la source de données du menu Local, mais elle n'était vidée que si le menu était ouvert à cet instant précis. Sur le chemin d'Échap il ne l'est jamais : le cadre du menu descend volontairement avant les fenêtres, et la partie de code concernée s'exécute une image plus tard. Elle est maintenant vidée dès qu'aucune fenêtre n'est ouverte.

Maître : le silence une fois la fenêtre fermée

Simple : Apprendre plusieurs sorts coup sur coup et fermer la fenêtre juste après laissait les annonces du maître continuer.

Technique : Chaque clic sur « Apprendre » mettait en file une re-lecture après une demi-seconde et une annonce après 0,85 seconde, sans possibilité d'annulation. Les deux étapes vérifient maintenant que ClassTrainerFrame est encore visible. Le garde-fou de la v43.1, qui évite de parler dans un menu fermé, n'aidait pas ici : dès que la fenêtre suivante rouvrait le menu, il était ouvert. De plus, la reprise des re-lectures silencieuses en déplacement perdait sa consigne de silence et était planifiée une fois par clic - elle transporte désormais ses arguments et ne s'exécute qu'une fois.

Hôtel des ventes : la liste des résultats est vraiment triée

Simple : Trier par « Niveau décroissant » donnait malgré tout une liste qui commençait par du bas niveau. Le tri n'agissait qu'à l'intérieur d'une page - et une page, ce sont les 50 enchères les moins chères. En haut se trouvait donc le plus haut niveau parmi la camelote grise la moins chère, tandis que les objets de niveau 70 étaient des centaines d'entrées plus bas. Même après le son de fin, car rien n'était jamais retrié. Maintenant, c'est le serveur qui trie lui-même la liste par niveau ; à niveau égal, c'est le prix à l'unité qui décide.

Technique : Chaque requête partait avec le tri serveur figé sur « unitprice », et la liste des résultats se construit page après page, par simple ajout à la fin (les nouveaux objets vont en bas pour que le curseur ne saute pas). L'ordre de la liste est donc toujours celui du serveur, et notre propre tri n'ordonnait qu'une page. Pour « Niveau croissant » et « décroissant », la réponse du serveur est désormais triée sur la colonne « level » - celle-là même que règle le bouton de tri par niveau de Blizzard. L'achat et l'achat stratégique restent sur « unitprice » : ils ont besoin de l'offre la moins chère en page 0. Une recherche par nom aussi : tous les résultats y ont le même niveau, le serveur aurait trié sur un champ où rien ne diffère et aurait renvoyé ses pages dans son propre ordre au lieu des moins chères d'abord. De plus, les comparateurs de niveau utilisent maintenant le prix à l'unité comme second critère ; les enchères sans achat immédiat comptent avec leur enchère à l'unité au lieu d'un prix d'achat de 0.

Hôtel des ventes : « niveau » signifie partout le niveau requis

Simple : Le niveau affiché dans les résultats était tantôt le niveau requis, tantôt le niveau d'objet, selon la liste d'où il venait et selon que l'objet a ou non une exigence. Une pile d'Étoffe du Néant (exigence 0, niveau d'objet 55) passait ainsi devant une épée de niveau 40. C'est désormais toujours le niveau requis, la colonne que l'hôtel des ventes lui-même appelle « niveau ». Et il n'est plus lu que là où il distingue les entrées : dans une catégorie ou dans la liste du scan complet. Une recherche par nom d'objet ne renvoie que des enchères du même objet - le même nombre y revenait 800 fois. Qui filtre par niveau continue de l'entendre partout.

Technique : Un lecteur commun aux deux listes de résultats : le champ 6 de la réponse du serveur, sinon la valeur de SkuDB. Le champ 7 est pris en compte - pour les recettes, le champ 6 contient la compétence de métier requise, pour les contenants le nombre d'emplacements, et ce ne sont pas des niveaux. Le niveau d'objet n'est plus jamais utilisé en remplacement. 0 signifie maintenant « aucune exigence de niveau » et non « inconnu », d'où la disparition du « Niveau 0 » annoncé (0 est vrai en Lua, c'est ainsi qu'il finissait par être lu).

Hôtel des ventes : « utilisables uniquement » ne cache plus rien

Simple : Dans la liste du scan complet, ce filtre ne laissait plus, dans certaines catégories, que du bas niveau - précisément les objets de haut niveau recherchés avaient disparu. La recherche normale n'a jamais eu ce défaut.

Technique : Dans la liste en direct, c'est le serveur qui filtre. Le scan complet récupère tout sans filtre et Sku décide lui-même - jusqu'ici strictement d'après le champ canUse de la réponse du scan. Le client ne peut remplir ce champ que s'il disposait déjà des données de l'objet ; lors d'un scan complet, il ne les a pas pour la majorité des lignes. Ce sont exactement les lignes dont le nom, le niveau et la qualité doivent être réparés - seul canUse n'avait aucune réparation. Disparaissait donc ce que le joueur n'a jamais vu, c'est-à-dire surtout le haut niveau. Un « non utilisable » ne compte plus que sur une ligne complète ; sinon, c'est le niveau requis de SkuDB qui décide. La base ne connaît ni les restrictions de classe ni celles de race - dans le doute, mieux vaut montrer un objet de trop que taire celui que l'on cherche.

Hôtel des ventes : sans filtre, rien n'est filtré

Simple : Même sans filtre réglé, la liste du scan complet écartait tout ce qui n'a pas d'exigence de niveau - marchandises, composants, beaucoup de recettes - et en plus tout le gris, alors que le menu de qualité affichait toujours « Médiocre », donc aucune restriction.

Technique : Les valeurs par défaut des filtres non réglés étaient un 1 au lieu d'un 0, et le niveau était lu brut dans la réponse du scan. Une ligne dont le client ne connaissait pas le niveau pendant le scan revenait à 0 et tombait donc sous le niveau minimum de 1 ; la réparation depuis la base ne se déclenchait que sur une valeur absente, pas sur un 0. Les deux valeurs par défaut sont maintenant 0, le niveau vient du lecteur commun, et la réparation à la lecture traite 0 comme « absent ». Le niveau minimum de l'utilisateur employé en dernier recours a disparu : une ligne ainsi marquée passait toujours son propre filtre et était en plus annoncée avec ce niveau.

Hôtel des ventes : les catégories sans sous-catégories affichent de nouveau leurs objets

Simple : Sous « Enchères par objet », certaines catégories ne contenaient rien d'autre que « Tout » - les objets de quête, par exemple.

Technique : La liste d'objets comparait la sous-classe même là où il n'y en a aucune. Une catégorie sans sous-catégories est construite sans sous-classe, et la comparaison est alors fausse pour chaque objet. Le jumeau du scan complet portait cette protection depuis toujours ; la liste d'objets l'a maintenant aussi.

Hôtel des ventes : un achat annulé reste annulé

Simple : Annulez un achat, faites autre chose, et le dialogue d'achat pouvait revenir de nulle part - et la touche Entrée suivante, destinée à ouvrir le champ de recherche, achetait. C'était au moins le bon objet, mais personne ne l'avait demandé.

Technique : L'annulation libérait les minuteurs et les raccourcis, mais pas la cible d'achat. La fonction de requête déduit son mode exactement de là - il existe une cible d'achat, donc c'est une requête d'achat -, et la requête suivante, pourtant sans aucun rapport, partait dans le chemin d'achat : il retrouvait l'ancienne cible dans la liste fraîche, construisait le dialogue et armait la touche Entrée. Dans le journal du 01/09/2026, l'annulation (18:45:40), la nouvelle recherche (18:46:12, aussitôt « MATCH FOUND, showing popup ») et l'achat (18:46:16, « enchère acceptée ») ne sont séparés que par quatre appuis de touche. La cible d'achat est désormais effacée aux trois endroits où l'intention d'acheter prend fin : annulation du dialogue (y compris par la sécurité de 30 secondes), démarrage d'une nouvelle recherche ou liste, et fermeture de l'hôtel des ventes. Le chemin d'achat lui-même reste intact : il ne passe pas par l'entrée de recherche, et la nouvelle tentative après une course perdue conserve sa cible.

Hôtel des ventes : une recherche interrompue le dit

Simple : Quand une recherche s'interrompt parce que le serveur ne répond plus, la liste à moitié remplie restait affichée et ressemblait à un résultat terminé. On entend maintenant « Recherche interrompue, liste incomplète ».

Technique : Le chien de garde met fin à une recherche paginée après 60 secondes sans réponse du serveur, ou après 180 secondes au total - en silence, jusqu'ici. Le son de fin est le signal du « complet », mais son absence ne s'entend pas. L'annonce n'a lieu que si l'utilisateur se trouve réellement dans cette liste de résultats ; une recherche qui tourne en arrière-plan reste silencieuse.