Signale en jeu : « il y a beaucoup trop de Cognedur et de Sautilleur,
c est totalement anormal », et plus tot « les lapins bouclent ».
Le script d instance appelle DoAction toutes les 12 a 14 secondes, EN
BOUCLE, tant que l etat de Hoptallus n est pas SPECIAL -- c est-a-dire
tant qu il n a pas jailli de son tonneau. La boucle demarre dix secondes
apres la creation de l instance. Chaque passage invoquait 3 a 4
Sautillons et 1 a 2 Sautilleurs, sans AUCUNE limite et sans qu aucun
joueur ait besoin d etre present.
Consequence : pendant qu on affronte Ook-Ook, a 105 m de la (distance
mesuree entre les deux spawns), la salle des tonneaux se remplit toute
seule. Sur vingt minutes de donjon, de l ordre de quatre cents creatures
vivantes accumulees.
En jeu officiel ces vermifuges sortent quand le joueur CASSE les
tonneaux. Faute de cette mecanique, on garde le minuteur mais on lui
pose deux garde-fous : aucune invocation si aucun joueur n est a 60 m
(portee choisie pour couvrir la salle sans jamais atteindre l arene
d Ook-Ook, mesuree a 105 m), et vague sautee au-dela de 20 vermifuges
vivants. summons suit deja les invocations vivantes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Correctif du commit precedent, qui FAISAIT PLANTER LE SERVEUR.
Il appelait CheckCompletedCriteriaTree sur l arbre racine. Enchainement
du debordement de pile (SIGSEGV, vidage de 389 Mo contre 120 Mo en temps
normal) :
feuille achevee -> Scenario::CompletedCriteriaTree(feuille)
-> CheckCompletedCriteriaTree(racine)
-> operateur ALL : parcourt les enfants
-> CheckCompletedCriteriaTree(enfant)
-> enfant complet ET absent de _completedCriteriaTree
-> CompletedCriteriaTree(enfant) ... et on reboucle.
Le garde anti-reentrance existe pourtant (CriteriaHandler.cpp:1109),
mais l insertion dans _completedCriteriaTree se fait dans
CriteriaHandler::CompletedCriteriaTree -- que cette surcharge ne
rappelle jamais. L arbre n est donc jamais enregistre et le garde ne se
declenche pas.
On se contente desormais de LIRE la progression via IsCompletedCriteria,
en parcourant l arbre avec WalkCriteriaTree, sans jamais repasser par le
moteur d evaluation. Plus aucun effet de bord, donc plus de reentrance.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signale en jeu, capture a l appui : a la Brasserie brune d Orage, la
liste des trois boss disparaissait entierement des qu Ook-Ook tombait,
au lieu de cocher 1/1 et de conserver les deux autres.
Le scenario 537 n a qu UNE etape (972), dont l arbre de criteres 36317
porte trois feuilles : 36318 Ook-Ook, 36319 Hoptallus, 36320 Yan-Zhu.
CriteriaMgr::LoadCriteriaList attribue l etape via GetEntry, qui REMONTE
la chaine des parents jusqu a trouver une correspondance -- chaque
feuille herite donc de l etape 972. Et le moteur n evalue que les
feuilles : GetCriteriaTreesByCriteria ne renvoie que les arbres portant
directement le critere, jamais la racine.
Resultat : la premiere feuille achevee marquait l ETAPE ENTIERE
terminee. CompleteStep ne trouvait alors aucune etape suivante,
IsComplete() repondait oui, et le scenario etait cloture des le premier
boss.
On verifie desormais l arbre RACINE de l etape avant de conclure. Un
garde naif sur « tree doit etre la racine » ne conviendrait pas : la
racine n etant jamais transmise ici, l etape ne s acheverait alors
JAMAIS. CheckCompletedCriteriaTree pouvant rappeler cette fonction avec
la racine, on relit l etat de l etape ensuite -- sans quoi CompleteStep
serait execute deux fois et la quete de recompense octroyee en double.
Correctif dans le moteur partage : il vaut pour tous les scenarios dont
une etape porte plusieurs criteres.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signale en jeu : « le donjon semble avoir declenche le done total au
1er boss, je n ai plus la liste des autres boss a tuer ».
La chaine de sauvegarde etait construite par une methode Save() qui
n etait APPELEE NULLE PART. Le tampon SaveDataBuffer restait donc vide,
et InstanceScript::SaveToDB abandonne des que la chaine est vide :
std::string data = GetSaveData();
if (data.empty())
return;
Ni l etat des boss ni le masque des rencontres accomplies n atteignaient
la base. Constate directement : completedEncounters = 0 et data = '' sur
l instance 3 apres un boss tue.
Second defaut cumule : Save() n ecrivait pas l en-tete « S S B » que
Load() exige pour accepter la chaine. Meme appelee, la relecture aurait
echoue -- la progression aurait ete perdue a chaque rechargement.
GetSaveData() construit desormais la chaine lui-meme, en-tete compris
(motif habituel de TrinityCore), ce qui supprime le tampon et Save().
SetBossState declenche aussi une sauvegarde : auparavant seule la mort
d un hozen en provoquait une, via SetData.
Verifie au passage, et ecarte : les 7 lignes instance_encounters ajoutees
sont bien chargees (389 -> 396 au demarrage), le drapeau DUNGEON_BOSS est
pose dynamiquement au chargement et IsDungeonBoss le relit correctement,
et DifficultyID 0 est bien etendu a toutes les difficultes de la carte.
A noter : Yan-Zhu the Uncasked (59479) n a aucun spawn sur la carte 961.
Uncle Gao (59074) est present, donc l invocation par evenement reste
plausible -- a verifier quand le donjon sera jouable jusque-la.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signale en jeu : « Paume du tigre » et les autres attaques de melee
refusees sur Ook-Ook avec « cible hors du champ de vision ». Meme defaut
qu au Temple du Serpent de jade juste au-dessus.
MESURE PAR SONDE. Sur 17 echecs releves, 13 sont LEGITIMES : Ook-Ook
depuis son perchoir (Z ~161,8, sol a 162,63) vers un joueur dans l arene
(Z ~147), a 23-26 m -- il y a un plancher entre les deux.
Les 2 autres ne le sont pas :
Ook-Ook (-756,26 1353,21 146,97) -> joueur a 4,38 m
joueur (-757,19 1356,00 147,06) -> Ook-Ook a 2,93 m
Les deux extremites reposent sur le sol de l arene, a la meme altitude
que le plancher sous leurs pieds, et l echec se produit DANS LES DEUX
SENS. A trois metres sur un sol plat, une ligne de vue ne peut pas
echouer legitimement.
BORNES MESUREES. Tranche d altitude etroite (145-149) : le rez-de-
chaussee est un plan unique (Z 146,6 a 147,5 sur 189 spawns), ce qui
exclut le perchoir et preserve les 13 echecs legitimes. Rayon de 15 m
autour du centre d arene : la repartition des spawns donne 6 creatures a
moins de 10 m, AUCUNE entre 10 et 20 m, puis 46 au-dela -- ce vide est le
mur de l arene. On s arrete avant les salles voisines pour ne pas laisser
les monstres se voir a travers les cloisons.
RESERVE ASSUMEE : deux echecs mesures seulement, la ou le correctif du
Temple s appuyait sur trente-neuf. Bornes volontairement serrees.
Egalement dans ce lot :
- PV du hozen ivre bornes a 1 minimum. La sonde a montre que le calcul
etait sain (pvMax=285568 -> 28556) : mon hypothese du zero etait
FAUSSE. Le garde reste, mais le cadavre qui frappe n est pas explique.
- Sonde CADAVREDBG conservee : elle journalise toute creature infligeant
des degats alors qu elle est morte ou a zero PV. Elle attrapera le cas
tout seule s il se represente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trois defauts distincts, tous confirmes par la sonde OOKDBG et par les
donnees de spawn.
1. OOK-OOK NE VENAIT PAS DANS L ARENE
La sonde montre que le chemin scripte fonctionne : « SEUIL ATTEINT »,
« Ook-Ook trouve, appel DoAction(0) », puis StartIntro. Le defaut etait
en aval, et double.
a) L appel passait CINQ arguments -- MoveJump(x, y, z, 25.0f, 25.0f) --
a une surcharge (x, y, z, o, speedXY, speedZ). Le premier 25.0f
atterrissait sur l ORIENTATION. On passe par la surcharge prenant
une Position.
b) Il passait en reaction AGRESSIVE juste avant de sauter. Les joueurs
sont 16 m plus bas, donc a portee : il acquerait une cible et le
mouvement de poursuite ecrasait le saut. N ayant aucun chemin pour
descendre, il restait plante sur son perchoir -- ce qui explique
aussi qu il ait ete attaquable trop tot. Il reste passif pendant le
saut et devient agressif a l atterrissage (MovementInform, en
EFFECT_MOTION_TYPE, que le filtre existant ecartait).
Le domicile est fixe avant le saut, sinon l evade le ramene en haut.
2. TONNEAUX ENCASTRES DANS LE DECOR (capture a l appui)
DoCastBarrel figeait l altitude a 146.79, soit le sol de l arene
(ookJumpPos = 146.92). Or les Hurleurs se tiennent entre 155,6 et 161,5 :
le tonneau etait depose 9 a 15 m SOUS son lanceur, a la verticale du
balcon mais a l altitude du plancher. On interroge desormais le sol reel
sous le point vise, et le tonneau suit le sol pendant qu il roule.
3. BARRE DE BANANES BLOQUEE A 39
Le test portait sur la valeur APRES incrementation (« + 1 < 40 ») : la
barre n atteignait jamais 40/40. Signale comme « Ook-Ook apparait avant
40/40 » -- il apparaissait au bon moment, c est l affichage qui etait en
retard d une unite. Le compteur d instance, lui, etait monte a 94.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signale en jeu : « les tonneaux sont completement bugges, ils se
deplacent bizarrement ».
Deux defauts certains dans npc_barrel :
1. Le trajet etait reinitialise en plein vol. Move() relancait un
MovePoint vers un point a 5 m devant TOUTES LES 300 ms, alors que le
tonneau avance a 0,85 de vitesse (environ 5,95 m/s) : parcourir ces
5 m lui demande 840 ms. Le trajet etait donc ecrase au tiers, quatre
fois par segment. Cote client chaque reinitialisation est une rupture
de trajectoire, d ou le roulement saccade. Le deplacement est
desormais relance A L ARRIVEE via MovementInform, par segments de
20 m.
2. L orientation de depart n etait jamais fixee. Le tonneau est invoque
par un sort a 5-10 m devant le Hurleur, mais rien ne lui donnait de
cap propre. Il part maintenant dans la direction du lancer.
Arbitrage assume : la generation de chemin de MovePoint est CONSERVEE.
Un tonneau devrait rouler droit et la couper serait plus juste sur le
papier, mais c est elle qui le maintient sur le sol praticable -- sans
elle il traverserait les murs. Sur sol degage le chemin est de toute
facon quasi rectiligne.
Sonde OOKDBG ajoutee (4 points) : Ook-Ook se reveille avant le seuil de
40 hozens alors qu InitializeAI le pose en NON_ATTACKABLE et en reaction
passive, et que le chemin scripte (SEUIL ATTEINT) n apparait jamais dans
les traces. Pistes deja ecartees : les evenements 2 et 3 de l instance
ne le concernent pas, et EVENT_INTROCHECK est programme mais traite
nulle part -- evenement mort.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le sort 106778 inflige 950 points fixes (EffectBasePoints, DB2 du build
7.3.5.26972 -- valeur confirmee par la sonde : exactement 950 par tic,
sans mitigation). A quatre tics par seconde cela fait 3800 par seconde,
un chiffre calibre pour cinq joueurs.
Or ce sont des degats BRUTS : ni l armure ni les statistiques ne les
reduisent, donc Solocraft n y peut rien (verifie, il s applique bien :
+400 % de statistiques, 61 000 PV au lieu de 12 299). Un joueur seul
encaissait la charge prevue pour cinq.
La valeur est desormais multipliee par l effectif present et divisee par
les cinq joueurs pour lesquels le contenu est calibre -- le meme rapport
que celui de Solocraft. Un joueur seul prend un cinquieme. Les maitres
de jeu ne comptent pas. La valeur de base est relue dans le sort plutot
que recopiee.
La cartographie du sol par la sonde (411 releves) a confirme que le
combat est jouable tel quel : bassin central jusqu a 5 m, ANNEAU SEC de
5 a 8 m -- le « inner most circle of dry zone » de la consigne
officielle --, rigole de 8 a 10 m, dallage sec au-dela. Le corps a corps
se fait depuis l anneau interieur.
Sondes TJSWATER et TJSDBG retirees. Celles de la Brasserie (SSBDBG)
restent en place, le blocage d Ook-Ook n est toujours pas elucide.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signalé en jeu par deux joueurs. Une sonde posée dans la boucle de dégâts
a montré que le joueur n'occupe que deux altitudes dans la salle :
174,698 sur la coursive sèche (103 relevés sur 124) et 174,157 dans la
cuvette centrale (12 relevés), à 3,1-4,5 m du centre — c'est-à-dire au
corps à corps.
Toute la cuvette infligeait 950 points toutes les 250 ms, soit 3 800 par
seconde, dès l'entrée en combat et sans aucune condition. Or la Sagesse
de Mari se tient dedans (174,24) : l'approcher revenait à se suicider.
Solocraft n'y peut rien, ces dégâts ignorent les statistiques — vérifié,
il s'applique correctement (+400 % de statistiques, 61 000 PV).
La sonde a aussi écarté deux fausses pistes : les dégâts ne venaient pas
de « Lessiver » (68 des 70 relevés portaient le sort 106778, lancé par le
joueur sur lui-même à zéro mètre), et les bandes d'altitude ne sont pas
mal calibrées — elles distinguent correctement la cuvette de la coursive.
CE QUE FAIT LE JEU OFFICIEL
L'infobulle du vrai sort (115167) dit : « les eaux corrompues DE LA
FONTAINE infligent des dégâts de Givre ». L'eau n'est pas dangereuse en
soi : elle le devient fontaine par fontaine, pendant que le boss les
souille l'une après l'autre — une toutes les 29 s dans son propre script.
D'où la consigne connue du combat : tourner le long des zones sèches
jusqu'à ce que les quatre Ondes vivantes soient mortes, puis se placer
sur l'anneau sec pour la phase du jet.
CORRECTIF
Un joueur dans l'eau ne prend des dégâts que s'il est à portée d'une
fontaine DÉJÀ corrompue (aura 106518, posée par le script du boss) :
- aucune fontaine souillée -> l'eau est inoffensive ;
- chaque fontaine corrompue noie la moitié de cuvette la plus proche
d'elle, les zones sèches se réduisent ;
- les quatre corrompues -> toute la cuvette est mortelle, et c'est le
moment où la phase 2 commence.
La portée de 30 m est le rayon du sort officiel 115167 (SpellRadius
ligne 10, build 7.3.5.26972), pas un chiffre choisi au jugé. Les
fontaines étant à 24,7-29,2 m du centre et la cuvette faisant une
dizaine de mètres de rayon, il découpe naturellement la cuvette en deux
par fontaine.
Reset() du boss purge les auras des fontaines : une mort de groupe
remet bien le compteur à zéro.
RESTE À FAIRE
- La sonde TJSWATER est conservée le temps de la validation en jeu ;
elle sera retirée ensuite.
- Nous lançons toujours 106778 « Corrupted Waters NOT READY », le
brouillon inachevé de Blizzard, au lieu de 115167. Dégâts comparables
(5 000 contre 4 749 en normal) mais sans les paliers héroïque et
mythique. Non basculé ici : 115167 utilise un ciblage par destination
qui demande d'être traité à part.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signalé en jeu : le jet d'eau de la phase 2 infligeait des dégâts aux
joueurs placés derrière le boss, « comme s'il y avait des dégâts de zone
autour ».
Le sort est en réalité une chaîne de trois. 106329 canalise — et son
effet 1 est un « script côté serveur », c'est-à-dire une logique Blizzard
jamais distribuée avec les données du client. 106331 est l'aura posée sur
le boss, qui déclenche 106334 toutes les 250 ms. C'est 106334 qui blesse :
école Givre, recul 200, rayon 60 m, drapeau « ignore la ligne de vue ».
Toute la forme du jet tenait donc à une seule valeur, et à une entrée DB2
facultative :
ConeAngle = _target ? _target->ConeDegrees : 0.f;
Le mode de contrôle associé au ciblage 110, TARGET_CHECK_ENTRY, ne filtre
par ailleurs — sans `conditions` — ni l'hostilité ni la position.
Valeurs officielles relevées dans les DB2 du build 7.3.5.26972 :
SpellTargetRestrictions ligne 7514 : ConeDegrees = 12
SpellRadius ligne 48 : Radius = 60
soit un cône frontal de 12° sur 60 mètres.
Le script `spell_wise_mari_wash_away` réimpose ces 12° en dur plutôt que
de dépendre d'une donnée invérifiable côté serveur (la table spell_effect
de dc_hotfixes est vide, ces données vivent dans les fichiers DB2), et
rétablit le contrôle d'hostilité laissé de côté par TARGET_CHECK_ENTRY.
Le boss pivote de PI/48 toutes les 300 ms, soit 3,75° : avec un jet de
12°, un joueur immobile est balayé environ une seconde par tour de salle.
C'est le comportement d'origine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signale en jeu apres le correctif de ligne de vue : le sort restait fige
au lieu de balayer la salle.
Unit::SetFacingTo abandonne en silence quand la creature nest pas a
larret :
if (!force && !IsStopped()) return;
Or la phase 2 lance MovePoint vers la position de depart juste avant :
elle EST en deplacement, la rotation ne partait donc jamais. Et le
SetOrientation qui precede ne met a jour que la valeur serveur, sans
prevenir les clients.
Seuls les deux appels de la phase 2 recoivent force = true. Le troisieme,
celui de lHydrolance en phase 1, est laisse tel quel : elle est a larret
a ce moment-la et il fonctionne.
Sondes retirees : la sonde a montre que la mecanique du combat est saine
— quatre fontaines trouvees, un elementaire invoque a chaque appel
(compteur 0 puis 1, 2, 3) et bouclier retire a foutainCount=4. Le seul
defaut etait la ligne de vue, corrigee au commit precedent. Le blocage
signale par le joueur — « les elementaires sont coinces, on ne peut pas
les buter, du coup le boss garde son bouclier » — sexplique entierement
par la : il ne pouvait frapper personne.
Signale par « le baltring » puis reproduit : aucun sort a distance
naboutit sur aucun PNJ de la Fontaine des Temoins, et la Sagesse de Mari
etait annoncee « hors de portee de vue » alors quelle est visible a
7 metres.
Fausses pistes ecartees avant de trouver, toutes verifiees : les drapeaux
(32832 est exactement celui du Sha du doute, jouable), un objet du monde
qui bloquerait (aucun a moins de 15 m), des tuiles de collision
manquantes (0960_36_30.vmtile fait 82 Ko, la plus grosse de la carte),
une position aberrante, et le phasage.
Mesure faite par une sonde posee dans IsWithinLOS. Sur 39 echecs :
tous tiennent dans une boite de 26 x 18 m — la salle et rien quelle, le
reste du donjon est indemne ; la tranche daltitude est etroite, 172,6 a
174,3 ; les distances vont de 4 a 18 m, donc meme a bout portant ca
bloque ; et la Sagesse de Mari elle-meme echoue a viser les joueurs.
Il y a donc de la matiere de collision A LINTERIEUR de la piece, dans la
tranche ou tout le monde se tient : lextraction du modele est fautive,
pas un fichier manquant.
Deplacer les creatures ne servirait a rien, le joueur aussi est dans la
zone fautive. La ligne de vue est donc neutralisee, mais UNIQUEMENT
quand les DEUX extremites du rayon sont dans le bassin. Hors de cette
boite, et sur toute autre carte, le calcul reste strictement inchange.
A retirer si les cartes de collision de la carte 960 sont un jour
re-extraites correctement.
Le serveur est tombe le 24/08/2026 dans le Temple du Serpent de jade,
SIGSEGV. Pile du vidage memoire, sans ambiguite :
PlayerStorage::IsEntryExists
<- spell_monk_mastery_combo_strikes::HandleHit
<- Spell::HandleEffects <- HandleCastSpellOpcode
Larret est a IsEntryExists+4, cest-a-dire au tout premier acces a this.
m_playerStorage est DECLARE dans Player.h et lu par GetStorage(), mais
alloue NULLE PART dans tout le depot : ni liste dinitialisation, ni
corps du constructeur, aucune affectation. Le pointeur contenait donc
des ordures des la construction du joueur.
Quatre scripts du Moine le deferencent sans controle dans spell_monk.cpp
— maitrise « Frappes combinees », Poings de furie. Le premier moine a en
declencher un faisait tomber le worldserver. Ce netait quune question de
temps : la classe est utilisee depuis toujours sans jamais avoir existe.
La classe PlayerStorage est parfaitement fonctionnelle, il ne manquait
que son allocation. Elle est desormais creee dans le constructeur et
liberee dans le destructeur : le plantage disparait ET la maitrise du
Moine devient operante.
Ceinture et bretelles : les quatre appels recoivent en plus une garde de
nullite, pour quun oubli similaire ne soit plus jamais fatal.
« Arretez Guldan ! » etait proposee en double par Maiev. Les quetes 38723
et 40253 partagent titre, prerequis, tri, et sont ouvertes a toutes les
races : rien ne les departageait. Ce ne sont pas des variantes
Horde/Alliance malgre le nom des constantes QUEST_STOP_GULDAN_H/_A — le
meme fichier les nomme correctement plus bas DMG_SPEC et TANK_SPEC. Ce
sont des jumelles de specialisation.
Le gestionnaire de conditions navait aucun moyen de tester la
specialisation. Le contournement par un sort caracteristique netait pas
tenable : les sorts de specialisation ne sont quasiment pas enseignes
sur ce serveur, les trois Chasseurs de demons existants ne connaissent
que Morsure de demon et celui de niveau 98 na pas sa Metamorphose. Une
condition batie dessus aurait masque les DEUX quetes.
CONDITION_SPECIALIZATION lit Player::GetPrimarySpecialization() et
valide la valeur contre ChrSpecialization.db2 au chargement.
Formulation retenue en base : la quete Vengeance exige la spe Vengeance,
la quete Devastation exige de NE PAS etre Vengeance. Il y a ainsi
toujours exactement une quete proposee, meme si la specialisation vaut
zero — un doublon agace, zero quete bloque.
Reutilisable : le serveur compte 1488 paires de quetes homonymes
partageant prerequis et races.
Signale en jeu : le joueur arrive au Caveau des Gardiennes avec ses
glaives DEJA EQUIPES. La quete « Notre dernier espoir » lui demande de
les equiper, mais levenement dequipement a eu lieu avant quil ne prenne
la quete. Ne guetter que OnItemLevelChange laissait donc la quete
bloquee dans le cas le plus courant.
Le script verifie desormais a trois moments : equipement dun glaive,
acceptation de la quete, et connexion. Le dernier rattrape les
personnages deja bloques — une simple reconnexion suffit.
Audit complet des 42 quetes de Mardum (1481) et du Caveau des Gardiennes
(1468) apres une traversee de la campagne ou les blocages avaient ete
franchis a la commande GM. Six quetes restaient impossibles a terminer
normalement.
Quetes sans aucun donneur
38668 / 38669 « Notre dernier espoir » et 38689 « Infusion gangrenee »
n'avaient aucune ligne creature_queststarter. Attribuees a leur
recepteur deja en place (Maiev 92718, Altruis 92986), tous deux deja
porteurs du drapeau de donneur. L'ordre officiel de la chaine est
retabli via PrevQuestID (38668 -> 38669 -> 38672 -> 38689 -> 38690 ->
38723/40253), ce qui corrige au passage le piege signale en jeu :
accepter « La gangr'evasion » faisait partir Maiev avant que les
autres quetes aient pu etre prises.
Objectifs obligatoires sans aucune source
38690 : les huit « Warden Cell » (244588) etaient posees mais inertes
— aucun AIName, aucun script, tous les Data a zero. SmartAI
ajoute sur le motif de la « Scourge Cage » 187854.
38672 : les cellules 103655/103658 avaient tout leur SmartAI sauf
l'action 33. Le script C++ prevu n'aurait rien regle : non
rattache, lignes de credit commentees, et entrees erronees.
38723/40253 : le credit « Face Gul'dan » 99303 dependait d'une scene
absente de scene_template. Ajoute a la liste d'actions de
Maiev, qui reproduit deja la scene.
38689 : les quatre demons du caveau accordent desormais l'energie
gangrenee, dix par mort, comme le prevoyait npc_fel_infusion.
38765 : go_mardum_portal_shivarra appelait ForceCompleteQuest sous la
condition inverse de ses deux jumeaux. Remplace par les credits
94407 et 97831, sur le schema des portails Cendrelangue et
Glissentaille.
38669 : nouveau PlayerScript accordant les credits des glaives via
OnItemLevelChange. Aucun identifiant d'objet code en dur : on
verifie la sous-classe WARGLAIVES dans chaque emplacement.
Butin
Compare aux tables officielles de Wowhead pour les 17 creatures
tuables de la zone. Le menu fretin de Mardum ne lache officiellement
rien : lootid = 0 etait correct, rien n'a ete touche. Manquaient en
revanche 132753 « Rations de la Legion » (absente des 46 000 lignes de
butin du serveur), 129196 sur quatre creatures, 147430, 132138, et
sept des huit lignes de l'Inquisiteur Funeste. Les objets
post-Legion que Wowhead attribue a ces creatures sont ecartes, et les
taux existants ne sont pas modifies.
Signale en jeu : boss juge trop puissant. Ses statistiques sont pourtant
authentiques - modificateur de vie 14, rang elite, VerifiedBuild 25549 -
et identiques a celles de Sledge, Crusher et Tyranna deja vaincus.
Le probleme venait du script : les trois sorts etaient lances avec
triggered = true, donc instantanes et non interruptibles. Or ils ont tous un
temps dincantation cote client :
200007 Annihilation gangrenee : 3 s, cone frontal -> il faut en sortir
200027 Ombres ecrasantes : canalise 5 s -> interruptible
200002 Effacement tenebreux : 2 s, +100% desquive -> interruptible
Toute la parade disparaissait. Surtout, le bouclier desquive a 100% montait
instantanement toutes les 6 s : le boss esquivait la quasi-totalite des
coups. Ce netait pas un boss surpuissant mais un boss intouchable.
Passage en incantation normale sur les trois. Comportement authentique
retabli, aucune statistique modifiee.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Preuve dans Server.log, exactement une fois par tentative de connexion
bloquee :
CMSG_DB_QUERY_BULK: [Daemon] requested unsupported unknown hotfix type:
3386291891
HandleDBQueryBulk se contentait de journaliser puis de RETURN sans envoyer
la moindre reponse. Le client, qui attend une reponse par enregistrement
demande, restait bloque indefiniment a lecran de chargement.
Corrige en emettant une reponse negative (Allow a false) pour chaque
enregistrement demande, comme le fait deja la branche enregistrement
introuvable juste en dessous.
Portee generale : nimporte quel client reclamant une table que ce core ne
connait pas restait bloque, quelle que soit la carte. La table en cause ici
etait 0xC9D6B6B3, absente des metadonnees du core.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Preuve dans Server.log : "tried to respond to invalid player choice 234
(allowed 0)". Le clic atteignait bien le serveur, mais celui-ci avait
memorise 0 au lieu de 234.
Enchainement fautif dans npc_korvas_bloodthorn::OnGossipSelect :
1. CastSpell(196650) -> EffectLaunchQuestChoice -> SendPlayerChoice(234)
inscrit PlayerChoiceId = 234
2. CloseGossipMenuFor() -> SendCloseGossip() -> _interactionData.Reset()
remet PlayerChoiceId a 0
La fenetre saffichait (le paquet etait deja parti) mais le serveur avait
oublie quel choix il autorisait. Cest pour cette raison que le tome de
Mardum fonctionne : lui ne ferme pas le dialogue.
Corrige en fermant AVANT de lancer le sort. Balayage de tout le core :
34 occurrences du motif CastSpell puis CloseGossipMenuFor, mais une seule
autre concerne un sort qui affiche un choix (class_hall_hunter.cpp), les
autres lancent des sorts ordinaires ou reinitialiser est sans effet.
Les deux sont corrigees.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signale en jeu : choisir entre Kayn et Altruis ne declenche rien.
1) HOOK MORT, 4 occurrences. OnCompleteQuestChoice est declare dans
ScriptMgr mais appele DE NULLE PART ; le seul hook invoque a la reception
dun choix est OnPlayerChoiceResponse (QuestHandler.cpp). Corrige dans :
zone_vault_of_wardens.cpp choix Kayn / Altruis
zone_legion_dalaran_legion.cpp Dalaran
class_hall_dh.cpp fief chasseur de demons
class_hall_hunter.cpp fief chasseur
Meme defaut que celui corrige a Mardum (commit 81b37487). Dautres fichiers
(class_hall_monk, class_hall_artifact_choices) utilisaient deja le bon nom,
ce qui confirme le diagnostic.
2) CREDIT MANQUANT. Le handler ne lancait quun sort : lobjectif 99278
(choisir entre Kayn et Altruis) de la quete 40373 netait accorde par rien.
3) QUETE SANS DONNEUR. 40373 a un recepteur et deux objectifs coherents
mais aucune ligne creature_queststarter. Attribuee a Korvas 97644 : elle en
est deja la receptrice, cest son propre script qui ouvre la fenetre de
choix, elle recoit aussi la quete precedente 39686, et elle porte npcflag=3.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Le livre relancait le choix de specialisation sans aucune condition : le
joueur pouvait le rouvrir et reprendre lautre spe a volonte. Chaque passage
relance LearnSpell + ActivateTalentGroup et reaccorde le credit de quete.
Consequence observee le 18/08/2026 sur un personnage de test :
primarySpecialization restee a 577 (Devastation) alors quil portait larme
de Vengeance et avait recu la variante Vengeance de Cry Havoc.
Deux gardes : le livre ne souvre plus une fois la quete 40051 validee, et
le gestionnaire de reponse refuse de sappliquer deux fois quelle que soit
la facon dont la fenetre serait rouverte.
NOTE : ces 16 lignes etaient deja EN SERVICE depuis hier - embarquees par
les compilations suivantes - mais jamais commitees. Elles le sont enfin.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signale en jeu : premier boss du Temple du serpent de jade infaisable, le
bouclier du boss ne tombe jamais.
Le tableau foutainTrigger a 4 cases (indices 0-3), mais les deux acces
utilisaient la PRE-incrementation :
ecriture : foutainTrigger[++tab] -> indices 1,2,3,4
lecture : foutainTrigger[++foutainCount] -> indices 1,2,3,4
Lindice 0 netait jamais rempli, et lindice 4 ecrivait 16 octets hors
limites - juste par-dessus hydrolancePhase, declare immediatement apres le
tableau. La salle contenant exactement 4 Fountain Stalker (56586), le
debordement etait systematique a chaque pull.
Corrige en post-incrementation des deux cotes, avec garde de borne a
lecriture. La condition de fin de phase (foutainCount == 4) reste juste.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Quatre corrections nees d une soiree d essais en jeu.
Le mercenaire etait teleporte sur son employeur et non sur la structure qui
l invoque : en reculant de quelques pas avant de payer, on le voyait apparaitre
loin du portail. Le contrat retient desormais la position de la structure ; le
mercenaire en sort a un ou trois metres, l angle tire au hasard pour que quatre
recrues ne s empilent pas, face au portail qu il vient de franchir, la hauteur
recalee sur le terrain. BotGroupAI expose pour cela un teleport vers un point
precis - un bot n a pas de client pour accuser reception, seul BotAITeleport
simule cet echange.
Il jurait ensuite selon sa faction : un demoniste de l Alliance invoquait donc la
Lumiere, qui est precisement ce qui le brule. Les serments viennent maintenant de
la CLASSE et l origine de la RACE. Nuance importante : demonistes et chevaliers
de la mort ne se reclament jamais de la Lumiere, mais peuvent la maudire et s en
moquer - c est leur role.
Enfin, les refus passagers des fournisseurs (503, 429) sont retentes deux fois
avant d abandonner, dans le fil dedie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il tenait son role mais parlait dans le vide. Trois ajouts.
Un socle sur Azeroth a l heure de la Legion : les Iles Brisees, Dalaran qui
flotte, les armes prodigieuses, Sargeras, le retour d Illidan, les continents,
les capitales des deux factions, la monnaie. Avec une contrainte qui compte
autant que le reste : il n a JAMAIS entendu parler de ce qui vient apres -
Kul Tiras, l Ombreterre, les Dragons. Un modele entraine sur tout le corpus de
Warcraft racontait sinon des evenements qui n existent pas sur ce royaume.
Le lieu reel ensuite : la zone et la sous-zone sont lues dans les tables du
client (AreaName->Str[locale]) et injectees a chaque replique. Le mercenaire
peut enfin rechigner sur le froid d une region qu il traverse vraiment.
Enfin, la relance des refus passagers. Les paliers gratuits repondent
regulierement 503 ou 429 ; renoncer au premier essai laissait le mercenaire muet
pour une gene d une seconde. Trois tentatives espacees, dans le fil dedie - la
boucle du monde n en sait rien. Un refus definitif, lui, n est jamais retente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le correctif precedent ne visait que le chuchotement, celui que la pile d appel
designait. La requete du canal de groupe (ai_talk_group) portait le meme defaut,
dans une boucle sur les membres qui plus est : une requete par bot present.
Le royaume est retombe cinq minutes apres le premier correctif, sur le meme mot -
« c est » - avec la meme erreur 1064. Lecon : chercher toutes les occurrences du
motif, pas seulement celle que le crash montre.
Retrait au passage de la trace de diagnostic temporaire : le message du
fournisseur, remonte au joueur en jeu, suffit desormais.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Quand un joueur chuchote a un playerbot, le core cherche une reponse toute faite
dans ai_talk_whisper et injectait le message BRUT dans la requete :
WHERE '%s' REGEXP cname
Une apostrophe - « c est », « j ai », une phrase de francais sur deux - cassait
la requete. MySQLConnection::_HandleMySQLErrno repond a une erreur SQL par un
abandon du processus : n importe quel joueur faisait donc tomber le serveur en
adressant la parole a un bot, et pouvait y injecter du SQL au passage.
Trois crashs SIGSEGV en une soiree (23h06, 23h44, 23h58), tous avec la meme pile
HandleChatMessage -> DatabaseWorkerPool::Query -> _HandleMySQLErrno -> Abort. Le
defaut preexistait, mais le module de dialogue l a reveille : jusqu ici personne
n adressait la parole aux playerbots.
Le message est desormais echappe et borne a 255 caracteres.
Second changement, sans rapport : Mistral devient un fournisseur a part entiere.
Il parlait deja le dialecte d OpenAI, mais « mistral » n etait qu un alias : sans
adresse explicite, la cle du joueur partait chez OpenAI, qui la rejetait par un
401 incomprehensible. Il a maintenant son adresse par defaut, et l aide en jeu
signale que Gemini ne repond pas depuis un serveur.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le mercenaire parle desormais avec le modele de langage de son employeur, paye
par la cle d API de celui-ci. Inspire de mod-ollama-chat (AzerothCore), mais
avec trois exigences qui changent l architecture : cle apportee par le joueur,
plusieurs fournisseurs, aucune persistance.
Trois adaptateurs natifs : OpenAI (et tout service parlant son dialecte, via une
adresse personnalisee : Mistral, Groq, OpenRouter, Ollama, LM Studio), Anthropic
et Gemini. Le joueur fournit sa cle en jeu par « !api <fournisseur> <modele>
<cle> », la retire par « !api off ».
La cle n atteint jamais un disque. Elle est interceptee des la premiere
instruction de HandleChatMessage, avant tout journal et toute rediffusion ;
elle vit en memoire, est ecrasee caractere par caractere avant liberation - un
simple clear() laisserait le secret lisible dans le processus - et disparait a
la rupture du dernier contrat, a la deconnexion et a l arret du royaume.
Aucun appel reseau ne part du fil du monde : un fil dedie consomme une file
d envoi, les reponses reviennent par une file relue au tick. Un appel prend une
a dix secondes ; le faire dans la boucle du monde figerait le royaume a chaque
replique.
Le mercenaire repond dans le canal ou on lui parle. Le chuchotement reste
l affaire de l employeur ; dans le groupe et a voix haute, tout compagnon peut
l interpeller, mais un seul mercenaire repond - celui qu on nomme, sinon le
premier sous contrat - et c est toujours la cle de l employeur qui paie.
Contrepartie indispensable : les ordres passent au prefixe « ! » (!follow,
!stop, !@heal stop). Sans cela, le mot « stop » au detour d une phrase aurait
fige le mercenaire.
Deux obstacles contournes : le rapidjson embarque ne compile plus avec GCC 14
et le core ne s en sert que par son lecteur evenementiel - un extracteur JSON
cible le remplace, echappements et sequences Unicode compris ; libcurl est lie
directement plutot que d activer WITH_CPR, qui recompilerait curl et cpr en
entier pour le meme service.
Inclut un correctif sans rapport decouvert en chemin : une recrue du siege des
capitales abandonnee en depassement de delai etait rayee des registres sans
etre deconnectee, et chaque assaut laissait ainsi quelques bots vagabonder.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Doctrine PvP : repartir seul de son cimetiere revient a nourrir l adversaire
un par un. Les bots ressuscites repartaient isolement et se faisaient cueillir
en chemin. Un bot patiente desormais au cimetiere jusqu a ce que trois allies
soient a portee, au maximum huit secondes. Il repart immediatement s il est
attaque, si un ennemi pousse jusqu au cimetiere, ou s il porte un drapeau.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1. Laisse : un bot ne se laisse plus entrainer loin de son objectif par un
fuyard. Au-dela de 50 m du point a tenir la cible est fortement
deprioritisee, sauf le porteur de drapeau qu il faut poursuivre partout.
Sans cette regle les defenseurs desertaient leur base des le premier
ennemi croise, defaut classique des IA de champ de bataille.
2. Escorte a Chanteguerres : jusqu a trois allies deja proches (60 m) collent
le porteur pour intercepter ses poursuivants. L Oeil du cyclone avait deja
ce comportement, Chanteguerres laissait le porteur rentrer seul.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Complement de c25c1305. Le credit 101760 netait accorde que dans
DamageTaken, au coup fatal, aux seuls joueurs figurant a cet instant dans
la liste de menace de Tyranna. Dans un combat ou quatre PNJ compagnons
frappent aux cotes du joueur, cette conjonction rate - constate en jeu :
le joueur tuait bien Tyranna, ramassait la Cle de voute (qui ne tombe que
sur son cadavre), et restait bloque sur ce seul objectif.
La cause exacte de lechec na pas pu etre determinee apres coup : trois
conditions doivent etre reunies simultanement (instance de degats letale,
liste de menace non vide, quete en cours) et rien dans les donnees ne dit
laquelle a manque. Do le choix de supprimer la dependance plutot que de
la diagnostiquer.
Le credit est desormais aussi accorde dans JustDied, par proximite (100 m)
et sans condition de menace, sur le modele du script de lInquisiteur
Baleful. Lancienne voie est conservee : les deux sont idempotentes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signale en jeu : le joueur descend, trouve la Cle de voute sargerite,
clique dessus, rien ne se passe - et la quete reste bloquee.
Le troisieme objectif (credit 101760, Find the way downstairs) netait
accorde que par le script de Tyranna, dans DamageTaken, aux seuls joueurs
presents dans sa liste de menace au coup fatal. Deux facons detre bloque :
le script non rattache au moment du kill (cas rencontre), ou le coup fatal
porte par Kayn. Une fois en bas, plus aucun recours sur place : il faut
remonter et retuer le boss.
Lobjectif sappelle pourtant trouvez le chemin vers le bas et la cle se
trouve justement en bas. Le gameobject 245728 laccorde desormais aussi,
en plus du credit 100651 qui appartient a la quete suivante (38729).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signale en jeu : cliquer sur loption de dialogue dAllari, Cyana, Kayn,
Korvas ou Mannethrel ne produisait rien.
Cry Havoc existe en DEUX versions strictement jumelles - memes cinq
objectifs, meme donneur (Kayn 93127) - une par specialisation :
39516 Semer la devastation (Devastation)
39515 A moi la vengeance ! (Vengeance)
Le script ne testait que 39516, en six endroits. Pour un joueur ayant
choisi Vengeance, HasQuest renvoyait faux et chaque handler sortait
immediatement. Le script de la Vigie brisee gere pourtant bien ses propres
variantes (_HA/_HH/_VA/_VH, _H/_V, _DMG_SPEC/_TANK_SPEC) : loubli est
propre a Mardum.
Verification systematique faite : en croisant toutes les quetes codees en
dur dans les deux scripts DH avec la liste des quetes partageant une
signature dobjectifs identique, Cry Havoc est la SEULE de Mardum a avoir
une jumelle non geree.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signale en jeu : le tome ouvre bien le choix, on selectionne Devastation ou
Vengeance, mais la quete reste incomplete.
Trois defauts :
1. Le script implementait OnCompleteQuestChoice, un hook declare dans
ScriptMgr mais appele DE NULLE PART. Le seul hook invoque par le core
est OnPlayerChoiceResponse (QuestHandler.cpp). La methode etait donc du
code mort - preuve mesuree en base : le joueur navait pas appris le sort
200749 et son activeTalentGroup restait a 0.
2. Aucun credit de quete nulle part, alors que 40051 exige lentree 99071.
3. La branche Devastation nactivait pas la specialisation, contrairement a
celle de Vengeance : asymetrie qui laissait le joueur sans spe.
AssertEntry remplace par LookupEntry avec garde, pour ne pas abattre le
serveur si un identifiant de specialisation manquait.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signale en jeu : le tome des secrets gangrenes ouvre le choix de
specialisation, la question saffiche mais les deux boutons sont vides.
Trois defauts cumules dans Player::SendPlayerChoice :
1. Le filtre exigeait une recompense avec un sort VALIDE pour quune
reponse soit envoyee. Le choix 231 (Devastation / Vengeance) a
SpellID=0 : les deux reponses etaient silencieusement ecartees.
2. displayPlayerChoice.Responses etait redimensionne AVANT le filtrage,
laissant une entree vide par reponse ecartee - do les boutons vides.
3. Reward->SpellID etait dereference sans controle alors que Reward peut
etre nul, comme le montre le test plus bas dans la meme fonction :
un plantage en attente pour toute reponse sans ligne de recompense.
Correctif general, valable pour tous les choix, pas seulement celui-ci.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signale par un joueur, reproduit 2 fois (SIGSEGV 17/08 22:09 et 22:15).
JustDied() invoque le Slipstream 45457 pour ouvrir la voie vers la 2e
plateforme, puis pose son drapeau de dialogue sans verifier le retour.
Lentree 45457 nexiste dans aucune base (ni la notre, ni TDB 7.3.5) :
SummonCreature renvoie nullptr et le dereferencement tue le worldserver
dans Unit::Kill a chaque mort du boss.
- SQL : creation de lentree 45457 par clonage de 45455, avec le script
npc_slipstream_two deja present et enregistre dans le core.
- C++ : controle du nullptr sur les deux occurrences du motif (Altairus
et Grand Vizir Ertan) pour quune donnee manquante ne puisse plus
faire tomber le serveur.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1. Un porteur de drapeau ne selectionne plus de cible : il court au but
pendant que son escorte le protege (doctrine PvP). Auparavant il engageait
le premier ennemi croise et mourait au milieu du terrain avec le drapeau.
2. Retrait de 4 traces PBOT heritees de l upstream, emises a chaque tick de
chaque bot (80 bots en Alterac) : formatage et ecriture disque inutiles a
chaque passage, et l une d elles dereferencait GetBattleground() sans
controle de nullite.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Le bot prenait l ennemi le plus bas en vie sous 80 %, sinon un ennemi AU
HASARD : aucun feu concentre, soigneurs ennemis jamais inquietes, porteur de
drapeau ignore. Les cibles sont desormais notees selon la doctrine PvP de
champ de bataille (Vanilla -> Legion) :
porteur de drapeau +1000 (objectif du match)
soigneur ennemi +400 (un soigneur libre rend le combat ingagnable)
cible blessee +3 par point de vie manquant (achever plutot qu etaler)
allie deja au contact +60 chacun (feu concentre)
distance -1 par metre
hors ligne de vue -250
Detection du soigneur par classe ET specialisation (un paladin protection
n est plus traite comme un soigneur) ; le feu concentre se lit sur la liste
des attaquants de la cible, sans recherche couteuse.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Suite de la recalibration commencee par le mage. Meme methode : chaque valeur
a ete verifiee presente dans character_spell chez les bots de niveau 110 du
serveur, la base faisant foi plutot qu une documentation externe.
Guerrier 12 constantes Paladin 8
Chaman 11 Priest 8
Druide 9 Voleur 6
Chasseur 5 Demoniste 3
Cas notable du guerrier : Frappe mortelle et Broyeur de colosse, le coeur de la
rotation Armes, n avaient aucune constante dans l IA. Deux constantes devenues
mortes ont ete repointees dessus.
Le chaman Restauration recupere toute sa panoplie de soins, qui etait
integralement inoperante : Vague de soins, Salve de soins, Chaine de soins,
Vague de rappel, Pluie de soins, Totem de maree de soins, Totem de lien
spirituel. C est la condition pour que les soigneurs de la horde du siege
tiennent leur role.
Le pretre Ombre retrouve Attaque mentale, Toucher vampirique, Eruption du Vide
et Forme d ombre ; le paladin Vindicte Lame de justice, Verdict du templier et
Tempete divine ; le druide Equilibre Courroux solaire, Frappe lunaire et
Poussee d etoiles, et le Gardien Fourrure de fer et Regeneration frenetique.
Total sur les neuf classes : 49 constantes recalibrees.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Les IA de BotClassAI resolvent leurs sorts par FindMaxRankSpellByExist. Quand le
bot ne connait pas l identifiant, la constante vaut 0 et toutes les branches qui
en dependent sont sautees en silence. Mesure sur les bots 110 du serveur : entre
80 et 93 pour cent du repertoire de chaque IA est du code mort, les identifiants
datant d une version bien anterieure du jeu. Le chaman connait 3 des 43 sorts
qu il reclame, le mage 4 sur 46.
Mage recalibre en premier, sept constantes : Trait de givre, Lance de glace,
Bourrasque, Blizzard, Orbe de givre, Barriere de glace, Frappe de feu. Les
valeurs viennent de la base du serveur et non d une documentation : ce sont les
sorts que les mages 110 possedent reellement.
sylvania/RECALIBRATION-IA-CLASSES.md consigne la methode et le kit Legion
verifie present pour les neuf classes, pour ne pas refaire ce releve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La horde etait recrutee sans regard pour les roles : n importe quelle classe,
avec la specialisation que le personnage portait deja. Les IA de classe savent
pourtant distinguer les roles - BotPaladinAI soigne en Sacre, BotPriestAI hors
Ombre, BotShamanAI en Restauration - mais cette logique ne servait a rien
puisque la specialisation n etait jamais imposee.
Le recrutement vise desormais des quotas, nouvelles cles siege_tank_pct et
siege_healer_pct (10 et 20 par defaut, somme plafonnee a 60). Les soigneurs et
les tanks sont engages en premier : sans eux la horde fond avant le trone.
FindSpecIndexForRole interroge ChrSpecialization pour trouver la specialisation
que la classe doit prendre, et le re-level la lui impose via parameter3.
Les specialisations d index superieur a 2 sont ecartees : elles sont hors de
portee du re-level, qui refuse talent > 2. Cela concerne la Restauration du
druide, dont l IA de classe attend de toute facon un druide a trois
specialisations, calibrage d avant Legion.
L imposition de la specialisation passe par Player::ActivateTalentGroup, sur son
propre tick du re-level. Une premiere tentative ecrivait
PLAYER_FIELD_CURRENT_SPEC_ID a la main pendant que stats et auras etaient
recalculees, et provoquait un debordement de pile.
Verifie en conditions reelles, assaut a 50 bots : apparition de guerriers
Protection et de druides Gardien en tank, de chamans Restauration en soigneur,
sept talents par bot et par specialisation, aucun plantage, progression 29 a 30
sur 30.
Reste a affiner : le quota de soigneurs n est pas toujours atteint faute de
comptes disponibles dans les classes soignantes au moment du recrutement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trois defauts distincts, tous verifies en jeu par sondes temporaires puis par
comparaison des positions en base.
1. L ordre « stop » n arretait rien. Le suivi est un generateur MoveFollow pose
sur le MotionMaster ; ClearMovement() se contente d appeler StopMoving() et
le generateur, toujours en tete de pile, relançait la poursuite au tick
suivant. ProcessStopCommand vide desormais la pile de mouvement.
2. Le teleport d un bot aboutissait cote serveur - positions identiques en base
apres un « summon » - mais les clients continuaient de l afficher a son
ancienne place : l etape finale diffuse un paquet portant un opcode CLIENT
(CMSG_MOVE_FALL_LAND) que les clients voisins ne savent pas lire. L objet est
maintenant reconstruit chez les joueurs alentour, et le MotionMaster vide a
chaque acquittement, comme le fait mod-playerbots dans HandleTeleportAck.
3. Cote module, l invocation posait un TeleportTo direct : meme cause, meme
effet, le mercenaire semblait n arriver jamais au portail. Elle passe
desormais par l ordre « summon » de l IA de groupe, au tick qui suit l entree
dans le groupe - le temps que l IA reconnaisse son maitre.
Enfin, FindCandidate retournait le premier compte bot eligible d une carte
ordonnee par identifiant : c etait invariablement le meme mercenaire. Tous les
candidats sont desormais collectes puis tires au sort, en ligne comme hors
ligne, un seul personnage par compte pour ne pas biaiser le tirage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le core ne savait que monter, jamais descendre : TryUpMount() sortait des la
premiere ligne si l aura de monture etait deja posee, et rien n appelait
Dismount() hors lancement de sort. Un mercenaire recrute alors qu il galopait
sur le terrain restait donc en selle indefiniment, y compris derriere un maitre
a pied.
UpdateMountState() remplace TryUpMount() dans le tick et traite les trois cas :
maitre a pied, le bot descend (RemoveAurasByType, la monture portee pouvant
venir de l IA de terrain et ne pas etre m_UseMountID) ; maitre monte au sol,
monture terrestre ; maitre en vol, monture volante.
Le vol passe par BotAIFly::UpdateFly, qui etait neutralisee par un return sec en
tete de corps. Elle est retablie : c est le seul code qui fasse suivre un bot en
trois dimensions, et BotGroupAI est son unique appelant - aucun autre mode d IA
n est touche.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le core sait deja piloter les bots de groupe (BotGroupAI::ProcessBotCommand) :
ordres ecrits dans le canal de groupe par le chef, ou chuchotes a un mercenaire
precis. Rien de tout cela n etait documente en jeu.
Le portail gagne un sous-menu en quatre rubriques - deplacement, combat,
ciblage par role ou par classe, equipement et specialisation - qui recense les
ordres existants en messages systeme, lesquels restent dans la fenetre de
discussion contrairement au texte d une boite de dialogue.
Aucune commande nouvelle : le portail enseigne, il n execute pas.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seuls les talents et les sorts suivaient la montee de niveau d un bot
(OnLevelupToBotAI : ReupdateTalents + LearnSpells). L equipement, lui, n etait
pose qu une fois, au re-level initial : un mercenaire embauche au niveau 20 et
monte a 25 gardait son stuff de niveau 20 pour tout le contrat et devenait de
plus en plus fragile.
Nouvelle methode PlayerBotSetting::RefreshEquipment() : reprend le seul bloc
equipement du re-level complet -- UnequipFromAll, CheckInventroy,
AddEquipFromAll, UpequipFromAll, SupplementOtherItems -- puis UpdateAllStats
et SaveToDB. On ne repasse volontairement ni par ResetTalents ni par
ActivateSpecialization : la reattribution de specialisation en cours de partie
est le chemin des crashs connus dans Unit::GetAPMultiplier.
ProcessDelayLevelup renvoie desormais false tant que le bot est en combat : le
schedule reste en tete de file et sera retente au tick suivant, plutot que de
desarmer le bot en pleine bagarre. RefreshEquipment reverifie de son cote.
Ce commit emporte aussi ActivateSpecialization (PlayerBotSetting), ecrit lors
d une session precedente, deployé depuis le 15/08 mais jamais commité.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Double liberation
-----------------
Group::Disband() declenche sScriptMgr->OnGroupDisband(this) en toute premiere
instruction et se termine par sGroupMgr->RemoveGroup(this); delete this;
MercenaryMgr::OnGroupDisband congediait aussitot, donc ReleaseBot appelait
bot->RemoveFromGroup(), donc Group::RemoveMember, qui disband le groupe des
qu il repasse sous deux membres : un second Disband() imbrique faisait
delete this, puis le Disband() exterieur reprenait la main sur un objet
libere et le liberait une seconde fois. Le garde-fou m_releasing ne protegeait
que nos propres hooks, pas la reentrance du core.
Le tas s en trouvait corrompu et le serveur tombait bien plus tard, dans un
malloc sans rapport (Object::_InitValues sur un chargement de grille). Piege
pose avec MALLOC_CONF=junk:true,redzone:true,quarantine:...,abort:true, qui a
signale le bloc passe deux fois par le chemin de liberation.
Les deux hooks de groupe se contentent desormais de marquer les contrats
(pendingRelease) ; Update() les libere au tick suivant, hors de la pile
d appel du core.
Balayage d inactivite
---------------------
PlayerBotMgr::UpdateIdleBotLogout exemptait les bots du siege des capitales
mais pas les mercenaires : un bot loue, immobile aupres de son employeur,
etait juge inactif et deconnecte au bout de pbotbg_idlelogout secondes.
Exemption ajoutee via MercenaryMgr::IsAccountHired().
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Creature::SaveToDB et GameObject::SaveToDB passaient directement
data.spawnDifficulties a StringJoin, qui serialise avec un flux. Or
`enum Difficulty` a pour type sous-jacent uint8 : le flux ecrivait donc le
*caractere* brut au lieu du nombre. Une difficulte 0, celle du monde ouvert,
donnait un octet NUL.
Au chargement suivant la colonne etait illisible et ObjectMgr rejetait le
spawn -- "not spawned in any difficulty, skipped". Tout PNJ pose en jeu
tenait donc jusqu au redemarrage, puis disparaissait. 46 lignes etaient
concernees en base, dont les 42 Portails d Invocation de Mercenaire.
Conversion en uint32 avant la jointure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CharTitles.db2 (7.3.5) ne contient aucun titre « Mercenaire » : 364 entrees,
ID max 522, MaskID max 373. On cree donc l entree custom 600 / MaskID 380
dans la table `char_titles` de la base hotfix, poussee au client par une
ligne `hotfix_data` (TableHash CharTitles = 0x85DF9E8E).
PlayerBotMgr::ApplyBotTitle() accorde puis selectionne ce titre a chaque
connexion de bot, depuis OnPlayerBotLogin(). Un bot ne peut donc pas s en
defaire, et les vrais joueurs les reconnaissent d un coup d oeil.
Cle de configuration pbottitle (600 par defaut, 0 = aucun titre force).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le Portail d Invocation de Mercenaire (creature 1000010) loue au joueur la
compagnie d un playerbot contre 100 pieces d or, dans le role achete (tank,
soigneur ou combattant) et au niveau de son employeur.
Le contrat est volontairement fragile : quitter le groupe, dissoudre le groupe,
expulser le mercenaire ou se deconnecter le renvoie hors du monde sur-le-champ,
et l invocation suivante se repaie. Un filet de securite dans Update() rattrape
les ruptures que les hooks n auraient pas vues.
Aucun fichier du core n est modifie : tout passe par GroupScript::OnRemoveMember
et OnDisband, PlayerScript::OnLogout et WorldScript. Seul ajout exterieur, un
accesseur CapitalSiegeMgr::IsAccountEngaged() pour ne pas debaucher un bot deja
enrole dans l assaut quotidien.
Plafond a quatre mercenaires : un groupe compte cinq places, employeur inclus.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PlayerBotSetting::LearnTalents() etait un corps vide alors que l etape 1 du
re-level appelle ResetTalents(true). Les bots repartaient donc au combat sans
un seul talent : sept rangs manquants a 110, soit une part importante de la
rotation de chaque classe. Constate en base avant correction, zero ligne de
character_talent pour huit classes sur neuf.
La fonction apprend desormais un talent par rang ouvert par le niveau, tire au
hasard parmi les colonnes que la specialisation du personnage autorise.
Deuxieme correction, dans ProcessSetting : le raccourci qui evite un re-level
inutile ne se declenche plus que si le bot possede reellement ses talents. Sans
ce controle, un bot deja au bon niveau sautait tout le reglage et restait a zero
talent, heritage de l epoque ou LearnTalents ne faisait rien.
Une premiere version de LearnTalents faisait aussi basculer la specialisation
en cours de re-level, par SetPrimarySpecialization et ecriture directe de
PLAYER_FIELD_CURRENT_SPEC_ID, hors du chemin officiel ActivateTalentGroup. Elle
provoquait un debordement de pile : cinq segfaults et quatre redemarrages du
worldserver en douze minutes. Ce volet est retire, la specialisation n est plus
touchee. La composition par roles qui en dependait est reportee.
Verifie apres deploiement : un bot seul puis cinquante, sept talents chacun sur
les neuf classes, aucun plantage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PlayerBotSetting::LearnSpells() n apprenait les sorts que depuis les donnees de
dresseur de classe (GetNpcTrainerSpells). En 7.3.5 les dresseurs n enseignent
plus le kit moderne : il s octroie a la montee de niveau et via la
specialisation. Les bots re-leveles arrivaient donc avec stuff et talents mais
un livre de sorts incomplet.
LearnDefaultSkills(), LearnSpecializationSpells() et
UpdateSkillsToMaxSkillsForLevel() sont desormais appeles avant le passage par
les dresseurs. Mesure avant / apres sur les bots 110 du siege, nombre moyen de
sorts connus :
guerrier 43 -> 56 paladin 43 -> 51 chasseur 44 -> 55
voleur 44 -> 63 pretre 44 -> 56 chaman 44 -> 56
mage 44 -> 54 druide 44 -> 56
Concerne aussi le remplissage des champs de bataille, qui re-level par le meme
chemin.
Deuxieme correction : BotBGAIMovement::IsNearToPosition() repondait toujours
pas encore arrive hors champ de bataille. Les appelants ne coupaient donc
jamais court et relancaient un calcul de chemin a chaque tick, d ou le flot de
messages de pathfinding en echec pendant le siege. Le mode siege passe
desormais cette garde.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SylvaniaCore deploy