C'est la position qui cadre, pas l'echelle : SetPosition(-5.5, 0, 0)
recule le personnage devant la camera sans deplacer son cadrage.
MODELE_ECHELLE repasse a nil -- on ne touche plus a l'echelle du client.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Releve dans Wow.exe : ce client ne porte que SetModelScale et
SetPosition. Ni SetCameraDistance, ni SetCameraPosition, ni
SetCameraTarget, ni SetCustomCamera, ni SetPortraitZoom.
SetModelScale reduit le modele autour de son origine, camera fixe : il
parait donc aussi glisser vers le bas. SetPosition l'eloigne devant la
camera, ce qui le rapetisse sans changer son cadrage.
Aucune des deux valeurs ne se releve dans la source -- camelot cadre par
une scene que 3.3.5 n'a pas -- d'ou /fui modele pour les juger a l'oeil
sans recharger l'interface.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Valeur d'essai demandee pour juger a l'ecran, pas une decision. A
remplacer par la valeur retenue.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La source ne donne qu'un ecart, 6, pour les deux sens. A la demande, les
deux colonnes passent a 4 ; la rangee des armes garde le 6 de la source
et l'ecart des munitions ne bouge pas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ce client n'a ni SetCamDistanceScale ni SetPortraitZoom -- verifie dans
Wow.exe, seul SetModelScale y figure. Le personnage passe donc a 0,9,
repose a chaque passage parce que le client refait son modele quand
l'apparence change (UNIT_MODEL_CHANGED est ecoute pour cela).
Le separateur des volets etait pose au niveau du volet, donc SOUS le
cadre fils qui porte l'habillage (NIVEAU_ART) : il se perdait sous le
metal. Il prend un cran de plus, calcule depuis la constante puisque
l'habillage n'existe pas encore quand les volets se montent.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Camelot donne tout le volet gauche a la scene du modele et pose les
emplacements par-dessus. Mais CharacterModelFrame prend la souris et
nait au meme niveau que les emplacements, tous enfants de
PaperDollFrame.
Mesure en jeu (/fui perso) : emplacement et modele tous deux a 28,
GetMouseFocus rend CharacterModelFrame. Le bouton avait pourtant tous
ses scripts et prenait la souris : a niveau egal, c'est le modele qui
recoit le clic -- plus de deseequipement, plus d'infobulle.
Les emplacements passent un cran au-dessus. Le test est un "au moins",
pas une incrementation : l'habillage se rejoue a chaque ouverture et a
chaque changement d'equipement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Un bouton d'equipement qui ne repond pas est soit recouvert par un cadre
qui prend la souris, soit prive de ses scripts : rien de tout cela ne se
voit a l'ecran. Le temoin rend l'etat du bouton (strate, niveau, souris,
scripts), la liste de tout ce qui couvre son centre en prenant la souris
avec strate et niveau, puis pendant cinq secondes ce que GetMouseFocus
rend sous le curseur.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
patch-enus-9.mpq porte l'extension .disabled : le client ne l'ouvre pas.
Le bloc des statistiques visait donc des cadres qui n'existent pas
(MostrarStatPaperDoll*DropDown, PStatFrameTemplate), d'ou des selecteurs
invisibles.
La chaine d'archives repond patch-enus-2 pour le .xml et patch-enus-3
pour le .lua : c'est le FrameXML d'origine. Les selecteurs y sont
PlayerStatFrame{Left,Right}DropDown, des UIDropDownMenuTemplate dont
l'art deborde du cadre et ne le suit pas ; il s'efface au profit de
l'en-tete UI-Character-Info-Title, la fleche du client revient contre le
bord droit et toute la barre ouvre le menu.
Le modele de ligne est StatFrameTemplate, 104 x 13 : le pas passe de 16
a 13. Rien ne depend d'une archive ajoutee.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Les deux MostrarStatPaperDoll*DropDown n'ont qu'un surlignage et aucune
texture normale : sans art ils sont invisibles. Ils prennent le fond
UI-Character-Info-Title et l'intitule centre de
CharacterStatFrameCategoryTemplate (camelot), 40 de haut, debordant de 5
sur leurs lignes.
L'intitule vient de la CVar de categorie, dont la valeur est une cle ; un
hooksecurefunc sur UpdatePaperdollStats le fait suivre le menu. Le clic
reste celui du client.
Le hooksecurefunc du banc n'enveloppait pas : il enregistrait seulement,
donc un greffon ne se declenchait jamais.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
DECOUVERTE : ce client n'a pas le PaperDollFrame d'origine. Son
Data/enus/patch-enus-9.mpq livre un FrameXML MODIFIE -- PaperDollFrame.lua
et .xml, CharacterFrame.lua et .xml, plus leurs textures. C'est ce code-la
qui tourne. Le FrameXML du client est donc lisible, contrairement a ce que
je croyais : il n'est pas dans les archives communes mais dans ce patch.
Sa presentation des statistiques est reprise telle quelle : deux groupes de
six lignes -- PlayerStatFrameLeft1..6 et PlayerStatFrameRight1..6 --
chacun coiffe d'un selecteur de categorie, le modele de ligne faisant
155 x 16 avec sa valeur calee a droite et un pas de 16.
Elles sont reposees dans le volet droit, sous la bande de pierre, elargies
a 193 -- le volet fait 233, moins 20 de marge de chaque cote -- et leur
niveau de cadre passe au-dessus du fond du volet. Ce sont des cadres du
client : deplaces et elargis, jamais recrees, puisqu'ils portent les
infobulles et les menus de categorie.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Clic maintenu sur la barre du titre, la fenetre suit. Elle est bornee a
l'ecran, et rien ne bouge en combat.
Le systeme de panneaux du client repose la fenetre a chaque ouverture : la
place choisie est donc retenue dans ForeverUIDB et REPOSEE apres lui, a
chaque passage de l'habillage -- qui tourne justement a l'ouverture. Sans
cela, la fenetre reviendrait a sa place d'origine des qu'on la rouvre.
Trois bouchons du faux client rendus utiles au passage : EnableMouse,
SetMovable et RegisterForDrag ne retenaient rien, on ne pouvait donc rien
verifier de ce qu'on leur demandait.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Trois reglages, poses en constantes nommees pour se corriger d'un chiffre :
ROTATION_Y -29 -> -12, les fleches remontent dans le volet gauche
MODELE_Y +24, le modele remonte d'autant dans son volet
RESISTANCES_X +30, le panneau des resistances glisse vers la droite
Ce sont des reglages et non des releves : la capture montre trois boutons
de rotation la ou 3.3.5 en a deux, et la camera de la scene de camelot
n'est pas celle du modele de 3.3.5, qui cadre le personnage plus bas.
Le decalage des resistances repart toujours de leur ancrage d'origine,
garde a part : sinon chaque passage les pousserait un peu plus loin. Le
harnais rejoue deux passages et verifie que la position ne derive pas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
characterFrameDisplayInfo fait suivre le titre au sous-cadre affiche : le
nom du joueur par defaut, puis REPUTATION, CURRENCY, PVP, SKILLS ou
STATISTICS selon le panneau. Ce n'est pas ce qui est voulu ici : la barre
du haut garde le nom du personnage et son titre, quel que soit le panneau.
UnitPVPName rend le nom accompagne du titre porte, ou le nom seul.
Ecart assume, note dans AMELIORATIONS, et le harnais verifie que le titre
ne change pas quand un autre panneau s'ouvre.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La ligne du niveau, de la race et de la classe etait restee centree dans la
fenetre entiere, a la place que 3.3.5 lui donne. Elle prend celle de
PaperDollLevelInfo : dans le volet DROIT, au TOP (0, -54) -- la bande est a
-50 des onglets lateraux, eux-memes a -4 du haut du volet -- large de 220
et centree. C'est le "Druidesse de niveau 3" de la capture.
PIEGE 3.3.5 : une region ne se reparente pas, SetParent n'est pas dans la
table des methodes de FontString de ce client. Ancrer celle du client au
volet ne suffirait pas non plus : elle appartient au cadre et se
dessinerait sous les volets, qui sont des cadres fils. On efface la sienne
et on pose la notre dans le volet, en recopiant son texte.
Les fleches de rotation du modele se centrent horizontalement dans le volet
gauche, de part et d'autre du milieu, 29 sous son bord haut comme le montre
la capture.
Le titre reste le nom du personnage et son titre (UnitPVPName), dans
TitleContainer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Le titre du client restait a la place prevue pour un cadre de 384. Il est
repris comme sur les sacs, dans un cadre fils : TitledPanelMixin pose le
conteneur en TOPLEFT (gauche, -1) et TOPRIGHT (droite, -1), texte a TOP
(0, -5). CharacterFrame n'appelle PAS SetTitleOffsets et garde donc les
valeurs par defaut, 58 et -24 -- son milieu tombe a 332,5 sur 631, ce que
la capture confirme.
Le texte suit characterFrameDisplayInfo : le nom du joueur en clair par
defaut, l'intitule du sous-cadre affiche en jaune sinon.
Le bouton de fermeture du client passe au coin haut droit, 24 x 24 en
(1, 0), habille du X rouge des panneaux modernes. Titre et bouton sont
au-dessus du metal, comme TitleContainer a frameLevel 510 l'est du
NineSlice a 400.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La capture de reference entre dans le depot :
docs/reference/camelot_feuille_personnage.png, 923 x 663, echelle 4/3 --
le cadre y mesure 837 x 647 pour 631 x 484 logiques, ce qui confirme les
constantes de la source.
Le module est reecrit. Ce qu'il pose desormais, tout releve de camelot/ :
cadre 631 x 484, art de panneau dans un cadre fils au-dessus des volets,
coin haut gauche UI-Frame-PortraitMetal-CornerTopLeft
portrait 44 centre sur le trou mesure de l'anneau (25 ; -22,5)
volet gauche 398 avec -General-BG, volet droit 233 avec -Stat-BG etire et
-Stat-StoneBG en haut, separateur en trois tranches
emplacements 40, colonnes (24,-60) et (-20,-60), armes au BOTTOM (-60,30),
distance et munitions en 27
modele sur tout le volet gauche
ONGLETS LATERAUX : les onglets du bas de 3.3.5 passent en colonne A
DROITE, dehors -- barre de 64 x 384 au TOPRIGHT du cadre, 30 sous son
haut, onglets de 55 x 55 (l'art common-sidetab fait 55 x 60 dont 5 de
transparent). L'onglet du personnage porte son portrait, rogne a
0,03125, comme UpdateCharacterModeTabPortrait.
Art ajoute a l'atelier : interface/common/commonsidetabc60 (l'onglet, son
survol, son etat choisi).
ECART SIGNALE : les icones INV_SideTab_*_c60 que la source donne aux
onglets de reputation, devises et statistiques N'EXISTENT PAS dans l'export
du client -- seul l'art commun des onglets y est. Ces onglets gardent donc
le texte du client en attendant.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
QUATRE ONT LA MEME RACINE : les volets sont des cadres fils et recouvrent
toute region de leur parent, donc l'art du panneau pose sur le cadre
passait dessous. D'ou le contour qui ne collait pas aux fonds, le fond du
volet droit debordant sur le bord droit, celui du volet gauche mangeant
l'anneau, et le portrait vide. La source fait ce qu'il fallait faire : son
NineSlice est un cadre fils et son PortraitContainer un autre, a frameLevel
400. SetPanelArt accepte donc une option niveau, qui loge l'art dans un
cadre fils au-dessus.
Le coin haut gauche n'etait pas le bon : PortraitFrameBaseTemplate declare
layoutType = "PortraitFrameTemplate", qui ne differe de HeldBagLayout que
par lui -- un anneau plus large. SetPanelArt prend une option
coinHautGauche.
Le portrait etait vide parce que le balayage efface aussi celui du client.
On en pose un a nous, 44 centre sur le trou mesure de l'anneau (25 ; -22,5),
rempli par SetPortraitTexture. Le 44 vient du meme calcul que sur les sacs.
Le fond du volet droit ne remplissait pas : la source le declare SANS
ancrage, donc il remplit ; a sa taille d'atlas il laissait 81 px nus.
Le separateur s'etalait : common-framedivider porte un embout a chaque bout.
Il est decoupe en trois tranches par ses coordonnees de texture.
L'art d'epoque ne tient pas qu'au cadre : la feuille de 3.3.5 le repartit
sur ses sous-cadres, qui echappaient au balayage. La liste est balayee.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Le cadre, ses deux volets et les emplacements d'equipement. Le volet droit
(statistiques, onglets lateraux) et les autres onglets -- reputation,
competences, PvP, devises -- viendront ensuite.
Releve de camelot/ pour les trois fichiers, qui existent tous dans cette
saveur :
fenetre 631 x 484, PortraitFrameBaseTemplate comme les sacs
volet gauche 398, TOPLEFT (0, -20) au BOTTOMLEFT, fond -General-BG
volet droit 233 accroche a sa droite, fonds -Stat-BG et -Stat-StoneBG,
separateur common-framedivider de 11 pose a -6
emplacement 40 x 40, cadre UI-Character-Info-GearSlot a sa taille
colonne gauche TOPLEFT (24, -60), colonne droite TOPRIGHT (-20, -60),
ecart 6
armes au BOTTOM (-60, 30) du volet gauche ; distance et munitions en
27 avec -GearSlotSmall, munitions a +19
le modele occupe tout le volet gauche, comme la ModelScene de la source
Ecart assume : la source pose l'arme a (-40, 30) et masque la distance
quand celle-ci n'est pas montree ; 3.3.5 la montre toujours -- arc, arme de
jet ou relique selon la classe -- donc seule la variante a -60 sert.
Rien n'est recree : les emplacements sont des boutons du client, ils
portent le glisser-deposer de l'equipement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adrestie