Nalorakk restait plante au-dessus de son escalier apres la deuxieme vague. Le
trajet entre deux paliers grimpe une structure VMAP (le terrain, lui, reste a
z=12,5 sur toute la rampe) ; quand le calcul de chemin cale, le boss s arrete
en route et, comme il attend d etre arrive pour enchainer, l evenement ne
repart plus. Chaque deplacement est desormais borne a vingt secondes, au-dela
le boss est pose d office sur l etape.
Alysrazor finissait toujours dans la lave : la ramener dans JustDied arrivait
trop tard, la chute etait engagee, et MoveFall vise le terrain (z=48) en
traversant la plateforme, qui n est qu une structure VMAP a 55,5. Elle est
maintenant posee au centre de l arene AVANT le coup fatal, via DamageTaken, et
plus aucune chute n est declenchee.
Rhyolith restait bloque en premiere forme a un point de vie. Son UpdateAI
sortait sur UpdateVictim avant d avoir teste la bascule en phase 2 -- or les
joueurs frappent les pieds et non le colosse, qui se retrouve sans cible. Le
passage de phase est teste en premier.
Ecrit d apres AzerothCore, qui tient la meilleure version de ce contenu BC :
le boss attend au pied de la rampe, jette sur les joueurs le groupe de trolls
pose autour de lui, ATTEND QUE LA VAGUE SOIT MORTE, puis recule d un palier en
lancant Make way for da Nalorakk!. Il n est attaquable qu apres la quatrieme.
Composition des vagues reprise telle quelle (lanceurs de hache et hommes de
tribu, puis avec le medecin, puis les porte-guerre, enfin porte-guerre et
medecin a 25 m) : nos spawns correspondent deja exactement a ces groupes le
long de la rampe. Les deplacements passent par des positions en dur, ce core
n ayant ni spawn groups ni chemins de waypoints.
Deux pieges evites : notre spawn est pose a la position FINALE du boss, il est
donc ramene au pied de la rampe au depart ; et l evenement ne se rejoue jamais
apres coup, avec une sortie de secours si un joueur arrive au contact -- une
immunite d introduction qui ne se leve pas rend un boss definitivement intuable.
La numerotation des textes est celle de NOTRE creature_text, verifiee ligne a
ligne : le groupe 10 est le cri de repli, pas le retour en forme de troll.
Signalement Discord : impossible d obtenir la monture du chrono, et Nalorakk
ne fait rien.
Captifs : l instance tenait deja le chrono (15 minutes, +5 aux deux premiers
boss) mais les quatre case de SetBossState etaient vides. SummonHostage n avait
jamais ete porte : la course allait jusqu au bout sans que personne apparaisse.
Tanzar, Harkor, Ashli et Kraz sont desormais invoques a la mort de leur boss,
et un script leur fait remettre leur coffre quand on leur parle (les quatre
coffres et leurs tables de butin etaient deja en base, seul le script manquait).
Nalorakk : sa coquille de script ne contenait aucun sort. Combat ecrit d apres
l amont en gardant notre numerotation de creature_text : les deux formes qui
alternent toutes les 45 s, leurs sorts respectifs et la frenesie a 10 minutes.
Les quatre vagues de trolls de la rampe ne sont pas portees : l amont les pilote
par des spawn groups et des chemins de waypoints que ce core n a pas.
Trois signalements Discord du meme joueur.
Coffres : WorldObject::SummonGameObject rattachait TOUT objet invoque a son
invocateur. Les objets rattaches sont detruits avec lui (RemoveAllGameObjects
au retrait du monde), donc le coffre d un boss disparaissait cote serveur des
que le cadavre s effacait : le raid voyait encore le coffre mais ne pouvait
plus l ouvrir. Cas signale : le Coffre du seigneur du feu de Ragnaros, mais
tous les boss qui invoquent leur coffre etaient concernes. Les coffres ne sont
plus rattaches.
Alysrazor : elle meurt en vol et JustDied enchainait directement sur MoveFall.
Au-dessus du vide entre les plateformes, la depouille finissait dans la lave,
butin compris. Elle est ramenee au centre de l arene avant la chute.
Oondasta : l intro pose UNIT_FLAG_IMMUNE_TO_PC et seul l evenement de fin la
retire. Reset() reposait ce drapeau et effacait les evenements d intro a chaque
evade, sans garantie de rejouer l intro : le boss frappait les joueurs sans
qu ils puissent riposter. Le drapeau n est plus repose apres coup, il est leve
des l entree en combat, et _introEnd est enfin initialise (il ne l etait pas).
Signalement Discord : entrer dans la Prison violette fait planter le serveur.
Trois SIGSEGV cette nuit, pile identique : ASSERT_NOTNULL sur GetItemTemplate
dans Group::GroupLoot, appele depuis HandleLootOpcode.
Dans les tables de butin de ce core, un Item negatif designe une devise
(LootMgr.cpp:151). Loot::AddItem les range dans le meme tableau que les objets
mais sans modele d objet. Group::GroupLoot parcourait ce tableau et exigeait un
modele pour chaque entree : la premiere devise rencontree tuait le processus.
24 creatures sont concernees, dont cinq boss de l Assaut sur la Prison violette
(Blood-Princess Thal ena, Sael orn, Lord Malgath, Festerface, Taldath).
Les devises sont desormais ignorees par le tirage au sort, et un objet
introuvable est journalise puis saute au lieu de faire tomber le serveur.
Un PNJ qui porte le drapeau donneur de quete sans le drapeau papotage recoit
CMSG_QUESTGIVER_HELLO et non CMSG_GOSSIP_HELLO. Seul le handler du papotage
appelait TalkedToCreature : tous les objectifs de type TALKTO vises sur ce
genre de PNJ (19 objectifs en base, dont Sergent Grimjaw pour la quete du fief
Nouvelles marchandises) ne se validaient jamais.
1. La re-resolution des sorts passait par une file qui la jetait.
Le correctif 19c0cf03 poussait un BGSType_DelayLevelup apres la creation
de l IA de groupe. Mesure sur quatre mercenaires : deux repares, deux
non. En cause PushScheduleToQueue, qui jette silencieusement une tache
si une du meme type est deja en file, et -- pour ce type precisement --
si IsSettingFinish() est faux. La reparation ne partait qu au hasard.
On appelle desormais OnLevelupToBotAI() directement. L IA de groupe
vient d etre creee : le dynamic_cast qui l ouvre aboutit forcement.
2. Le raccourci de mise en place renvoyait des mercenaires nus.
Signale en jeu : « Kaerbrus n a meme pas d equipement ». Constate en
base : niveau 110, 76 sorts, zero piece portee.
ProcessSetting court-circuite le re-level d un bot deja au bon niveau,
avec ses talents et la bonne specialisation -- et saute du meme coup les
etapes d habillage. Un bot ayant perdu son equipement ne le retrouvait
jamais : a chaque embauche le raccourci concluait que tout allait bien.
On verifie donc qu il porte au moins dix pieces avant de couper.
3. Le rappel n intervenait qu au-dela de 160 metres.
Mesure : au moment d un « !attack », deux des quatre mercenaires se
trouvaient a 100 et 106 metres de leur employeur. Sous le seuil de
rappel, ils acceptaient l ordre et partaient A PIED -- une quinzaine de
secondes de marche, le combat fini avant leur arrivee. Vu du joueur, le
mercenaire « refuse d attaquer ».
Ce seuil convient a un bot de terrain, pas a un membre de groupe. Ramene
a deux fois la portee de recherche, soit 64 metres : bien au-dela des 32
ou l IA engage et des 28 de portee des sorts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Salles des Valeureux (1477) : Hyrja, le Roi-dieu Skovald et Odyn n existaient
dans aucune ligne de creature. Le donjon etait bloque bien avant le butin :
les portes GOB_DOOR_ODYN_PASSAGE et GOB_DOOR_ODYN_BRIDGE sont des passages
commandes par DATA_HYRJA, qui restait donc NOT_STARTED pour toujours - la
moitie arriere du donjon etait inaccessible. Apparitions ajoutees pour Hyrja,
Olmyr, Solsten, Skovald et Odyn ; Odyn n avait pas de table de butin, il est
branche sur sa rencontre du Guide d aventure (1489).
Auchindoun : Azzakel n etait pas un boss absent mais un boss jamais invoque.
Le controleur qui l invoque est Claws of Argus (76216) apres la mort de six
Cackling Pyromaniac ; or la mort de ces derniers envoyait le compteur a la
creature 87218, un simple marqueur de position sans IA - l action tombait
dans le vide. Le compteur passe desormais par les donnees d instance
(DataTriggerAzzakelController). Corrige au passage une condition inversee
dans l invocation (if (!m_Azzakel) au lieu de if (!m_Azzakel.IsEmpty())),
qui empechait Azzakel de devenir hostile et de charger la plateforme.
Signalement Discord : les instances haut niveau ne lachent aucun equipement.
Sur ce core, le butin d equipement des boss modernes ne vient pas de
creature_loot_template mais de Unit::Kill, qui lit creature_template_journal
(entree -> JournalEncounterID) puis tire 2 objets dans JournalEncounterItem.db2
avec le bon masque de difficulte et le bon contexte d objet. Cette table ne
contenait que 45 lignes, toutes Burning Crusade : aucun boss de Draenor ni de
Legion, et ces boss ont lootid = 0. Ils ne lachaient donc rigoureusement rien.
44 correspondances ajoutees, etablies depuis les DB2 officiels du client
(JournalInstance -> JournalEncounter -> JournalEncounterCreature ->
CreatureDisplayInfoID -> creature_template.modelid), une seule creature par
rencontre et uniquement celles sans table de butin, pour ne rien doubler.
Couvre entre autres la Fonderie des Rochenoire (10 boss), les Docks de fer,
Haut-perchoir, le Pic Rochenoire, la Floraison eternelle, le Siege du
Triumvirat (4 boss), le Tombeau de Sargeras (6), Gul dan et Elisande.
Les scripts de generation et de verification sont dans chantiers/butin-journal.
Signalement Discord : la quete 31589 (Panser ses plaies) est impossible a
valider, un clic sur Murog ouvre directement la boutique.
Donnees (sql/sylvania/battlepet_stablemaster_heal.sql) :
- Murog (47764) et Jaelysia (10085) n avaient aucun gossip_menu_id : ils
retombaient sur le menu 0, dont la seule option compatible pour un
non-chasseur est le vendeur, que le client selectionne automatiquement.
- le menu 9821 des maitres d ecurie avait perdu ses options vendeur et
ecurie : seule restait l option de soin.
- 10 des 12 maitres d ecurie de la chaine On The Mend n avaient pas le
SmartAI qui soigne les mascottes et donne le credit de quete.
- le credit de Jenova Stoneshield pointait sur Elwynn (64320) au lieu de
Hurlevent (65214).
Core :
- CRITERIA_TYPE_BATTLEPET_WIN, _LEVEL_UP et CAPTURE_PET_IN_BATTLE etaient
dans la liste non implemente : le systeme de combat de mascottes
remontait bien les evenements, le gestionnaire de criteres les jetait.
- l ordre des miscValue de _LEVEL_UP ne correspondait pas a ce qu attendent
les conditions (espece en miscValue1, niveau en miscValue2).
Signale en jeu : les mercenaires n utilisent presque aucune de leurs
capacites.
Chaque IA de classe resout ses poignees de sorts UNE seule fois, a sa
construction, par FindMaxRankSpellByExist. Ce qui n est pas connu du
personnage a cet instant renvoie zero et reste eteint pour toute la vie
du bot, chaque usage etant garde par un « if (poignee) ».
Mesure a la sonde, le 09/09/2026, sur une escorte de quatre mercenaires
tous montes au niveau 110 : l IA avait resolu ses sorts au niveau 1 pour
l un d eux, au niveau 100 pour deux autres. Le quatrieme, re-resolu par
hasard a 110 parce qu il avait gagne un niveau pendant que son IA
existait deja, n avait plus que quatre capacites indisponibles -- et
toutes les quatre appartenaient a une autre specialisation, donc
parfaitement normales.
Les tables de sorts ne sont donc pas en cause, contrairement a ce que
laissait croire un premier releve : c est un probleme d ordre.
Le core prevoyait la reparation. Quand la mise en place s acheve,
PlayerBotSetting pousse un BGSType_DelayLevelup qui reapprend les sorts
et rappelle InitializeSpells. Mais OnLevelupToBotAI() commence par un
dynamic_cast<BotGroupAI*> et ne fait rien tant que l IA de groupe n
existe pas -- or le module ne la cree qu ensuite. La tache partait avant
sa cible et tombait dans le vide.
On en repousse donc une juste apres SwitchPlayerBotAI, quand l IA existe.
Elle attend que le bot soit hors combat avant d agir, le rehabillage
complet faisant partie du meme passage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signale en jeu : « quatre mercenaires contre un gangreseigneur elite,
ils meurent tous, alors que seul j y arrive ».
Solocraft divise la difficulte brute par le nombre de membres presents,
pour compenser l absence de joueurs. CountPlayersInInstance comptait les
playerbots comme des joueurs entiers : un employeur accompagne de quatre
mercenaires passait de x5 a x1, c est-a-dire d un bonus de 400 % a aucun
bonus du tout.
Or un mercenaire ne remplace pas un joueur. Sa couche de combat est
restee en identifiants de sorts WotLK -- mesure faite sur trois classes,
entre cinq et six sorts reellement lancables sur une quarantaine cites
par l IA. Il ne compensait donc rien de ce qu il faisait perdre, et
l escorte etait strictement perdante : un piege pour le joueur plutot
qu un arbitrage tactique.
Les playerbots sont desormais ignores dans le compte. Un groupe
entierement compose de bots retombe sur 1 et recoit le meme bonus qu un
joueur seul, ce qui reste coherent : personne de reel n est la pour
porter le contenu.
Supprime au passage une oscillation du buff -- chaque mercenaire qui
debarquait faisait recalculer et fondre le bonus d un cran, d ou les
cycles de retrait/reapplication visibles dans le journal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signale en jeu : sur une escorte de quatre, un compagnon restait a
l autre bout de la carte pour toute la duree du contrat.
L ordre de rappel -- ProcessBotCommand("!summon"), ou TeleportToPoint
quand un portail est connu -- partait une seule fois, et le contrat le
tenait aussitot pour honore : summonPending passait a false sans que
rien ne verifie que le mercenaire avait bouge. Un ordre perdu, et le
bot restait a la position ou il s etait connecte.
Le contrat retient maintenant ses tentatives et verifie l arrivee au
point de rendez-vous -- le portail s il y en a un, l employeur sinon.
Tant que le mercenaire n y est pas, l ordre est renouvele, jusqu a
quatre fois, avec trois secondes entre deux verifications : un teleport
de bot se joue en trois echanges et conclure au tick suivant reviendrait
a le declarer perdu alors qu il est en route.
Passe ce delai, on cesse d insister et on le dit au joueur, plutot que
de le laisser croire son groupe au complet.
Repare aussi le message de journal du recrutement offert, dont le format
avait ete abime lors de sa pose.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Retirees a tort le 07/09/2026. Je les avais supposees responsables du joueur qui
passe sous la map en cliquant les pierres de la quete 34392.
Verifie en jeu depuis : jouer 961 seule ne produit que la replique de Cho gall,
texte et audio, sans deplacement ni cinematique. Elles etaient inoffensives, et
leur retrait supprimait la replique qui indique au joueur d aller chercher
Gul dan.
A ne pas confondre avec les scenes du bateau 953 et 986, elles bel et bien
relocalisantes : jouer 953 deplace le joueur et declenche son teleport vers
Draenor. Leur retrait dans tanaan_intro_finale.cpp reste justifie.
La cause du passage sous la map sur les marques reste inconnue. Seul candidat
restant : le retrait de la phase 175 par RemoveAurasDueToSpell.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Faction 14 alors qu il porte le drapeau de dialogue : aucun joueur ne pouvait
lui parler. Meme classe d erreur que Khadgar 78288, trouvee par le meme signal
d incoherence interne : sur les 8 entrees Ken-Ken de la base, six sont en
faction 35 et celle-ci etait la seule en 14. Wowhead le donne amical envers
l Alliance et la Horde.
Deux spawns concernes, foret de Jade.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signalement : un personnage Alliance debarquant a Crete-de-Gel se fait attaquer
par trois PNJ. Deux sont conformes, Thrall et Farseer Drek Thar sont des chefs de
la Horde et Wowhead les donne hostiles a l Alliance. Le troisieme non.
Khadgar est neutre dans tout Draenor, il sert les deux factions. Wowhead donne
cette entree amicale envers les deux camps, et notre propre base le confirme :
sur 150 entrees Archmage Khadgar, 100 sont en faction 35 et 78288 etait la seule
en faction 83. Deux spawns concernes, tous deux en zone 6720.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
81 betes spawnees avaient skinloot = 0. Relevees sur l onglet skinning de
Wowhead, distinct de celui des butins, avec controle du statut HTTP et du
marqueur g_npcs. Aucun refus rencontre.
67 n ont aucun onglet depecage sur Wowhead : oiseaux, insectes, gasteropodes,
araignees. Verifie a la main sur cinq d entre elles, l absence est reelle.
Elles ne sont pas touchees. Restent 14 betes, 66 lignes.
Methode validee AVANT collecte sur un temoin dont la table existait deja
(90134 Llothien Grizzly) : memes objets, memes intervalles de pile, ecarts de
taux sous le bruit. Sans ce temoin le relevé aurait rendu zero partout : l
onglet skinning n est pas du JSON strict comme celui des butins, ses cles sont
non quotees et une espace precede outof.
Controle : 11 479 lignes chargees pour 11 479 en base, aucun rejet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reparation et non suppression : ces lignes portaient du butin reel, rendu
inoperant par deux defauts d import distincts.
62 lignes a chance negative sur 35 creatures : signe inverse a l import. Les
memes objets figurent ailleurs dans la table avec la meme valeur en positif
(69815 entre 50 et 100, 71141 entre 75 et 100). Valeur absolue retablie.
80 lignes a chance nulle sans GroupId sur 6 boss de points d invasion majeurs
d Argus : encodage classique d un groupe equiprobable dont le GroupId manquait,
donc tout etait rejete et ces boss ne lachaient rien. Verifie sur Wowhead,
Mistress Alluradel liste exactement les 14 memes objets que nous.
Resultat : 932 578 lignes chargees sur 932 578 en base, plus aucun rejet.
41 creatures retrouvent leur butin.
Quete 41039 : son objet 133995 Recette du breuvage des tempetes existe dans
Item.db2 mais pas dans ItemSparse.db2, or le core exige les deux. Verifie par le
serveur lui-meme : 104 011 ItemTemplate charges pour 103 967 enregistrements
ItemSparse, donc le fichier est lu en entier. Cree par hotfix DB2 (table miroir +
hotfix_data, TableHash 0x919BE54E) et HotfixCacheVersion passe de 1 a 2.
Quete 46765 : objet 147430 absent de toute table de butin. 199 lacheurs listes
par Wowhead, 58 spawnes chez nous, 49 lachent effectivement l objet. Taux releves
sur les fiches PNJ, QuestRequired = 1.
Reliquat des 67 especes : 53 n ont aucune donnee Wowhead, 11 n ont que des objets
post-Legion. Restaient 3 cas reels, tous traites : 102852 par le hotfix, 100231
par la Meteorite gangrenee, 113198 par une table de depecage.
Trois objectifs de quete (quest_objectives Type 1) n existaient dans aucune table
de butin du serveur : 142079, 144362, 147396. Poses avec QuestRequired = 1.
Taux repris de la fiche PNJ de Wowhead et non de la fiche objet : les deux
divergent (Gemme pulsatile a 19,66 pour cent cote objet contre 82 cote PNJ),
et c est la fiche PNJ qui est juste, verifiee a l ecran.
Les trois quetes sont des quetes MONDIALES (QuestType 3, QuestInfoID 109) : sans
donneur par construction, leur disponibilite depend du systeme de quetes mondiales.
41039 Un savoir vole non traitee : seule quete classique du lot, donc la seule
reellement bloquee, mais son objet 133995 n existe pas dans ItemSparse. Le serveur
rejette la ligne au chargement. Demande un DB2 custom par hotfix.
Filtre affine par HealthModifier >= 1, qui ecarte decors et critters.
102 especes hostiles a lootid = 0 relevees sur Wowhead, statut HTTP et marqueur
g_npcs controles.
Wowhead agrege le jeu moderne : 3727 lignes brutes, 235 retenues apres trois
filtres. Ecartes : objets absents de notre Item.db2, taux sous 1 pour cent, et
objets jamais utilises comme butin de cadavre chez nous. Ce dernier ecarte les
materiaux a dominante depecage (124113 Cuir de rochepeau : 19 usages en butin
contre 284 en depecage) et les objets de quete qui exigeraient QuestRequired.
Objet dominant : 124437 Soie shal dorei a environ 50 pour cent sur les
humanoides, equivalent Legion des Fragments d armure abimes du Draenor.
Les 245 especes hostiles a lootid = 0 de la carte 1116 relevees une par une sur
Wowhead. 222 n ont effectivement aucun butin sur les royaumes officiels non plus :
decors, critters, PNJ scenarises, envahisseurs de fief. 8 autres n ont que des
objets post-Legion, absents de notre Item.db2. Restent 15 especes, 65 lignes.
Le chiffre de 21 pour cent de mobs hostiles sans butin annonce plus tot etait
trompeur : le filtre laissait passer des objets de decor classes humanoides ou
betes en base (Renfort de fer, 294 spawns, Champignon gorge...).
Le releve controle desormais le statut HTTP 200 et le marqueur g_npcs : sans ca
une page de refus 403 se lit exactement comme un PNJ sans butin. 8 refus
rencontres et rattrapes sur cette passe.
Signalement joueur du 05/09. 26 especes hostiles des Terres foudroyees 6.0 et de
Tanaan avaient lootid = 0, alors que leurs voisines immediates avaient leur table.
Taux releves un par un sur Wowhead. 9 des 26 n ont legitimement aucun butin la-bas
non plus et ne sont pas touchees : ame tourmentee, demolisseur, Keli dan, Ankova...
Les objets post-Legion listes par Wowhead (ids 235xxx et 236xxx) sont ecartes.
Profil dominant de la Marche-de-Fer : 112463 a 75-99 pour cent, 112684 a 29-41,
118675 a 0,2-0,4.
Les deux points d entree ne se declenchent que si le joueur n a PAS encore de
fief : l objet Master Surveyor (233664, Horde) et Baros Alexston (79243,
Alliance). Une fois le fief fonde, plus rien n y ramenait. Les trois joueurs du
royaume qui en possedent un ne sont jamais alles dessus : aucun personnage n a
jamais ete sur les cartes 1152, 1153, 1158, 1159, 1330 ni 1331.
Gazlowe (78466) et Baros proposent desormais "Emmenez-moi a mon fief" aux
proprietaires. L option est masquee quand on est deja sur une carte de fief,
Gazlowe y etant aussi spawne. Le declencheur de proximite cote Horde n est pas
touche : il aurait teleporte tout passant.
TeleportOwnerAndPlayMovie renomme TeleportOwnerToGarrison, l ancien nom mentait
depuis le retrait du film.
Signalement joueur du 05/09 : la cinematique du fief bloque le jeu, il faut se
reconnecter pour continuer.
Le film (189 Horde / 192 Alliance au niveau 1) etait envoye par SendMovieStart,
et le teleport dans le fief etait accroche a CMSG_COMPLETE_MOVIE. Un client qui
ne joue pas le film ne renvoie jamais ce paquet : le joueur restait bloque ET
n arrivait jamais dans son fief. On teleporte donc directement.
Meme demarche que pour les scenes 953 / 986 et 961 / 962 : la cause du gel cote
client reste inconnue, on supprime le declencheur pour ne plus bloquer la
progression. Le commentaire indique quoi remettre le jour ou on saura.
Signalements joueur du 05/09.
Scenes 953 / 986 (bateau) : rendre "La derniere ligne droite" faisait planter le
client. La scene est ecrite pour se jouer sur un transport en mouvement, alors que
PlaySceneByPackageId l envoie ancree sur la position du joueur, TransportGUID vide
et SceneID nul. On fait desormais directement le teleport et le succes que son
declencheur "Teleport" produisait.
Scenes 961 / 962 (marques de Tanaan) : cliquer une des deux pierres de la quete
34392 envoyait le joueur sous la map. Rien d autre sur ce chemin ne deplace le
joueur (le sort du goober est un simple KILL_CREDIT, aucun hook de scene mal
filtre, les marques sont au niveau du sol), et l ecart entre ancrer sur l objet
ou sur le joueur est de deux metres : c est la scene elle-meme. Elle est
decorative, le credit de quete est donne avant.
Scout Pazaztick (85249) et son telescope (234619) ne sont spawnes nulle part.
Les joueurs Horde tombaient donc sur la paire Alliance : telescope inutilisable
(il ne valide que la quete 36379) et Scout Pazerp, en faction 84, les agresse.
Faute de phasing sur la map 1190, le telescope existant sert desormais aux deux
factions, les deux eclaireuses passent en faction 35 et Pazaztick est spawnee.
SIGNALE EN JEU : « un petit groupe de demons m a valide les 33/33 et les
3/3 gangreseigneurs d un coup ». L exploitant a refuse mon explication --
« je ne vois pas en quoi c est une bonne nouvelle » -- et il avait
raison.
InstanceScript::DoSendEventScenario passait par DoUpdateCriteria, qui
diffuse a CHAQUE joueur de l instance. Or Player::UpdateCriteria
transmet ensuite au scenario :
if (Scenario* scenario = GetScenario())
scenario->UpdateCriteria(type, ...);
et ce compteur est PARTAGE par toute l instance. Chaque mort etait donc
comptee autant de fois qu il y avait de joueurs presents. Avec une
escorte de quatre mercenaires, sept demons suffisaient a remplir un
objectif qui en demande trente-trois.
Le defaut restait invisible tant qu on jouait seul : un joueur, un
credit. L escorte l a mis au jour. Il touche tous les scenarios du
serveur, pas seulement le Rivage brise.
L evenement credite desormais le scenario une seule fois, avec un joueur
de reference pour les conditions qui en dependent.
HAUT FAIT JCJ HORS SUJET. « J ai attaque un petit groupe de demons et
j ai recu le haut fait Courroux de l Alliance », qui demande de tuer
cinq joueurs de la Horde dans chaque grande ville.
KillRewarder::Reward creditait CRITERIA_TYPE_SPECIAL_PVP_KILL a chaque
membre du groupe pour n importe quelle mort, creatures comprises. Meme
mecanisme d apparition : ce bloc n est parcouru qu en groupe.
TrinityCore ne fait pas cette mise a jour du tout, ni en 3.3.5 ni en
master -- c est un ajout local, pose sans le garde-fou _isPvP que ce
fichier emploie partout ailleurs. Il est ajoute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SIGNALE EN JEU : « !summon repond "You can't teleport yourself to
yourself", et !follow repond "There is no such command" ».
ChatHandler::ParseCommands traite le point d'exclamation comme un
prefixe de commande au meme titre que le point :
if (text[0] != '!' && text[0] != '.')
return false;
Il intercepte donc tout ordre ligne 202 de HandleChat, bien avant que
le message n'atteigne le canal de groupe ou Group::ProcessGroupBotCommand
l'attend, ligne 405. « !summon » partait vers la commande de maitre de
jeu du meme nom, « !follow » vers une commande inexistante.
Le systeme d'ordres aux playerbots -- summon, attack, follow, flee,
stop, equipement, talents -- etait donc inaccessible depuis toujours.
Comme la formation de groupe corrigee juste avant, il etait ecrit,
complet, et jamais atteint.
Les messages en « ! » passent desormais aux compagnons lorsque le joueur
en commande effectivement. Un maitre de jeu sans bot garde ses commandes
en « ! » ; celui qui en a passe par le point, qui reste le prefixe
principal.
Corrige aussi : le journal des mercenaires annoncait « a paye 100 po »
pour les recrutements offerts. Rien n'etait preleve -- le garde-fou est
bien en place -- mais un journal qui raconte le contraire de ce qui
s'est passe fait perdre du temps au diagnostic suivant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SIGNALE EN JEU : « les bots restent les uns sur les autres, il n existe
pas des commandes de strategie de placement ? ». Le systeme existait
bien -- il etait casse.
GetPositionFromGroup calcule correctement une place propre a chaque
membre : un angle reparti sur le cercle, a quatre metres du meneur. Mais
son resultat n etait jamais renvoye :
Position resultPos(distX, distY, distZ, ...); // calculee
Position pos; // vide
pCenterPlayer->GetFirstCollisionPosition(...); // resultat jete
return pos; // (0,0,0)
GetFirstCollisionPosition REND une Position ; son retour etait ignore et
l on renvoyait une variable jamais renseignee. La fonction rendait donc
l origine du monde a tous ses appelants -- BotGroupAI comme BotAITool.
Par-dessus, les deux MoveFollow de BotGroupAI employaient la meme
distance et le meme angle pour tout le monde : un metre devant le
meneur, a son orientation. Meme reparee, la formation aurait ete ecrasee
deux lignes plus loin. Chaque bot y prend desormais l angle de son rang
dans le groupe, a trois ou quatre metres selon l effectif.
Le defaut ne touchait pas que le scenario : il vaut pour tous les
playerbots du serveur, champs de bataille et donjons compris.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'exploitant a fourni une seconde video, en 1080p et sans ecran partage,
qui montre le vrai depart cote Alliance. Elle a permis quatre
corrections.
L'EMBARQUEMENT. Le script d'Angelica deposait le joueur en
(443.8, 2076.1, 1.2), le point d'ancrage de la plage -- une coordonnee
inventee. Le sort officiel 199358 porte (441.2, 2023.75, 4.44) dans
spell_target_position, marque VerifiedBuild 27843 : le pont de
l'Alliance Battleship. On y teleporte desormais. La premiere etape
s'intitule « Rendez-vous au rivage Brise » et ne s'acheve qu'une fois
le joueur debarque, au lieu d'une minuterie de douze secondes qui
s'ecoulait pendant le chargement du client.
Sa condition exigeait par ailleurs que la quete 42740 soit EN COURS :
deja rendue ou pas encore prise, l'option restait muette. Elle accepte
maintenant les trois etats et explique le refus au lieu de ne rien
faire.
LES FACTIONS, et la resolution du paradoxe d'aout. On avait bascule les
demons de cette carte en faction 16 parce que la 2780 les rendait
inattaquables, sans comprendre pourquoi. Le prix etait invisible : la
faction 16 porte EnemyGroup = 1, elle n'est hostile QU'AUX JOUEURS. Nos
allies, eux, ont EnemyGroup = 0 et une liste d'ennemis qui designe la
faction 1786. Les deux camps ne se reconnaissaient pas -- d'ou les
soldats qui s'engagent puis n'ont personne a frapper, releve par la
sonde d'evasion : onze fois pour la garde royale gilneenne, dix pour
Jaina, dix pour Varian.
On avait repare le joueur en supprimant la bataille. Les 102 entrees
exclusives a la carte passent en 2898, qui porte la meme faction 1786
mais avec EnemyGroup = 15, hostile a tous. Verifie en jeu : attaquable.
L'ESCORTE. Le scenario officiel se joue en groupe constitue par la file
d'attente, que nous n'avons pas. A l'entree, une escorte est desormais
offerte : un protecteur, un guerisseur et deux combattants, via le
module des mercenaires. Un mode gratuit y est ajoute -- le contrat reste
identique, rupture au premier depart du groupe, mais sans prelevement.
Les invocations sont espacees d'une seconde et demie, faute de quoi
elles se superposaient au meme point.
LES DOUBLONS DE DISTRIBUTION. Quatrieme et cinquieme occurrences du meme
defaut : le script invoquait Genn, Jaina, Mekkatorque, l'escorte et
Arganoth alors que la carte les porte tous. Toutes les invocations de
l'introduction sont supprimees ; c'est Genn qui ouvre la scene cote
Alliance, Varian n'etant pas encore la -- ce qui est tout l'objet de
l'etape « Trouver Varian ».
Corrige aussi : Gul'dan Talk(1) n'existait pas, le script l'appelait
dans la finale et rien ne se jouait. 263 allies passent en arme
degainee, 131 recoivent un equipement recupere de la reference et la
posture EMOTE_STATE_READY1H.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SIGNALE EN JEU : « p7 Tirion reste muet, le script ne se lance plus,
mais Krosus est bien combattable ». Un seul defaut, deux symptomes.
La verification de proximite sortait SANS SE REPLANIFIER quand Tirion
n'etait pas encore charge -- sa zone se trouve a l'autre bout de la
carte, et la grille ne se peuple qu'a l'approche du joueur. Au premier
passage, deux secondes apres la fin de l'etape 6, il n'existait pas : la
tache mourait la, definitivement. D'ou Tirion muet, et d'ou Krosus
combattable, puisque c'est cette meme scene qui devait le figer.
Le meme Repeat existait deja dans la detection de Varian ; je ne l'avais
pas reporte ici.
« Varian a un dialogue audio au lancement de la campagne, il ne se
declenche pas. » StartIntro etait appele DANS OnPlayerEnter, pendant
l'ajout du joueur a la carte : le cri partait quand le client chargeait
encore la zone. Decale de quatre secondes. Corrige au passage le
demarrage direct en phase 2, meme cause -- les douze secondes de la
premiere phase s'ecoulaient avant l'arrivee effective.
« Tous les PNJ allies doivent porter leurs armes. » L'etat de fourreau
ne suffisait pas : il n'y avait rien a degainer. Sur les 51 entrees
alliees de la carte, seules QUATRE avaient un equipement defini.
Trente equipements recuperes du creature_equip_template de la
reference : 131 spawns sont desormais armes, contre 11.
Les 263 allies passent aussi en arme degainee, sans emote d'etat --
l'emote 27 demandee est celle du combat A MAINS NUES et aurait range
leurs armes. Sans emote forcee, le client joue l'attitude propre a
l'arme reellement portee, hache a deux mains comme epee courte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trois signalements en jeu, une cause commune pour deux d'entre eux.
« Il y a toujours ces vagues de demons qui m'attaquent, RETIRE-LES. »
Le script a ete ecrit quand la carte etait VIDE : il fabriquait ses
propres ennemis a la plage, chez le commandant, dans la cite et au
tombeau. Elle porte aujourd'hui 748 creatures posees, et toutes ces
invocations faisaient double emploi. Supprimees aux quatre endroits.
« La p9 vaincre Gul'dan se valide toute seule. » Meme origine : elle
s'achevait apres huit morts de demons, or le script en invoquait
lui-meme quatre au tombeau puis quatre autres vingt secondes plus tard.
Il declenchait sa propre condition de fin. L'etape se conclut desormais
au terme de la sequence de Gul'dan, une fois ses repliques prononcees.
« Le Krosus du lac de lave en p8 est inattaquable. » Il portait la
faction 2878 -- exactement le defaut resolu en aout pour les autres
demons de cette carte, ou 2780 et 1768 les rendaient inattaquables et
avaient toutes ete basculees en 16. La 2878 n'etait pas dans le lot,
personne n'etant jamais alle aussi loin dans le scenario. L'entree
90544 n'existe QUE sur la carte 1460, un seul exemplaire.
« Le scenario ne se declenche que si on saute dans la lave. » Tirion
agonise au bord du bassin a z=40, Krosus etant a z=35 : avec un rayon
de 25 metres, le seul point qui satisfaisait la condition etait la lave
elle-meme. Porte a 50.
Les poids de la barre de l'etape 6 montent d'un cran -- 5 pour les
demons ordinaires, 10 pour les elites -- la progression ayant ete
jugee trop lente en jeu. Avec 2 et 5, la cite plafonnait a 273 points
sur 300, ce qui expliquait aussi les vagues que j'avais ajoutees pour
compenser puis retirees.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SIGNALE EN JEU, trois points.
« Tu ne les as pas implementes au Tirion et Krosus qu il y avait de base
sur la map, tu en as ajoute. » Exact, et c est la meme faute que pour
Varian avant-hier. Les protagonistes de la crevasse SONT poses sur la
carte, mais sous d autres entrees que celles du script :
91951 Highlord Tirion Fordring (1495, 1751)
94276 Gul dan (1530, 1742)
90544 Krosus (1481, 1716)
90705 Dread Commander Arganoth ( 613, 2085)
Le script invoquait des sosies aux entrees 90367 et 90413, qui ne
figurent nulle part. OnCreatureCreate retient desormais les quatre, et
la scene de la mort de Tirion emploie ceux de la base -- Krosus n est
plus duplique, il est seulement rendu inerte le temps de la sequence.
« Ces invocations de demon, il faut arreter ca, a chaque fois que je me
bats ils reviennent en vague, c est affreux. » Supprimees. Elles etaient
une addition de ma part pour permettre a la barre d atteindre ses 300
points -- un pansement pose sur une deduction incertaine, qui rendait le
combat interminable. Si la barre plafonne, c est la correspondance des
poids qu il faudra revoir, pas le nombre d ennemis.
« Les voix qui marchent, Tirion Krosus et Gul dan, c est les seules. »
Confirmation du mecanisme : seules ces repliques portaient un
BroadcastTextId. Les autres sont nos textes inventes, avec un zero dans
ce champ, donc muettes par construction. Sept repliques de mise en scene
recoivent leur identifiant et leur son officiels -- le ralliement de
Varian et de Vol jin, la mort de Varian, Jaina, Sylvanas, et les deux
repliques finales de Gul dan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SIGNALE EN JEU : « p7 c'est Krosus qui plonge Tirion dans le fiel
normalement, et la pas de script de scenario ». Le script se contentait
d'invoquer Krosus douze secondes apres avoir pose Tirion agenouille.
La sequence officielle est relevee sur Warcraft Wiki, et ses huit
repliques existent dans nos donnees avec leur BroadcastTextId ET leur
Sound -- de 99237 a 99247. Elle est desormais jouee en trente-trois
secondes : Tirion comprend le piege, Gul'dan lui repond depuis le
tombeau, Krosus surgit de la lave, Gul'dan ordonne, Krosus souffle,
Tirion sombre, le chef de faction riposte, Gul'dan raille puis lance
l'assaut. Krosus n'est attaquable qu'a ce dernier signal.
Gul'dan est invoque des cette scene, au sommet du tombeau, et y reste
jusqu'a la fin -- c'est de la qu'il domine le champ de bataille. La
finale le reutilise au lieu d'en invoquer un second.
RENFORTS DE LA CITE : « en phase 6 j'ai des invocations de demon sur ma
tronche ». Ils naissaient au point de ralliement, c'est-a-dire au
milieu du combat. Ils arrivent desormais de la peripherie, sur un
cercle de 45 a 60 metres dont l'orientation change a chaque vague, puis
chargent.
Ces vagues restent une addition de ma part, pas une donnee du jeu : la
cite ne compte que 273 points de defenseurs pour une barre qui en
demande 300. Si la correspondance des poids se revele fausse, elles
n'auront plus lieu d'etre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Suite du parcours joue de bout en bout avec l'exploitant.
ETAPE 6, LA BARRE RESTAIT A 0 %. Son arbre 42770 porte l'operateur 9,
SUM_CHILDREN_WEIGHT : la barre vaut 300 points et chaque enfant y
contribue selon son poids -- 44384 vaut 1, 53062 vaut 2, 53063 vaut 5,
53064 vaut 10. Le script n'envoyait aucun des quatre : il comptait dix
morts dans son coin et forcait le passage, laissant la barre morte.
Les demons ordinaires alimentent desormais le poids 2, les elites le
poids 5, et des vagues affluent pour que la barre puisse se remplir --
la zone ne compte pas assez de defenseurs pour ses 300 points.
LES CAGES DE LA LEGION ne comptaient pour rien : aucun critere ne les
mentionne, et elles n'avaient aucun script. Signale en jeu, puis
confirme par l'observation (« la barre bouge de 1 % »). Elles portent
le quatrieme poids, le seul qui restait libre. Les 39 exemplaires sont
rattaches a go_legion_cage.
ETAPE 7, TIRION se validait par une minuterie de douze secondes, sans
le joueur, et disparaissait au bout de vingt -- impossible a atteindre
meme en courant. Meme defaut que « Trouver Varian ». Il faut desormais
le rejoindre, il reste en place, et Krosus n'apparait qu'ensuite.
ETAPES 8 ET 9 cablees dans la foulee : 44669 a la mort de Krosus,
44826 quand Gul'dan est arrete. Plus aucune etape ne se valide par
forcage.
DOUBLONS DE PLACEMENT : neuf creatures de la 1460 et trente-huit de la
1666 occupaient une position strictement identique a une autre, au
centimetre pres. L'import n'est pas en cause -- la reference les porte
deja en double, guids 294825 et 294827 pour l'entree 92564. Ecart
assume avec elle, au benefice du rendu.
RESERVE : la correspondance des quatre poids de l'etape 6 reste une
deduction. La cite ne contient que deux categories d'ennemis la ou les
poids en supposent quatre. A verifier en jeu, chiffres en main.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SIGNALE EN JEU : « tous les PNJ de la zone sont totalement inexpressifs,
ca n a pas d ame », et « tout est muet meme s il y a du textuel ».
Nos repliques portaient un BroadcastTextId a ZERO. Le serveur envoyait
donc du texte brut, que le client affiche sans rien avoir a resoudre --
donc sans version localisee et SANS BANDE SON. Le client possede
pourtant les deux : c est pour cela que la video montre du francais
alors que notre base n en contient aucune traduction. Il ne lui manquait
que l identifiant.
34 repliques recuperees du creature_text de dufernst/LegionCore-7.3.5,
qui a conserve les Sound et BroadcastTextID d origine, pour dix
personnages : Varian, Voljin, Jaina, Sylvanas, Genn, Thrall, Baine,
Mekkatorque et Krosus. Le texte y est en russe, sans importance --
l identifiant prime. Celui porte ici est l anglais officiel tire de
notre propre broadcast_text, en repli et repere de lecture.
GROUPES DECALES DE +10 : nos repliques existantes aux groupes 0 et 1
sont conservees, le script les appelle par Talk(0) et Talk(1). Les
ecraser ferait dire a Varian « Pour l Alliance ! » au moment de mourir.
RESTE A FAIRE : le script n appelle encore aucune de ces lignes. Il
faut des cris de combat -- « Celui-la est a moi ! », « A la gorge ! » --
et une IA pour que les allies engagent les demons. Aucune des 156
entrees de cette carte n a le moindre AIName ni ScriptName.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SIGNALE EN JEU : « j ai passe ma phase 2 et ca m a switche jusqu a la 5
sans rien faire », puis « je suis en phase 4, juste a cote de Varian, et
rien ne se valide ».
Deux causes distinctes.
La plage validait son etape DEUX fois : une fois par les criteres
officiels que le moteur reconnait, une seconde par le CompleteStep()
ajoute par-dessus. Le moteur avancait donc de deux crans. Le forcage est
retire, les criteres suffisent.
L etape « Trouver Varian » guettait une copie invoquee sur la plage,
alors que la carte porte DEJA le vrai Varian en (1120, 2484) parmi les
757 creatures transposees -- comme Vol jin, Sylvanas et Jaina. Le joueur
se tenait devant le bon personnage pendant que le script surveillait un
sosie. On retient desormais celui de la base, distingue par son spawnId,
et on ne le teleporte plus : l etape s appelle « Trouver ».
L etape du portail comptait deux « ancres dimensionnelles » (90637) que
le script fabriquait lui-meme. La video de la bataille affiche « 0/4
Ancres blindees detruites », et le wiki confirme : quatre 101667, dont
la carte porte quinze exemplaires deja poses. Les criteres officiels
45131, 45228 et 45288 sont desormais alimentes.
Le deroule de reference joint croise la video, les DB2 du build et le
wiki. Il revele trois ecarts NON corriges : le commandant Horde est
Azgalor et non Arganoth, l etape 4 Horde vise Sylvanas ET Baine, et
l etape 9 Horde consiste a tenir la crete. Il etablit aussi que nos
dialogues sont inventes -- BroadcastTextId a zero -- et que la replique
de Jaina parlant d ancres « dimensionnelles » est ce qui a produit
l erreur de code de l etape 5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signale en jeu avec une reproduction exacte : « si on attend la phase
deux sans le frapper, le serveur plante ». Deux vidages memoire l'ont
confirmee, pile en main :
#0 spell_seismic_shard::HandleScript(SpellEffIndex)
#1 Spell::HandleEffects
#2 Spell::DoSpellHitOnUnit
...
#13 InstanceMap::Update
GetDynObject renvoie un pointeur NUL quand l'objet de visee n'existe pas
-- pas encore cree, ou deja expire. La ligne suivante le dereferencait
sans le moindre test :
DynamicObject* dynamicObject = GetCaster()->GetDynObject(...);
target->CastSpell(dynamicObject->GetPositionX(), ...);
Le plantage a lieu dans le fil de mise a jour de la carte, donc il
emporte le processus entier, pas seulement la session fautive.
GetCaster() et GetHitUnit() sont verifies au passage : rien ne garantit
leur presence au moment ou l'effet est traite, un lanceur mort entre le
lancement et l'impact suffit. Meme prudence sur le ExitVehicle du script
de changement de siege, juste au-dessus.
RESTE OUVERT, signale par le meme joueur et non traite ici : le deuxieme
boss du donjon se reinitialise des qu'on le deplace, et le bouclier du
dernier boss serait purement visuel, sans absorption.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Scan de -fsyntax-only avec les vrais flags sur les 1767 fichiers du
serveur (compile_commands.json), warnings de logique actives. 3277
warnings, tries a la main. Le bruit (Wreorder, Wswitch) est ecarte ;
voici ce qui etait un vrai defaut.
Memoire morte et comportement indefini :
- ObjectMgr::GetGarrssionMissionReward rendait l adresse d un vecteur
local ; Garrison melangeait puis parcourait cet objet detruit.
- BattlePayDataStoreMgr::GetProduct faisait "return{}" sur une fonction
qui rend une reference : huit appelants lisaient un temporaire mort.
- Garrison::RewardMission reaffectait une initializer_list, ce qui ne
prolonge pas la duree de vie du tableau sous-jacent.
- WorldSession avait un destructeur non virtuel alors que
PlayerBotSession en derive : chaque delete d une session de bot ne
detruisait que la moitie de l objet. Idem FieldActing.
- boss_levantus lisait Waypointspawn[6] dans un tableau de 6 entrees,
a chaque declenchement de l evenement.
- boss_hyrja_tov modifiait expelLightSwitch deux fois sans point de
sequence, et replanifiait son evenement toutes les 20 ms au lieu de
20 secondes (IN_MILLISECONDS manquant).
Code jamais appele :
- cinq hooks OnRemoveTarget d areatrigger (Klaxxi, Blackfuse, Siege
d Orgrimmar, Ordos) : le hook du core s appelle OnUnitExit, ces
methodes n etaient rattachees a rien et les auras restaient sur le
joueur apres sa sortie de zone. Trois d entre elles n avaient meme
pas de return.
- boss_admiral_svirax declarait un membre bool du meme nom que
SetDungeonEncounterID, qui masquait la methode de BossAI ; l appel
avait ete "repare" par une virgule et ne faisait donc rien.
- WorldSession::HasSocket comparait l adresse d un tableau a NULL,
donc rendait toujours true.
Conditions toujours vraies :
- zone_vault_of_wardens : "== QUEST_STOP_GULDAN_H || QUEST_STOP_GULDAN_A"
jouait la scene de Gul dan pour n importe quelle quete acceptee.
- boss_vizaduum : "type == POINT_MOTION_TYPE || WAYPOINT_MOTION_TYPE".
- boss_council_of_elders : parenthese fermee au mauvais endroit,
"HasAura(SPELL_DISCHARGE || HasAura(SPELL_OVERLOAD))".
Valeurs tronquees :
- InstanceScript::m_ScenarioStep etait un uint8 alors qu il recoit des
ID de ScenarioStep (3195, 3207...), tronques a 135 ou 136.
- PetBattleTrainer passait 3000000000000000 a SetRespawnTime(uint32).
Nettoyage sans effet de bord : memcpy sur PetBattleRequest remplace par
une copie, et suppression d un getThreatList()/empty() sans effet dans
boss_wise_mari.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cliquer sur un dompteur de mascottes (88 PNJ, dont Julia Stevens 64330)
tuait le worldserver.
Player::QuestObjectiveActiveInPlayerByObject n avait aucun return sur le
chemin de sortie de boucle. GCC en deduit que la boucle ne peut pas se
terminer normalement -- sinon comportement indefini -- et supprime le test
q < MAX_QUEST_LOG_SIZE. Le numero de slot grimpait donc au-dela de 25
jusqu a sortir du tableau de valeurs du joueur : ASSERT dans
GetUInt32Value (index 4636, slot 275 dans la pile signalee).
Le compilateur le disait deja : "control reaches end of non-void function"
dans nos logs de build. C etait le seul cas du core, il n y en a plus.
Au passage, PetBattleTrainer.cpp gardait ObjectId et isTrainer comme
membres du CreatureScript, or celui-ci est un singleton partage par les 88
PNJ et par tous les joueurs : le dernier interlocuteur decidait de ce que
pouvait faire le suivant. La verification se fait desormais sur le joueur
et le PNJ courants.
Signale sur le Discord avec une pile gdb par un utilisateur du core.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La carte 1666 etait peuplee et scriptee depuis hier, mais aucun chemin
n y menait : le joueur restait plante devant Khadgar. Les quetes 45102
et 46734 restaient donc infranchissables malgre le portage.
Le deroulement officiel, decrit par les joueurs : on prend la quete a
l Anneau de Krasus, on choisit une option de dialogue, et l on est
emporte par la voie des airs. Cette option n existe ni dans notre base
ni dans le dump de reference -- donnee de capture jamais importee. Elle
est donc recreee sur Khadgar 86563, qui est bien celui de l Anneau de
Krasus : pose en (-841, 4258, 746), l altitude de Dalaran, et deja
donneur d Assault on Broken Shore.
Rien d invente sur la destination : le sort 240603 porte deja les
coordonnees officielles dans spell_target_position.
OnGossipHello reconstruit le menu complet avant d ajouter l option,
sans quoi Khadgar perdrait les seize quetes qu il propose : le coeur
saute PrepareGossipMenu des qu un script repond au dialogue.
Verifie en jeu : le joueur arrive bien sur la carte 1666 aux
coordonnees attendues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Croisement entre les sources officielles et notre base, pas une fiche
encyclopedique. Les quinze quetes de la campagne existent chez nous avec
donneur et receveur : elle n etait pas cassee, seuls ses deux points
d entree l etaient.
Consigne le piege des DEUX scenarios du Rivage brise (1460 intro 7.0 et
1666 assaut 7.2), les trois Khadgar a ne pas confondre, les huit etapes
du scenario 1280 relevees dans les DB2, et deux anomalies : la quete
46832 sans objectif, et un doublon de titre sur 48641.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
_setTargetLocation ne passait pas CanFly() en forceDest a CalculatePath. Une
creature volante dont la cible se tient sur un relief non navigable obtenait
PATHFIND_NOPATH, se marquait injoignable, puis evadait au bout de cinq secondes
(CREATURE_NOPATH_EVADE_TIME).
Chaque evade passe par CreatureAI::_EnterEvadeMode, qui lache le proprietaire de
butin et reinitialise m_PlayerDamageReq. A la mort, Unit::Kill force alors
SetLootRecipient(NULL) : le corps est vide et ne rapporte aucune experience. Le
symptome remonte comme un bug de table de butin alors que la table est saine.
Signale sur le Proto-drake perdu dans le temps (32491) aux Pics Foudroyes, qui
lachait l aggro tant que le joueur n etait pas sur une plateforme reliee au
maillage, puis n a rien donne une fois tue. 3709 creatures volantes du monde
etaient concernees.
Aligne sur TrinityCore amont, identique en 3.3.5 et master :
bool success = _path->CalculatePath(x, y, z, owner->CanFly());
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
BattlegroundMgr::Update forcait la mise a jour des files cotees avec
BattlegroundBracketId(14) -- la boucle sur les brackets avait ete
commentee en amont. Deux consequences :
- m_QueuedGroups ne compte que MAX_BATTLEGROUND_BRACKETS (12) entrees :
chaque passage lisait au-dela du tableau, toutes les 5 secondes.
- aucune entree PVPDifficulty ne correspond au couple (carte du template
BATTLEGROUND_AA, bracket 14), donc la fonction sortait aussitot en
journalisant une erreur : 585 000 lignes dans dc-world.log, soit la
moitie du fichier, et le force-update des arenes cotees ne servait
a rien depuis toujours.
On parcourt desormais les brackets reellement declares pour la carte, et
BattlegroundQueueUpdate refuse un bracket hors plage au lieu de lire a
cote.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ProcessLeaveBG et ProcessLeaveAA construisaient BattlefieldLeave a partir
dun WorldPacket() par defaut (opcode 65535), et ProcessInAAQueue passait
CMSG_BATTLEMASTER_JOIN_SKIRMISH a BattlemasterJoinArena. Le constructeur
de ClientPacket asserte GetOpcode() == expectedOpcode : le thread monde
mourait des quun bot devait quitter un champ de bataille (fin de match ou
depart dun vrai joueur), laissant le processus fige et les joueurs bloques
a lecran de chargement.
Signale sur le Discord avec une pile gdb par un utilisateur du core.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Suite du signalement Discord. Le garde-fou pose dans GetBGObject a tenu
-- plus de lecture hors limites -- mais les appels avec 24 et 32
persistaient : le correctif precedent visait BattlegroundAB.cpp alors que
l'appelant fautif est le module BotFill.
CommandAB.cpp indexait les bannieres en abNode * 8, disposition de
l'ancien Bassin d'Arathi de TrinityCore ou chaque noeud possedait huit
objets. Le notre n'en a qu'UN par noeud, aux indices 0 a 4. Le calcul
etait donc faux pour TOUS les noeuds :
noeud 0 -> 0 banniere juste, par hasard
noeud 1 -> 8 REGENBUFF_STABLES
noeud 2 -> 16 SPEEDBUFF_LUMBER_MILL
noeud 3 -> 24 hors limites
noeud 4 -> 32 hors limites
Les bots visaient des objets de bonus au lieu des bannieres et ne
voyaient tout simplement pas la scierie ni la mine d'or. Les deux sites
etant proteges contre le pointeur nul, cela echouait en silence : seul le
garde-fou a fini par le rendre visible. Le controle de borne manquant sur
abNode est ajoute.
Verifie au passage : Gilneas a REELLEMENT huit objets par noeud
(BG_BFG_OBJECT_MAX = 37), son node * 8 + 5 est correct. Rien a y changer.
Second defaut, sans lien avec le premier : deux fonctions de l'IA des
bots construisaient un paquet portant l'opcode CLIENT CMSG_MOVE_FALL_LAND
et le diffusaient. WorldSession le refuse toujours et journalise une
ERREUR a chaque tentative -- des milliers de lignes par match dans le
journal du rapporteur. BotBGAIMovement::SyncPosition n'avait meme aucun
autre effet : elle ne deplacait pas le bot cote serveur. Les envois sont
retires ; aucun comportement de remplacement n'a ete invente, le defaut
n'etant pas reproductible chez nous.
RESERVE IMPORTANTE : rien de ceci n'explique le PLANTAGE signale. Les
deux sites fautifs testaient deja le pointeur nul, et le journal fourni
ne contient aucune trace d'arret. Une pile d'appels est necessaire.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le carnet decrivait un etat du 27/08 ou rien n etait applique. Il note
desormais ce qui est deploye, ce qui reste a verifier en jeu, et la
raison pour laquelle les 5 chemins scriptes avaient ete manques : ils
vivent dans waypoint_data_script, table absente de notre schema.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La carte 1666 etait declaree mais entierement vide, et instance_template
y reclamait un script fantome. Les quetes 45102 « Begin the Assault » et
46734 « Assault on Broken Shore » etaient donc infranchissables : elles
relevent de ce scenario, et non de l'introduction 7.0 deja portee sur la
carte 1460.
PORTAGE, PAS TRANSCRIPTION. La source (dufernst/LegionCore-7.3.5, meme
lignee uwow) repose sur quatre extensions que nous n'avons pas :
onScenarionNextStep/getScenarionStep, CRITERIA_TYPE_SCRIPT_EVENT_2,
FunctionProcessor et une surcharge de GetClosestGraveYard. La
progression est donc inversee : au lieu d'etre rappele a chaque etape,
le script alimente les criteres officiels et le moteur avance seul --
la meme architecture que sur la carte 1460.
Les neuf criteres des huit etapes ont ete releves dans les DB2 du build
7.3.5.26972 (ScenarioStep, CriteriaTree, Criteria) et non recopies de la
source ; ils confirment ses identifiants d'asset. Sept sont de type 92
(SEND_EVENT_SCENARIO), un de type 73, un de type 68.
Six ecarts d'API traites, tous constates et non supposes :
InstanceScript(InstanceMap*), Conversation::CreateConversation (Player
n'a pas cette methode -- la source l'appelait sur une creature, cela
n'aurait pas compile), UNIT_NPC_FLAGS avec SetFlag64, DamageTaken a 2
arguments, OnSpellClick a 2, MovePath a 2.
NON PORTE : player_scripts_for_start_assault, qui sondait chaque joueur
a chaque tick pour lui imposer la quete 46730. Un donneur en base fait
le meme travail sans ce cout.
SQL joint :
- rattachement des 5 scripts a leurs 11 entrees, toutes verifiees
exclusives a la carte 1666 ;
- les 87 points des 5 chemins scriptes. Ils vivaient dans
waypoint_data_script, table absente de notre schema, d'ou leur oubli
lors de l'extraction du 27/08. Le 11322708 est le vol d'arrivee :
l'atteinte de son point 20 declenche l'etape 0, sans lui rien ne
demarrait ;
- le donneur manquant de 45102, l'archimage Khadgar 116302, deja pose
chez nous aux coordonnees de la reference mais jamais declare.
Les 593 creatures et 59 objets de la carte etaient generes depuis le
27/08 et n'avaient jamais ete appliques ; ils le sont desormais.
RESERVE : rien de tout ceci n'a ete verifie en jeu. Les credits de quete
116253 et 116279 sont en outre cables sur la fermeture des deux premiers
portails par deduction -- la quete parle de « First » et « Second Legion
Spire destroyed » -- et non sur une donnee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signale par un utilisateur de SylvaniaCore : ses matchs de Bassin
d'Arathi avec pbotbg=1 faisaient tomber le serveur, avec dans le journal
GetBGObject: gameobject (type: 24, ... Entry: 7735234) not found
GetBGObject: gameobject (type: 32, ... Entry: 0) not found
soit des GUID manifestement arbitraires, sur une carte 529 dont le
tableau BgObjects ne compte que 22 cases.
GetNearGameObjectFlag, introduit par le module BG BotFill (a7b1fa78),
indexait BgObjects en node*8+status. Cette disposition -- huit objets
par noeud -- est celle de l'ancien Bassin d'Arathi de TrinityCore. Le
notre n'a qu'UNE banniere par noeud, aux indices 0 a 4 : _ChangeBanner
modifie son visuel selon l'etat au lieu d'echanger huit objets. Le
calcul donnait donc 24 pour le noeud 3 et 32 pour le noeud 4.
Le defaut de fond est ailleurs : huit accesseurs de Battleground.cpp
indexent BgObjects ou BgCreatures avec une valeur fournie par
l'appelant, sans jamais verifier la borne -- AddObject y ECRIT meme.
Une faute de calcul y devient une corruption memoire, et le plantage
survient loin de son origine. Tous sont desormais bornes : ils
journalisent l'indice fautif et renvoient l'echec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
BlaMacfly