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>
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>
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>
BGSType_EnterBG n avait aucun site d emission : les bots restaient invites
jusqu a expiration et le joueur entrait seul dans le BG. InviteGroupToBG
pousse desormais le schedule aux sessions bots, et ProcessEnterBG utilise
le slot de file reel comme Ticket.Id (attendu par HandleBattleFieldPort).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ProcessInBGQueue envoyait BattlemasterJoin avec QueueID=0 (ligne commentee du
portage) : toutes les inscriptions bots etaient rejetees (invalid bgtype 0).
Ajout de GetScheduledBotCount : tant que 8+ bots sont en cours d engagement
(login/re-level/inscription), le tick n en engage pas de nouveaux (on est
montes a 92 bots en ligne pour un 15v15).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- PlayerBotSession : simulation de l ack de teleport PROCHE (CMSG_MOVE_TELEPORT_ACK),
debloque les .tele enchaines sur un bot (le 1er passait, les suivants restaient coinces)
- Runner artefacts, fixes issus de la passe bot in-game (7 scenarios certifies ACTIFS) :
* vagues engagees explicitement (SetReactState AGGRESSIVE + SetInCombatWithZone) :
les TempSummon de Map n aggro pas seuls -> mobs inertes sur TOUS les scenarios
* phase 169 appliquee aux invocations (alignement avec OnPlayerEnter)
* tolerance GetHeight 25->60m (Skywall : plateformes etagees, le garde-fou lachait
les vagues dans le vide) + sonde QA-PROBE etiquetee par map (visibilite/combat/pos)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- PlayerBotSession : simulation de l ack MSG_MOVE_WORLDPORT pour un bot en jeu
(IsBeingTeleportedFar) ; sans ca tout .tele name sur un bot restait bloque
- BotFieldAI : eviction hors instance gatee par la config pbotqa (harnais scenarios)
- Diagnostics QA-BOTLOG/QA-RUNLOG (login bot, holder async, cycle du runner)
- Runner artefacts : Z des spawns cale au sol via GetHeight avec repli sur l ancre,
offsets resserres (plateformes type Skywall)
- Cause racine login bots : noms generes invalides (chiffres) rejetes par
CheckPlayerName -> persos QA renommes en DB (Botqa/Botqb, compte 32)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sylvania