Un objet de police porte la SIENNE. GameFontNormalLeft est a gauche ;
GameFontHighlight, NumberFontNormal et NumberFontNormalSmallGray n ont
aucun justifyH -- donc CENTRE, releve dans le FontStyles.xml du client.
Un SetJustifyH pose a la creation, ou avant SetFontObject, ne survit
donc pas.
Dans la reputation, le nom se retrouvait centre dans une boite dont la
largeur change d un gabarit a l autre : il se deplacait horizontalement
au fil du defilement, selon le role que la ligne reprenait. Meme faute
dans les competences et les monnaies, ou le compte d une monnaie a zero
passait de RIGHT a CENTER avec GameFontDisable.
Et sur les boutons d action, ou le raccourci et la quantite sont cales
a droite dans le code mais etaient centres a l ecran. C est du code
VALIDE : le geste ne change pas l intention, il la retablit.
camelot le fait exactement ainsi, et c est ce qui le trahit :
<FontString inherits="GameFontHighlight" justifyH="LEFT">
Le faux du harnais ne touchait pas a justify : il est desormais fidele,
et c est lui qui a trouve la faute des boutons d action.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
/fui micro a nomme le coupable : les dix boutons sont exactement a leur
place, un seul ancrage chacun, et GetMouseFocus rend BonusActionBarFrame.
Elle est declaree 505 x 43, strate HIGH, toplevel, avec enableMouse="true".
Effacer son art la rend invisible mais PAS inoffensive : elle reste une
dalle au-dessus du bas de l'ecran et avale les clics de tout ce qu'on y a
pose -- le bouton du personnage ne repondait plus.
C'est le meme piege que CharacterModelFrame sur les emplacements
d'equipement, et le meme remede : un cadre qui ne sert que de contenant n'a
pas a recevoir de clic. Ses douze boutons gardent le leur, etant des cadres
fils.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Elle montait a l'apparition mais disparaissait d'un coup. Le client rend le
mouvement inverse possible : comme pour ses autres barres glissantes, il
pose mode = "hide", CONTINUE d'afficher la barre le temps du mouvement, et
ne la masque qu'a la fin. La glissiere lit donc son mode et pas seulement sa
visibilite, et redescend d'une hauteur de bouton avant l'effacement.
Quand la barre est masquee, la glissiere se remet en bas : le mouvement
suivant repart d'en bas au lieu de sauter.
Si un client ne portait pas ce champ, le retrait resterait instantane :
rien ne peut animer des boutons deja masques. C'est note.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ancrer ses boutons au porteur lui avait fait perdre son mouvement. On ne
peut pas le rendre en deplacant les boutons image par image : ils sont
securises, le client l'interdit en combat, et c'est precisement la qu'on
change de posture.
Les boutons bonus sont donc ancres UNE FOIS a une glissiere --
ForeverUIBonusSlide, un cadre a nous pose sur le porteur -- et c'est elle
qui glisse. Les boutons suivent sans qu'on y touche, et deplacer son propre
cadre reste permis en combat. La course vaut une hauteur de bouton, la
duree BONUS_ACTIONBUTTON_SLIDE_TIME quand le client la declare, 0,2 s
sinon. Au repos la glissiere est exactement sur le porteur, donc la barre
reste a la place de la barre de sorts.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Celle qui remplace la barre de sorts quand le joueur change de posture --
BonusActionBarFrame -- etait montree par le client a une position a elle,
d'ou le decalage. Ses douze boutons sont maintenant poses sur LE MEME
PORTEUR que la barre de sorts, aux memes places : elle suit donc la
position du porteur, y compris celle que le joueur a choisie par /fui.
Rien n'est reparente : un bouton reste enfant de la barre du client, donc
il suit sa visibilite (posture, vehicule, possession) ; seul son ancrage
change. Deux consequences assumees : la barre bonus glissait a l'ecran en
se deplacant, ancree au porteur elle ne glisse plus, elle parait ; et son
art d'epoque est efface par le meme balayage de regions que celui de la
barre du familier.
Le harnais verifie que les deux barres se posent au meme endroit et sur le
meme porteur, et qu'un deplacement du porteur les emmene toutes les deux.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ce n'est pas le fond que 3.3.5 masque, c'est LE BOUTON ENTIER :
ActionButton_HideGrid le cache des que son compteur showgrid retombe a
zero, et ce compteur ne monte que le temps d'un glisser-deposer. L'art
d'emplacement vide de camelot disparaissait avec lui.
Le compteur est maintenu a 1 : le client garde alors ses boutons vides
affiches de lui-meme, et c'est lui qui appelle Show, pas nous. Un Show de
secours couvre le cas d'un bouton deja masque, jamais en combat --
afficher un cadre securise y est interdit. Ce qui est masque pendant un
combat revient a la sortie, PLAYER_REGEN_ENABLED etant deja surveille.
Defaut du harnais corrige au passage : un test posait STATE.inLockdown a
vrai sans le rendre, si bien que tout ce qui suivait tournait en combat --
et masquait donc les comportements gardes par InCombatLockdown.
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>
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