- GlueXML ForeverUI (data/glue) : cadre 2:1, polices, atlas, gabarits ;
connexion, menu, selection des personnages, dialogues, creation en deux
etapes (races et classes ; personnalisation numerotee, listes ouvrantes,
echantillons de couleur, apercu differe, nom en bas de l'ecran)
- choix valides calcules sur CharSections aux regles du moteur
(tools/choix_personnalisation.py) ; couleurs des echantillons lues dans
les textures du client (tools/couleurs_personnalisation.py), peau teintee
par la lumiere du decor
- decors de la creation et de la selection reduits a 0,912 pour compenser
le cadre 2:1 (tools/decors_accueil.py) ; deployer.py suit aussi
Interface\Glues\Models
- patcheur optionnel de Wow.exe (tools/patcheur, source et executable) :
CycleCharCustomization rend l'indice du reglage
- art des ecrans d'accueil (data/art), outils de decoupe, d'atlas et de
donnees
- barre du bas : boutons JcJ et Aide retires, bandeau a la largeur de ses
boutons
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
/fui micro a montre deux boutons, et eux seuls, ancres ailleurs que sur
notre bandeau : CharacterMicroButton a BOTTOMLEFT (552, 2) et
SocialsMicroButton sur le BOTTOMRIGHT de QuestLogMicroButton. C'est
exactement ce que fait VehicleMenuBar_MoveMicroButtons, appelee par
MainMenuBar_ToPlayerArt ET MainMenuBar_ToVehicleArt -- donc a chaque entree
ou sortie de vehicule. On repose apres elle, et a chaque passage general.
MainMenuBar avalait les clics a son tour : declaree enableMouse="true" et
couvrant tout le bas de l'ecran, son art remplace par le notre mais sa
souris intacte. Meme remede que pour BonusActionBarFrame.
La lecon se generalise : tout contenant du client qu'on vide garde sa
souris, et il faut la lui retirer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deux questions a la fois, pour le bouton du personnage signale decale et
sans reponse au clic.
L'ANCRAGE de chaque bouton dit s'il a bouge : nous les posons une fois, a
gauche du bandeau, d'un pas fixe. Un ancrage sur autre chose que notre
bandeau, un decalage qui n'est pas un multiple du pas, ou plus d'un point,
veulent dire que quelqu'un les a repris.
GetMouseFocus, pendant cinq secondes, dit qui recoit reellement le clic : un
bouton peut etre au bon endroit et recouvert.
Lecture du cote client : en 3.3.5, seul VehicleMenuBar_MoveMicroButtons les
deplace, et CharacterMicroButton_SetPushed ne change que le rognage et
l'alpha du portrait -- ni position, ni verrou. La cause n'est donc pas la.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
KeyRingMixin:OnBagUpdate, dans la surcharge camelot/ de
mainmenubarbagbuttons, ne pose UI-HUD-ActionBar-Keyring-Small que si la
CVar showKeyring est allumee, et prend sinon l'emplacement vide. Cette
condition vient d'un client ou le trousseau n'est plus qu'un reste du
passe, masque par defaut : la CVar ne s'allume qu'au tutoriel, la premiere
fois qu'on ramasse une cle -- d'ou la cellule vide en jeu.
En 3.3.5 le trousseau est un element permanent de la barre, et notre barre
montre toujours sa cellule : un emplacement vide y serait faux. L'image est
donc toujours posee. Ecart assume et note.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The bag window was still laid out on 3.3.5's numbers. It now follows
mainline/ContainerFrame.lua, figure for figure: width 178, five pixels between
slots in both directions, padding of 9 + 48 and thirty more for the search
row of the backpack, money frame 13 high anchored 8 from each side and 8 from
the bottom, first slot sitting on the money frame. The search box no longer
touches the grid, and the window is as tall as what it holds.
The outline was the wrong one. The reference does not frame a bag slot with
the frame of the bags bar: SetItemButtonQuality_Base lays WhiteIconFrame over
the item and tints it with its quality colour, and an empty slot has none --
its background is what shows. That is what is done now, and the money frame
gets the coin box border it was missing.
Two more sheets came into the workspace for this, one of them a plain image
rather than an atlas: tools/ajouter_feuilles.py now knows both kinds.
The end caps go down 2 pixels, as measured on screen. The bars do not move.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two corrections from what the game shows.
The order is the other way round: reputation on top, experience below. The
priorities in the file (Experience 0, Reputation 2), sorted descending, would
put reputation in the lower container; the game does the opposite. As with the
threat glow on the player frame, what the client displays wins over reading
the function, and the file says so at that spot.
And the two bars are as long as the row itself -- action bar, micro menu and
bags aligned -- instead of stopping at the inner edge of each end cap. Their
ends now pass behind the gryphons, which overlap the row by 30 on each side.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The addon and the art it needs, read from a modern client and served to
3.3.5 through texture coordinates, since that client has no atlas.
What is in place: player frame with its states, death knight runes, target
frame and its classification rings, cast bar, action bar with its page block
and end caps, micro menu, bags bar, experience and reputation bars. Every
piece registers itself as a movable system.
This folder is the workspace. The addon in a client and the art in patch-Z
are copies tools/deployer.py makes, and what sits under Interface\ForeverUI
in the patch is exactly what data/art holds -- the deployer removes from the
archive anything this folder no longer carries. Each .blp comes with the .png
that shows what it holds.
docs/AMELIORATIONS.md lists what is known to be improvable: where the
reproduction departs from the reference and why, what the 2010 client cannot
do, and the debts left in the tooling.
The repository README also gains the row for mod-limit-break, which was
written earlier and had not been committed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adrestie