CHARACTER_MODE_TAB_ICONS porte aussi INV_SideTab_Stats_c60, que le premier
releve avait omis. Son identifiant -- 8197104 -- rejoint ceux du PvP dans le
code et dans tools/fichiers_simples.txt.
Aucun des trois n'est verse : la feuille de 3.3.5 n'a ni onglet PvP ni
onglet des statistiques. CHARACTERFRAME_SUBFRAMES en compte cinq, et les
statistiques du jeu vivent dans AchievementFrameStats, une fenetre a part
que Blizzard_AchievementUI charge a la demande.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Le listfile communautaire ne nomme pas les INV_SideTab_*_c60 : elles
n'existent que par leur FileDataID. ajouter_feuilles.py accepte donc une
ligne "source => nom voulu" -- on exporte par l'identifiant et on range sous
le nom que camelot donne, pour que l'atelier reste lisible et que
l'identifiant demeure note.
Reputation 8197103, monnaie 8197078 : verifiees a l'apercu -- une poignee de
main, une pile de pieces -- puis posees sur les onglets 3 et 5. Avec celle
des competences, les trois onglets que camelot decrit portent leur icone.
Les deux icones PvP ne sont pas versees : la feuille de 3.3.5 n'a pas cet
onglet. Leurs identifiants sont notes pour le jour ou elle en aura un.
L'onglet du familier garde son texte : camelot n'en a pas, donc aucune
source.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CHARACTER_MODE_TAB_ICONS nomme trois icones. Celle des competences --
Ability_Racial_JackofAllTrades -- est versee et remplace le mot.
Les deux autres, INV_SideTab_Reputation2_c60 et INV_SideTab_Currency_c60,
sont introuvables : le client charge dans wow.export EST celui de camelot,
wow_classic_beta 1.60.1.69913, et son code les nomme, mais le listfile
communautaire ne leur donne aucun nom -- /resolve rend null, /search n'en
connait aucune. Reputation et monnaie gardent donc le texte du client
plutot qu'une icone inventee. L'onglet du familier, lui, n'existe pas chez
camelot : aucune source, donc pas d'icone non plus.
UpdateTabLayout corrige au passage l'ecart entre deux onglets : (0, -2) et
non (0, 0). Le chevauchement de 2 px etait perdu. La meme fonction confirme
la regle du precedent VISIBLE, posee la veille.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.3.5 efface l'onglet du familier quand le personnage n'en a pas --
PetPaperDollFrame_UpdateIsAvailable fait CharacterFrameTab2:Hide(), puis
rattache le suivant sur le LEFT du masque, sa reparation a lui, pensee pour
une rangee horizontale.
En colonne, l'onglet masque restait ancre et reservait sa hauteur :
reputation, competences et monnaie flottaient sous le personnage au lieu de
le suivre. La pile ne chaine plus que sur le precedent VISIBLE, et se refait
a chaque appel de cette fonction -- la seule qui decide de cet etat.
Le faux client sait desormais masquer cet onglet comme le vrai, avec son
rattachement horizontal, et le banc verifie les deux sens.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La source le dit : UpdateRightPaneHeader ne masque que le StoneBg -- "the
stone header backs the PaperDoll sidebar tabs, so it should not render on
tabs that have none" -- et RightPaneHost demeure. Chaque onglet aura ses
propres informations a y mettre ; le volet leur est reserve des maintenant,
vide en attendant.
Ce qui s'en va d'un onglet a l'autre n'est donc pas le volet mais le
MOBILIER du groupe : bande de pierre, onglets de page et ligne de niveau
pour le personnage -- les trois choses exactes que la source masque.
Le mobilier est un troisieme niveau dans Panes.lua, parce que deux ne
suffisaient pas : la pierre et les onglets de page appartiennent au groupe
et non a l'une de ses deux pages, ou passer de l'une a l'autre les aurait
emportes.
Le repli, lui, traverse les onglets : replie sur le personnage, il l'est
encore sur les competences, et se defait depuis n'importe lequel.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ForeverUI.Panes valait nil en jeu : le client dresse la liste des fichiers
d'un addon a l'ouverture, et /reload rejoue ceux qu'il connait sans en
decouvrir de nouveau. Panes.lua etait sur le disque et inscrit au .toc, et
pourtant absent -- la feuille s'arretait sur une erreur au chargement.
Elle le dit maintenant au joueur et se tait : le reste de l'interface tient.
Le banc rejoue le cas dans un client neuf, sans ce fichier.
A retenir, et ecrit dans le README : tout nouveau fichier demande de fermer
et rouvrir le jeu.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Elle se decidait a cinq : l'habillage, les deux onglets du volet, le repli
et la fonction des statistiques. Et l'habillage reposait TOUTE la geometrie
a chaque evenement. D'ou deux fautes que rien ne pouvait prevenir -- le
panneau du gestionnaire survivait a un changement d'onglet lateral, parce
qu'il appartient a NOTRE volet et non au PaperDollFrame du client ; les
barres de reputation traversaient ce volet, ReputationFrame gardant la
taille de la fenetre d'origine sans que personne ne le borne.
Panes.lua pose le modele de camelot : des HOTES, des GROUPES -- ce qu'un
onglet ouvre, un ecran entier -- et des PAGES, deux contenus qui se
partagent une surface. Un contenu se batit UNE fois, a sa premiere
ouverture, et ne fait ensuite que paraitre.
Les cadres du client ne sont pas reparentes : cela reinitialiserait niveau
et strate, et des reglages deja valides avec. Un contenu declare la liste
de ceux qu'il possede.
CharacterFrame_ShowSubFrame est le commutateur : le nom de l'ecran sert de
nom de groupe. La largeur de la fenetre devient une consequence -- l'hote
droit a-t-il quelque chose a montrer -- et le bouton de repli disparait la
ou il n'y a rien a replier.
Aucune mesure ne bouge : le banc le verifie sur vingt allers-retours, et
tous les essais de geometrie deja valides passent inchanges. /fui perso
rapporte desormais l'etat des hotes en tete.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bouton de 28 au coin haut droit du volet gauche, releve de camelot :
fleches de page, PrevPage depliee, NextPage repliee, survol UI-Common-
MouseHilight. Replie, la fenetre passe a 398 -- exactement la largeur du
volet gauche : le volet droit ne retrecit pas, il s'en va.
Ce qui part avec lui : les douze lignes de statistiques, leurs selecteurs
et le panneau du gestionnaire, qui sont des cadres DU CLIENT seulement
ancres dans notre volet -- les masquer un par un est necessaire.
Ce qui reste : tout le volet gauche, et les onglets lateraux, ancres au
bord droit de la fenetre et non au volet. La source ne les masque pas non
plus.
Quatre pieges regles : la largeur se decide en fin d'habillage, sinon le
passage suivant rouvrait le volet ; l'onglet ouvert se retient, sinon le
depli revenait toujours aux statistiques ; le bouton prend deux crans de
plus que le modele, qui recouvre son coin ; reposerLaPlace est declaree en
amont.
Le faux client retient desormais le proprietaire et le texte de
l'infobulle, et repond a GetOwner comme le jeu.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La recette du bouton tertiaire et ses mesures passent dans
ForeverUI.SkinTertiaryButton (AtlasUtil), employee par les selecteurs de
statistiques et par ce bouton. Son option auto fait suivre l'etat presse
au bouton de la souris ; sans elle l'appelant commande, ce que font les
selecteurs dont l'etat tient tant que leur liste est ouverte.
L'intitule est ecrit en dur : PAPERDOLL_NEWEQUIPMENTSET n'existe pas ici
et ce client ne porte aucune chaine equivalente.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Les boutons du panneau sont ses cadres fils, pas ceux de la fenetre du
client : masquer GearManagerDialog ne les emportait pas, et le bouton
restait visible sous les statistiques. Le panneau entier se montre et se
cache avec l'onglet.
Son intitule venait de NEW_COMPACT_UNIT_FRAME_PROFILE, absente de ce
client -- d'ou "New Profile", une chaine d'un tout autre panneau.
PAPERDOLL_NEWEQUIPMENTSET, que camelot ecrit, n'existe pas ici non plus :
NEW est la plus proche, et elle va avec Equip et Save.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sans ancrage donne, ToggleDropDownMenu accroche la liste a "<nom>Left" --
la piece doree du menu deroulant, que nous avons justement masquee --
d'ou le decalage. UIDropDownMenu_SetAnchor est l'entree prevue par le
client : TOPLEFT de la liste sur le BOTTOMLEFT du bouton, sans ecart.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
UIDropDownMenu_InitializeHelper finit par
frame:SetHeight(UIDROPDOWNMENU_BUTTON_HEIGHT * 2). Cette constante, nous
l'avons portee a 20 pour les lignes de menu de camelot : le selecteur
reprenait donc 40 des qu'on cliquait dessus.
La taille voulue est retenue sur le cadre et reposee par un greffon sur
UIDropDownMenu_Initialize, qui passe apres le securecall de l'aide.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
C'est la hauteur propre de l'art de bouton
(common-button-tertiary-normal, 46 x 34) : a cette taille la bande
centrale du decoupage ne s'etire plus du tout en hauteur. Les lignes de
statistiques remontent d'autant.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
habillerSelecteur la greffe sur la liste, et elle n'etait ecrite que plus
bas : son nom s'y resolvait en globale, donc nil, et HookScript refusait
le greffon. Declaration anticipee.
Le banc ne l'a pas vu parce que son HookScript acceptait nil. Il refuse
desormais tout greffon qui n'est pas une fonction, comme le vrai.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A la demande : l'en-tete UI-Character-Info-Title laisse la place a l'art
commonbuttontertiaryc60, normal et pressed, et la fleche du client s'en
va -- toute la barre ouvre deja le menu.
Decoupe et non etire : a partir de x = 11 le profil d'une colonne ne
change plus, donc coin de 11 sur les deux axes. Tendue de 46 a 203,
l'image ecraserait ses angles.
L'etat presse tient tant que la liste est ouverte. Elle se ferme de deux
facons -- ToggleDropDownMenu et CloseDropDownMenus -- donc l'etat se
releve sur le OnShow et le OnHide de la liste elle-meme.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
UI-GearManager-Button fait 64 x 64 mais son contenu opaque n'occupe que
x 6..58 sur toute la hauteur : c'est un bouton de 52 x 64, qui paraissait
rectangulaire dans un onglet carre. On en prend le carre central, la meme
plage sur les deux axes, comme l'onglet des statistiques rogne son
portrait.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sur le releve de PaperDollFrame.EquipmentManagerPane et de
GearSetButtonTemplate : panneau sous la bande de pierre, bordure
common-insideframe, cartes de 169 x 44 en colonne avec leur fond
OutfitCard, leur icone cerclee, leur intitule et la coche des ensembles
portes, puis Equip, Save et New Set au bas.
Rien n'est recree : GearManagerDialog passe dans le volet, son art de
fenetre est efface, ses cartes se reposent et se rhabillent. Le client
garde la liste, la selection et les infobulles.
Ecarts documentes : New Set passe par le Save du client, Delete est
garde (3.3.5 n'a pas le menu de carte de camelot), la coche se calcule
depuis GetEquipmentSetLocations, et la liste defile a la molette faute
de MinimalScrollBar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
GearManagerDialog_OnShow appelle UpdateUIPanelPositions(CharacterFrame)
et _OnHide appelle UpdateUIPanelPositions() : le systeme replace la
feuille a SA position et la place retenue par le joueur est perdue.
Le greffon est pose sur UpdateUIPanelPositions elle-meme, pas sur le
seul gestionnaire : toute autre ouverture qui la declenche pose le meme
probleme.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
camelot donne 42 a son Icon, soit tout le bouton, mais ses icones
portent leur propre marge transparente ; un portrait remplit sa texture
et ressortait des angles arrondis. Mesure sur UI-Character-Info-StatTab :
metal en 3..6 et 35..38, ouverture de 7 a 34, soit 28.
Les deux se comportent en onglets : le gestionnaire ouvre son panneau et
masque les statistiques, les statistiques le ferment et reviennent. Au
retour on laisse PaperDollFrame_UpdateStats refaire le travail -- lui
seul sait cacher la sixieme ligne des categories a cinq statistiques --
et poserStatistiques lit l'etat de l'onglet au lieu de tout rallumer a
chaque evenement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PLAYER_LEVEL vaut ici "Level %s %s %s" -- niveau, RACE, classe. camelot
emploie PLAYER_LEVEL_NO_SPEC, absent de ce client : la ligne est
recomposee depuis UNIT_LEVEL_TEMPLATE et le nom de classe, pour ne pas
ecrire un format en dur.
Deux onglets de 42 x 42 au-dessus, sur le gabarit de
PaperDollSidebarTabs : cadre UI-Character-Info-StatTab, marque
...-Selected, paire centree et collee. L'onglet des statistiques prend le
portrait du joueur avec le rognage de la source ; celui du gestionnaire
prend UI-GearManager-Button, PaperDollSidebarTabs.blp n'existant pas
ici. Il ouvre le GearManagerDialog du client, dont le bouton d'origine
est masque.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Profil de l'anneau mesure sur l'art, rayon en pixels d'affichage :
transparent jusqu'a 12, degrade 13 a 25, opaque 26 a 29, retombee
jusqu'a 32.
A 44 le carre s'arretait a 22 sur ses axes, dans un degrade a moitie
transparent -- les 2 px manquants de chaque cote. A 48 il atteint 24,
la ou le metal est deja opaque a 86 %. En contrepartie ses angles
tombent a 33,9, au-dela de l'anneau ; 46 reste le compromis si leurs
pointes se voient.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
L'anneau est porte par le coin haut gauche de l'encadrement : le passage
au calcul sur le filet interieur a deplace le coin de (-13, 16) a
(-18,5 ; 17), et le portrait, pose en absolu, s'est retrouve a cote.
Sa place se calcule desormais depuis le coin, plus 38 / -38,5 -- le
centre du trou, mesure sur l'art (plages 13..39 et 113..138 en double
densite) et deja confirme par la place validee en jeu. Le banc verifie
l'ecart au coin, pas la position absolue.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Decalages relatifs au voisin de gauche, qui s'additionnent le long de la
chaine : main gauche -2, distance -2 de plus, soit -4 a l'ecran, et les
munitions -4 heritees sans reglage propre.
La fleche des munitions est une region de l'emplacement -- texture
OVERLAY de 23 x 41 centree a (-22, 0) sur CharacterAmmoSlot -- elle le
suit donc.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
camelot pose l'emplacement de distance en 27 avec GearSlotSmall, comme
les munitions. Il porte pourtant, selon la classe, une arme a distance
ou une relique -- des objets de meme rang que les deux armes de melee.
Ecart assume, sur demande : les quatre font 40. Les munitions gardent le
petit emplacement de la source.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Les decalages de la source posent le contour EXTERIEUR de l'image : le
filet interieur du metal tombait a 6 px dans la fenetre, et ces 6 px de
fond restaient visibles sous lui -- ce qui se lit comme un encadrement
qui n'atteint pas le bas.
Mesure sur l'art, pas sur une capture (une capture a sa propre echelle) :
uiframemetal2xc60 est en double densite, filet interieur a 18,5 px
d'affichage a gauche, 8,5 a droite, 14 en bas. Le haut ne se recalcule
pas, ses 41,5 sont la barre de titre, interieure par conception.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
camelot/NineSliceLayoutOverrides.lua repasse sur TOUTES les mises en
page apres les avoir definies, parce que son art ne fait pas la taille
de l'art standard : coin haut droit x += -2, coins du bas y = -8.
Nous prenions les valeurs non corrigees, d'ou deux coins du bas 5 px
trop haut -- l'encadrement n'allait pas jusqu'en bas de la fenetre -- et
deux coins de droite 2 px trop a droite.
SetPanelArt prend une option coins ; la feuille s'en sert, plus 1 px de
montee juge a l'ecran. La fenetre des sacs, qui est validee, n'est pas
touchee bien que la meme correction s'y applique.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
SetUnit("player") lance un chargement asynchrone : le reglage pose juste
apres s'applique a un modele qui n'est pas encore la, et la fin du
chargement remet la transformation a zero. D'ou le symptome -- la meme
commande tapee a la main tient, parce que le modele est deja charge.
Le reglage se repose a chaque image pendant 1,5 s apres chaque passage,
sans condition : rien ne garantit que GetPosition rende ce que le moteur
dessine. Meme rattrapage que pour la hauteur des sacs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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