bd22c626311893e1fd84d2b37fd20dcf5ff1887b
254 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 BlaMacfly
|
bd22c62631 |
Rivage brise : embarquement sur le navire, escorte de mercenaires, factions
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> |
||
|
BlaMacfly
|
346bd9c200 |
Rivage brise : Tirion introuvable, allies desarmes, intro inaudible
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> |
||
|
BlaMacfly
|
0032c28f21 |
Rivage brise : plus aucune vague, Krosus attaquable, Tirion atteignable
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> |
||
|
BlaMacfly
|
5f5317dee3 |
Rivage brise : employer les PNJ de la carte, couper les vagues, etendre les voix
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>
|
||
|
BlaMacfly
|
a9f2fde270 |
Rivage brise : la mort de Tirion, et les renforts qui tombaient sur le joueur
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> |
||
|
BlaMacfly
|
82254cf627 |
Rivage brise : les neuf etapes ont enfin leurs criteres officiels
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> |
||
|
BlaMacfly
|
191422c038 |
Rivage brise : rendre la VOIX aux personnages du scenario
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> |
||
|
BlaMacfly
|
70fdf20075 |
Rivage brise 1460 : les vrais criteres, et le deroule de reference
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> |
||
|
BlaMacfly
|
5c8b82338e |
Coeur de Pierre : l'Eclat sismique d'Azil faisait tomber le serveur
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>
|
||
|
Sylvania
|
37796803c7 |
Passe de warnings sur tout le core : 12 bugs reels corriges
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>
|
||
|
Sylvania
|
5205a9b5f0 |
Dompteurs de mascottes : return manquant, le journal de quetes lu hors limites
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> |
||
|
BlaMacfly
|
6d98d5cbbd |
Rivage brise : l entree du scenario d assaut n existait nulle part
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> |
||
|
BlaMacfly
|
b047cb7a02 |
Reference Legion : premiere section, la campagne du Front-de-Legion
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> |
||
|
SylvaniaCore deploy
|
e0b2fcf3e0 |
Creatures volantes : aucun chemin vers une cible hors du maillage, evade et butin perdu
_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>
|
||
|
Sylvania
|
0b2a042175 |
Arenes cotees : bracket 14 code en dur, hors plage et introuvable
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> |
||
|
Sylvania
|
04b6dd20f5 |
Playerbots : opcodes manquants sur les paquets de sortie de champ de bataille
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> |
||
|
BlaMacfly
|
ac40810f25 |
Champs de bataille : le vrai appelant hors limites, et un opcode client diffuse
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>
|
||
|
BlaMacfly
|
5c4c4b6d7a |
Chantier Rivage brise : carnet remis a jour apres le portage
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> |
||
|
BlaMacfly
|
a95670ac0a |
Rivage brise : portage de l'Assaut 7.2 (scenario 1280, carte 1666)
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> |
||
|
BlaMacfly
|
ce69bad85b |
Bassin d'Arathi : lecture hors limites de BgObjects
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 (
|
||
|
BlaMacfly
|
a4d245ecbe |
Commandes : .npc add perdait la phase du maitre de jeu
Les PNJ crees en jeu n'etaient visibles qu'en mode MJ. InheritPhaseShift donnait bien la phase du joueur a la creature, mais SaveToDB n'ecrit que GetDBPhase() -- la phase DECLAREE EN BASE, nulle pour une creature creee a la volee. La commande detruit ensuite l'objet et le recree depuis la ligne enregistree, donc sans phase. Dans une aire phasee, PhaseShift:: CanSee exigeant une intersection, la creature etait invisible a tout joueur normal ; le mode MJ masquait le defaut, SetAlwaysVisible court-circuitant le test de phase. TrinityCore 3.3.5 transmettait la phase explicitement a Create et a SaveToDB, via un GetPhaseMaskForSpawn qui ignorait volontairement l'etat « MJ voit tout ». La reecriture du systeme de phases a perdu ce principe : master a le meme defaut. On le restaure, en annoncant la phase retenue puisqu'un joueur moderne peut en porter plusieurs alors qu'une ligne de la table creature n'a qu'un champ. SQL joint : phase 6666 posee sur l'aubergiste deja pose au port de Hurlevent, et suppression de 18 options de dialogue de type 1 qui doublonnaient une option fonctionnelle et se placaient au-dessus d'elle. Les options porteuses de conditions sont preservees -- une premiere version avait supprime a tort les options d'Halloween. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
e1ccf30afc |
Sessions : les comptes au-dessus du niveau 0 ne sont plus coupes pour inactivite
Demande : « j aimerai que les comptes au-dessus du numero 0, c est a dire
les comptes GM/testeur/admin, ne soient pas soumis en jeu a la
deconnexion automatique en cas d absence prolongee ».
La coupure vient de WorldSession::Update :
if (!IsBotSession() && IsConnectionIdle())
m_Socket[CONNECTION_TYPE_REALM]->CloseSocket();
IsConnectionIdle() s appuie sur m_timeOutTime, initialise depuis
SocketTimeOutTime (900 000 ms, soit 15 minutes) et decremente a chaque
tick sans paquet entrant.
On ajoute GetSecurity() <= SEC_PLAYER a la condition. Les comptes de
niveau superieur restent connectes indefiniment ; les joueurs ordinaires
demeurent soumis au delai, la protection contre les sessions fantomes
gardant tout son interet pour eux.
Motif concret : ces comptes restent volontairement inactifs de longues
minutes pour observer une zone, suivre un evenement scripte ou attendre
le resultat d un test -- et se faisaient couper en plein travail, parfois
au milieu d une instance.
Portee actuelle : 5 comptes concernes (3 de niveau 1, 2 de niveau 4).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
SylvaniaCore deploy
|
80a4a589f6 | worldserver.conf.dist : pbotqa et les deux cles du Bond heroique manquaient | ||
|
SylvaniaCore deploy
|
0bc9b016d6 |
Commandes : .npc near faisait tomber le serveur
Signale en jeu : « la commande .npc near fait planter le serveur ». L hypothese de l utilisateur etait proche : ce n est pas le rayon en soi, c est l absence de plafond. La requete preparee WORLD_SEL_CREATURE_NEAREST n a AUCUNE limite : SELECT ... FROM creature WHERE map = ? AND (POW(x-?,2)+POW(y-?,2)+POW(z-?,2)) <= ? ORDER BY order_ Elle calcule trois puissances sur les 384 000 lignes de la table, sans index utilisable, puis la boucle d affichage envoie UN message de discussion PAR RESULTAT. Avec un rayon large cela represente des dizaines de milliers de paquets pour une seule commande, ce qui sature la session. La requete etant partagee avec d autres commandes, on pose les garde-fous cote appelant : rayon plafonne a 500, affichage plafonne a 150 lignes. Les omissions sont ANNONCEES et non silencieuses : la commande indique combien de resultats n ont pas ete montres et invite a reduire le rayon. Un plafond muet ferait croire a une recherche complete. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
3a4c6c01dd |
Hyjal : parler a Jaina faisait tomber le serveur -- et faction 16 au Rivage brise
1) PLANTAGE DU SERVEUR, cause reelle de la coupure de cette nuit Trace du vidage 3007513 : #0 Trinity::Assert(...) #1 npc_jaina_proudmoore::OnGossipHello(Player*, Creature*) #2 WorldSession::HandleGossipHelloOpcode hyjal.cpp utilisait ENSURE_AI(hyjalAI, creature->AI()), qui ASSERTE. Or GetAI() ne fabrique une hyjalAI que si GetHyjalAI() la trouve, donc uniquement dans l instance du Mont Hyjal. Ailleurs la creature recoit une IA quelconque et l assertion tue le process. Declencheur : un exemplaire de Jaina (17772) se trouve sur la carte 0, a Hurlevent (-8295, 1386), en plus de celui du Mont Hyjal. Lui parler suffisait a planter le serveur -- faille exploitable par n importe quel joueur, sans commande ni privilege. Les 5 occurrences passent en dynamic_cast avec sortie propre. J avais d abord conclu a une recursion en me fiant a la taille du vidage (387 Mo contre 133). C ETAIT FAUX : cette taille reflete la memoire allouee au moment du plantage, pas un debordement de pile. La trace, elle, etait parfaitement lisible. 2) RIVAGE BRISE : factions demoniaques ramenees a 16 Etabli par TEST A/B, pas par raisonnement. Une seule entree basculee en faction 16 (Molosse de l effroi gangrene, 90686), toutes choses egales par ailleurs. Verdict en jeu : « les molosses sont maintenant attaquables », les autres non. La sonde SPAWNDBG confirme que seule la faction distingue les deux : Felstalker Dreadhound faction=16 drapeaux=32768 drapeaux2=0 OK Felguard Legionnaire faction=2780 drapeaux=32768 drapeaux2=0 bloque Pourquoi 2780 echoue reste INEXPLIQUE : FactionTemplate.db2 lui donne EnemyGroup=15 (ennemi de tous) et sa faction 1786 a ReputationIndex=-1, donc aucune reputation n intervient. Sur le papier elle devrait etre hostile. Le refus vient du client, qu aucune sonde serveur ne peut observer. On retient donc la faction 16, demontree fonctionnelle dans ce scenario meme -- ecart assume avec la donnee de reference. 101 entrees, 464 spawns. Effet secondaire bienvenu : les demons cessent de s entretuer (Friend_0=14). 3) COMPTEUR : tout demon compte desormais Signale : « les molosses sont attaquables mais ne comptent pas dans l objectif ». OnUnitDeath ne reconnaissait que les cinq entrees invoquees par le script. On s appuie desormais sur le type demon plutot que sur une liste de 101 entrees qui vieillirait mal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
b0b876b76b | README : renvoyer vers le wiki, section Documentation et allegement du depannage | ||
|
SylvaniaCore deploy
|
fa7a543b94 | worldserver.conf.dist : les 10 cles du module Mercenaires manquaient | ||
|
SylvaniaCore deploy
|
5408eae697 |
Rivage brise 1460 : UNIT_FLAG2_UNK5 rendait les demons inattaquables
Signale en jeu, nommement : Gangreseigneur Rakkan, Legionnaire gangregarde, Molosse de l effroi gangrene. Et l observation decisive : « les demons inattaquables se battent avec les demons attaquables ». LA CAUSE EST DE MON FAIT. La transposition des modeles a importe unit_flags2 sur 147 entrees. Ces creatures valaient 0 avant ; elles ont recu 2097152, soit 0x200000 -- UNIT_FLAG2_UNK5. CE DRAPEAU EST PARTICULIER : notre serveur l IGNORE totalement, aucune de ses verifications ne le consulte. Le client, lui, l interprete et refuse de designer la creature comme cible. C est ce qui explique le symptome le plus deroutant de la serie : la sonde posee dans _IsValidAttackTarget n a JAMAIS produit la moindre ligne pour ces creatures. Le client refusait de lui-meme, sans jamais interroger le serveur. L ABSENCE DE TRACE ETAIT L INFORMATION -- j ai mis trois tours a la lire comme telle. CORRELATION QUI TRANCHE : demons INVOQUES (attaquables) : unit_flags2 = 0 demons STATIQUES (bloques) : bit 0x200000 present 67 entrees, 420 spawns. Seul ce bit est retire, le reste de la colonne est preserve. Le serveur ne s en sert pas : le retrait ne peut rien casser cote logique. Egalement dans ce lot, deux sondes conservees le temps de la validation : ATTDBG (recentree sur les factions 2780/1768) et SPAWNDBG (etat reel des creatures a leur creation). Deux divergences d API relevees au passage : getFaction() et getLevel(), en minuscule dans ce fork. Retour arriere joint. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
995122dc78 |
Rivage brise 1460 : les demons statiques etaient immunises aux joueurs
Signale en jeu : « les demons invoques c est ok mais pas les autres au fond ». Les creatures invoquees par le script etaient frappables, les placements statiques non. LA CAUSE EST DE MON FAIT. La transposition des modeles d hier a importe unit_flags sur 136 entrees. Parmi les valeurs reprises, 33536 et 537166592 contiennent le bit 256 -- UNIT_FLAG_IMMUNE_TO_PC. Dans le coeur de reference un script retire vraisemblablement ce drapeau au bon moment ; le notre ne gere aucun drapeau, les demons restaient donc immunises en permanence. Cela explique aussi pourquoi la sonde ATTDBG ne produisait plus rien : le client refusait de lui-meme, sans jamais interroger le serveur. L absence de trace etait l information. PORTEE : uniquement les factions HOSTILES -- 2780 (30 entrees), 1768 (20 : Anetheron, Balnazzar, Brutallus...), 2878 (Krosus), 14 (Gul dan), 2877 (Lave gangrenee). Soit 53 entrees. EPARGNES car l immunite y est legitime : factions 35, 2876, 2879, 1819 -- allies, pretres, montures, vaisseaux. 13 entrees conservees. SIMPLIFICATION ASSUMEE : Krosus et Gul dan perdent aussi leur immunite, alors qu une implementation fidele la retirerait au debut de leur etape. Notre script ne gere aucun drapeau : la conserver rendrait les etapes 7 et 8 infranchissables. La progression reste pilotee par la machine a etats du script. Retour arriere joint. A NOTER, non traite : les modeles de Varian (90713) et Jaina (90714) sont ceux d anciennes versions. Le dump de reference ne stocke aucun modele dans creature_template -- ses affichages viennent d ailleurs. Une autre source sera necessaire. Cosmetique, non bloquant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
0ac509e421 |
Rivage brise 1460 : le phasage rendait les creatures inattaquables
Signale en jeu : creatures visibles, hostiles, mais impossibles a cibler
-- alors qu elles pouvaient attaquer le joueur.
J avais enchaine trois hypotheses (phase, factions, modeles souches).
Les trois etaient de VRAIS defauts et meritaient correction, mais aucune
n etait la cause. J aurais du poser la sonde d abord.
VERDICT DE LA SONDE, dans _IsValidAttackTarget :
Felblade Destroyer | vivante=1 | aucun drapeau bloquant
reaction=1 (hostile) | mesPhases=0 sesPhases=1
Le joueur n a AUCUNE phase, la creature en a une. PhaseShift::CanSee
exige une intersection des phases, et UpdateUnphasedFlag retire le
statut « non phase » des qu un objet en possede une. Aucune intersection
possible.
C est MA modification precedente qui a introduit ce decalage : j avais
place les 757 spawns en phase 169 en croyant que le joueur y etait,
en me fiant a un commentaire du script. Il ne l etait pas.
CORRECTIF : suppression du phasage des deux cotes, ce qui rejoint la
configuration de la reference -- le dump laisse les 757 placements de
cette carte SANS phase. La phase 169 n existe d ailleurs pas dans
Phase.db2 du build 7.3.5.26972.
- PhaseId remis a 0 sur les 757 creatures et les 101 objets ;
- AddPhase retire de OnPlayerEnter ;
- FinalizeSummon ne phase plus rien (conservee comme point de passage
unique, sans quoi les invocations deviendraient invisibles a un
joueur non phase -- le meme probleme en sens inverse).
La sonde ATTDBG est CONSERVEE le temps de la validation en jeu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
SylvaniaCore deploy
|
6219d00c06 |
Rivage brise 1460 : les modeles de creatures etaient des souches
Signale en jeu : « exemple lui n est pas attaquable », capture d un
.npc info montrant Felguard Legionnaire (109591) en Level: 1.
Nos creature_template de l epoque Legion sont des SOUCHES : sur les 152
entrees exclusives a cette carte, 141 etaient au niveau 1. La faction,
corrigee au tour precedent, n etait que la partie visible du trou.
Divergences relevees face au dump de reference :
minlevel 150/152 unit_flags2 147/152
maxlevel 145/152 unit_flags 136/152
unit_class 62/152 speed_run 55/152
AIName 32/152 speed_walk 12/152
151 entrees corrigees. Il ne reste que 6 souches : les entrees partagees
avec d autres cartes, volontairement ecartees comme pour les factions --
ce sont des declencheurs invisibles.
EXCLUS VOLONTAIREMENT du correctif, malgre leurs divergences :
AIName -- transposer pourrait defaire un comportement pose
sciemment chez nous.
flags_extra -- porte des drapeaux que le coeur calcule lui-meme, dont
CREATURE_FLAG_EXTRA_DUNGEON_BOSS pose au chargement
depuis instance_encounters.
Verification prealable ecrite : un comparateur colonne par colonne
(chantiers/rivage_brise/outils/comparer_templates.py) a mesure les
divergences avant toute modification, plutot que de transposer en bloc.
La faction n y figurait plus, confirmant que le correctif precedent avait
bien pris et que l outil dit vrai.
Retour arriere joint, reconstruit depuis les valeurs d avant correction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
SylvaniaCore deploy
|
6c3804dde9 |
Rivage brise 1460 : les demons etaient hors de la phase du joueur
Signale en jeu : « les ennemis sont bien affiches en rouge mais mon curseur ne m indique pas qu ils sont attaquables ; en revanche eux peuvent m attaquer ». scenario_broken_shore_intro::OnPlayerEnter place chaque joueur en phase 169 (PhasingHandler::AddPhase). Le script porte son propre avertissement, ecrit par qui l a redige : « Toute invocation doit partager la phase des joueurs, sinon elle est invisible/intangible : cible de quete introuvable, vague intuable. » C est pourquoi FinalizeSummon ajoute la phase 169 a tout ce qu il invoque. Or les 757 placements importes etaient en phase 0. Le script n en attendait AUCUN : il invoquait la totalite de ses acteurs. En important le decor statique, on a introduit des creatures qui ne partagent pas la phase du joueur -- visibles, mais intangibles. VERIFIE avant de conclure : la reference donne bien PhaseId vide pour les 757 lignes, la conversion en 0 etait donc fidele. Le decalage vient de notre script, pas de la transposition. CHOIX : aligner les placements sur la convention du script plutot que de retirer le phasage. Retirer la phase 169 du joueur obligerait a la retirer aussi de toutes les invocations -- bien plus de code touche pour le meme resultat. Les 101 objets sont inclus : les Fleches de la Detresse doivent etre actionnables, sans quoi le critere des 3 fleches reste bloque. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
966a866e7c |
Mardum : le point de foyer etait fixe a l origine au lieu de la destination
Signale en jeu : « j ai utilise ma pierre de foyer qui ne m a pas
teleporte, je devais atterrir en foret d Elwynn et il est ecrit vous
renvoie a Fleur-de-l hiver alors que je n ai pas change le lieu ».
La pierre fonctionnait parfaitement : elle renvoyait a Mardum, ou le
joueur se trouvait deja -- d ou l impression qu elle ne faisait rien.
CAUSE, dans spell_mardum_back_to_black_temple :
player->TeleportTo(1468, 4325.46f, -620.53f, -281.40f, 1.517563f);
player->SetHomebind(player->GetWorldLocation(), 7873);
TeleportTo est ASYNCHRONE : le joueur n est pas deplace a la ligne
suivante, si bien que GetWorldLocation() renvoyait encore la position de
MARDUM. Le point de foyer se retrouvait donc fixe la ou le joueur venait
de partir, au lieu du Caveau des Gardiennes (carte 1468) visé.
Constate en base : character_homebind du personnage pointait sur
mapId 1481 (Mardum), zone 6383.
On lie desormais explicitement a la DESTINATION, via une WorldLocation
construite une fois et passee aux deux appels.
Le point de foyer du personnage affecte a ete remis en foret d Elwynn,
avec des coordonnees reprises d un homebind Alliance deja valide dans
notre base plutot qu inventees.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
SylvaniaCore deploy
|
483b3c02bc |
Rivage brise 1460 : les demons etaient flagues en allies
Signale en jeu, capture a l appui : « ce sont bien des ennemis mais
flagues en allie » -- plaques de nom vertes sur les Legionnaires
gangregarde.
Sur les 156 entrees placees, 729 spawns sur 757 portaient la faction 35,
amicale envers tous. Comparaison avec creature_template du dump de
reference : 135 entrees divergeaient. Ce trou est ANTERIEUR a l import
des placements, qui ne touche pas creature_template -- c est une valeur
par defaut posee sur ces PNJ de Legion dans notre base.
Repartition retablie :
2780 441 creatures les demons de la Legion (hostiles)
2879 105 les PNJ Alliance
2876 67 les PNJ Horde
1768 23 les demons nommes (Anetheron, Balnazzar, Brutallus)
35 74 ce qui doit rester neutre : canons, vehicules,
navires, declencheurs invisibles
PRUDENCE OBSERVEE : creature_template.faction agit PARTOUT, pas seulement
sur la carte visee. Les 4 entrees possedant un spawn hors de la carte
1460 ont donc ete EXCLUES du correctif -- ce sont des declencheurs
invisibles (General Purpose Bunny) et un matelot, pour lesquels la
faction 35 est correcte. Portee reelle : 135 entrees exclusives a 1460.
Fichier de retour arriere joint (chantiers/rivage_brise/), reconstruit
depuis les valeurs en place avant modification.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
SylvaniaCore deploy
|
42427a8a72 |
Rivage brise 1460 : rebrancher les vrais compteurs de l etape 1
Signale en jeu : « la phase 1 ou il fallait tuer 33 demons ainsi que
d autres objectifs a ete skip et je suis passe en phase 3 direct », puis
« les objectifs ne se remplissent jamais ».
DEUX COMPTEURS VIVAIENT EN PARALLELE, et ne disaient pas la meme chose.
Le client affichait les criteres officiels de l arbre 42935 (« Broken
Shore - Stage 1 », operateur ALL) du build 7.3.5.26972 :
43010 Demons slain 33 critere 27653
46549 Fel Lords slain 3 critere 29377
46548 Spires of Woe destroyed 3 critere 27619
Tous trois de type CRITERIA_TYPE_SEND_EVENT_SCENARIO (92) : ils ne se
remplissent PAS en tuant, mais quand le script emet l evenement
correspondant. Le script ne l emettait jamais -- d ou le 0/33 fige.
En parallele, il tenait sa propre comptabilite et cloturait l etape a
KILLS_BEACH = 12, un chiffre invente. D ou l impression de saut : a 12
demons il invoquait Arganoth avec SetInCombatWithZone(), lequel mourait
aussitot et faisait franchir une seconde etape.
CORRECTIF -- on ne touche PAS aux objectifs, qui sont officiels et de
toute facon dans les donnees du client. On supprime le seuil invente et
on emet les vrais evenements :
- chaque demon tue emet 44095 ;
- chaque Seigneur gangrebois emet 52643 (les treize entrees placees
sur la carte sont enumerees explicitement, le nom n etant pas une
donnee stable) ;
- chaque Fleche actionnee emet 44077 ;
- l etape ne s acheve que si les TROIS seuils officiels sont atteints
(33 / 3 / 3), conformement a l operateur ALL de l arbre.
LES FLECHES sont des objets de type 10 : ACTIONNES, pas detruits. Ni
OnGameObjectCreate ni OnGameObjectRemove ne rapportent cette
utilisation. Le seul accrochage est GameObjectScript::OnGossipHello, que
GameObject::Use appelle avant tout traitement specifique
(GameObject.cpp:1379). D ou la classe go_spire_of_woe -- ET son
rattachement en base, sans lequel elle n aurait jamais ete invoquee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
SylvaniaCore deploy
|
c8f1d570e1 |
Rivage brise : placements des cartes 1460 et 1666, generateur unifie
NON APPLIQUES au serveur. Verses pour relecture.
DECOUVERTE QUI RECADRE LE CHANTIER
Il y a DEUX Rivages brises, et je preparais le second en premier :
carte 1460 -- le lancement de Legion (Voljin, Varian, la defaite),
c est le contenu de la video fournie ;
carte 1666 -- l assaut de la 7.2 (Kalgorath, Arganoth, Mephistroth).
Pour la 1460, NOTRE SCRIPT EXISTE DEJA : scenario_broken_shore_intro.cpp,
464 lignes, correctement rattache -- instance_template reclame
scenario_broken_shore_intro et c est exactement le nom sous lequel il
s enregistre (RegisterInstanceScript, map 1460). Son scenario est aussi
deja declare (786). Il ne lui manquait QUE les placements. Aucun portage
C++ n est necessaire pour cette carte.
VERIFICATION CROISEE faite avant de generer : sur les 17 entrees que le
script attend, 10 sont placees dans la reference (Voljin, Sylvanas,
Baine, Thrall, Varian, Jaina, Mekkatorque, Genn, Krosus, Arganoth) et
les 7 autres sont INVOQUEES par le script lui-meme (Khadgar l.335,
ancres l.370-371, Tirion l.380, Guldan l.398, troupes via TroopEntry,
credit de fin l.431). La repartition est donc coherente.
CONTENU
carte 1460 : 757 creatures, 101 objets, 84 chemins (526 points)
carte 1666 : 593 creatures, 59 objets, 180 chemins (1495 points)
Toutes les creatures mobiles ont leur chemin, aucune orpheline.
BUG RATTRAPE A LA VALIDATION
Une premiere version de l outil, obtenue en substituant mecaniquement le
numero de carte, produisait pour la 1460 un fichier dont les DELETE
visaient encore la 1666 : il aurait vide la mauvaise carte et laisse
l autre intacte. Le generateur est reecrit, le numero de carte ne vit
plus qu a un seul endroit, et la difficulte est desormais DEDUITE du
spawnMask (verifiee puissance de 2, uniforme) au lieu d etre codee.
VALIDATION en base jetable pour les deux fichiers : import reussi,
comptages exacts, zero creature hors carte, zero mauvaise difficulte,
zero mobile sans chemin, zero collision de GUID avec la base reelle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
SylvaniaCore deploy
|
1b1eb863e2 |
Rivage brise : declaration du scenario pour la carte 1666
Sans cette ligne la carte n a aucun scenario attache : aucun suivi d objectifs ne s affiche et aucune progression n est enregistree. Meme manque que celui constate sur les donjons de Pandarie. VALEURS VERIFIEES, pas supposees Scenario 1280 : releve dans scenario_data du dump de reference, puis confirme dans Scenario.db2 du build 7.3.5.26972 -- « The Assault on Broken Shore », type 4. Difficulte 12 : MapDifficulty.db2 ne declare qu une seule difficulte pour la carte 1666, la 12, pour 5 joueurs. Difficulty.db2 donne pour la 12 « Normal Scenario », type d instance 5. RECOUPEMENT INDEPENDANT : les 593 placements extraits pour cette carte portent tous spawnMask = 4096, soit 2^12 -- la meme difficulte. Deux sources distinctes concordent. Team 0 cote reference = les deux camps, d ou scenario_A = scenario_H, ce que confirme la video qui montre le meme deroule des deux cotes. Le scenario compte HUIT etapes distinctes (Into the Fray, Vanguard of the Assault, Might of the Legion, Rifts of Chaos, The Doomguard s Command, Gateway to Ruin, Pillar of Fire, Mephistroth), chacune avec son propre arbre de criteres -- contrairement a la Brasserie qui n en avait qu une a trois criteres. Le correctif de scenario deploye aujourd hui se comportera donc correctement ici. Applique. Table lue au demarrage : effet au prochain redemarrage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
bab69fab2d |
Rivage brise : SQL de placement genere (593 creatures, 59 objets, 180 chemins)
NON APPLIQUE au serveur. Le fichier est verse pour relecture. Transpose depuis le dump world de dufernst/LegionCore-7.3.5 vers notre schema. Le generateur est pilote par les NOMS de colonnes et s arrete plutot que de produire un decalage silencieux si un schema bouge. CONTENU 593 creatures, 59 objets, 180 chemins (1495 points). Les 180 creatures a MovementType=2 ont TOUTES leur chemin : aucune orpheline. DECISIONS etablies sur donnees spawnMask 4096 = 2^12 -> spawnDifficulties '12', la difficulte 12 etant « Normal Scenario » d apres Difficulty.db2 du build 7.3.5.26972. GUID renumerotes a partir de 290100000 et 210200000, au-dessus de nos maxima 290000114 et 210120986. PhaseId : chaine vide cote reference -> 0 chez nous (colonne entiere). VALIDATION faite dans une base jetable, pas sur dc_world : import reussi, comptages exacts, et cinq controles a zero -- aucune creature hors carte, aucune difficulte erronee, aucune mobile sans chemin, aucun chemin orphelin, aucune position nulle. Aucune collision de GUID avec la base reelle. La carte 1666 y est actuellement vide, donc le DELETE d en-tete n efface rien. Repartition en altitude coherente : 454 creatures au sol, 64 au-dessus de 600 (aeronefs presumes, a confirmer en jeu). ABANDONNE faute d equivalent : npcflag2, AiID, MovementID, MeleeID, isActive, skipClone, personal_size, isTeemingSpawn. 12 creatures portaient AiID=7424 : leur comportement est perdu et reste a refaire. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
15ac8dbd7a |
Chantier Rivage brise : materiel de reference et outillage d extraction
Rien n est applique au serveur. Ce commit ne fait que persister le travail de reperage, qui vivait dans /home/ubuntu/tmp et aurait ete perdu. LE BLOCAGE. instance_template reclame pour la carte 1666 un script nomme scenario_7.2_broken_shore_intro qui n existe nulle part dans notre code -- script fantome. La table scenarios n a aucune ligne pour cette carte. Les quetes 45102 et 46734 sont donc infranchissables. RASSEMBLE depuis dufernst/LegionCore-7.3.5 (meme lignee uwow) : - AssaultBrokenShore.cpp (500 lignes) et instance_AssaultBrokenShore.cpp (308 lignes) ; - reperage de 593 placements de creatures (67 entrees) et 59 placements d objets (52 entrees) sur la carte 1666, dans le dump world du depot. NOTRE BASE possede deja les 67 modeles de creatures et les 52 modeles d objets -- aucun manquant. Elle possede aussi les repliques francaises de Vol jin (90708) et Sylvanas (90709), qui n ont ni spawn ni script. DECISIONS DE TRANSPOSITION etablies sur donnees, pas supposees : - spawnMask 4096 = 2^12 -> spawnDifficulties '12', la difficulte 12 etant « Normal Scenario » d apres Difficulty.db2 du build 7.3.5.26972 ; - GUID renumerotes au-dessus de nos maxima (290000114 / 210120986) ; - huit colonnes de la reference sans equivalent chez nous, abandonnees. DEPENDANCES DECOUVERTES : 180 des 593 creatures ont MovementType 2 et suivent donc des chemins a extraire aussi ; 12 portent un AiID renvoyant a une table propre au coeur de reference, comportement a refaire. PIEGE CONSIGNE dans le README : le premier extracteur renvoyait zero ligne, ce qui aurait fait conclure a tort que la reference etait vide. Les instructions insert du dump s etalent sur plusieurs lignes. C est un controle sur cas positif connu qui a revele le bug. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
1507d1084d |
Brasserie : les vermifuges s accumulaient sans aucune limite
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> |
||
|
SylvaniaCore deploy
|
7f8cdd2d4b |
Scenarios : la verification de l etape doit etre purement lectrice
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>
|
||
|
SylvaniaCore deploy
|
85b0251bc1 |
Scenarios : le premier critere achevé cloturait toute l etape
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> |
||
|
SylvaniaCore deploy
|
8238ca0925 |
Brasserie : l instance n enregistrait jamais rien
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>
|
||
|
SylvaniaCore deploy
|
b0174ab55f |
Brasserie : ligne de vue refusee a bout portant dans l arene d Ook-Ook
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> |
||
|
SylvaniaCore deploy
|
80b76d3bd1 |
Pandarie : aucune rencontre de boss n etait declaree
Signale en jeu : « je n ai plus les objectifs de boss a battre affiches, ce qui laisse penser que le donjon est considere comme fini au 1er boss ». instance_encounters associe une rencontre officielle (DungeonEncounter) a la creature qui la valide. Sans ces lignes le coeur n a rien a annoncer au client : aucun objectif ne s affiche et aucune progression n est enregistree. Le script d instance declarait pourtant bien ses trois rencontres (MAX_ENCOUNTER 3) -- c est la donnee qui manquait, pas le code. Verification faite, AUCUN donjon de Pandarie n avait ses rencontres : Temple du Serpent de jade, Brasserie, Passage des Voleurs de mort, Palais de Mogu shan, Porte du Couchant, Fosse aux serpents. La table contient 389 rencontres pour les extensions precedentes : l oubli est circonscrit a Pandarie. Traites ici les deux donjons debogues recemment (7 rencontres). Identifiants releves dans DungeonEncounter.db2 du build 7.3.5.26972 filtre par MapID, et LFGDungeons.db2 en mode normal pour le dernier boss de chaque donjon. Table lue au demarrage uniquement : necessite un redemarrage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
29038ec486 |
sylvania/README : remettre les notes internes en accord avec le serveur
Le document affirmait "PlayerBots : DESACTIVES - serveur blizzlike sans bots" alors que trois modules du royaume en pilotent : BG BotFill (pbotbg = 1), Mercenaires (pbotmerc = 1) et le Siege des Capitales (livre, siege_enable = 0 pour l instant). Ce qui est coupe, c est le peuplement automatique herite de l amont (pbot = 0, pbotall = 0), pas le systeme lui-meme : World.cpp initialise le gestionnaire de bots des que pbotbg OU pbotall vaut 1. La confusion pouvait conduire un contributeur a croire tout ce code mort. Le reste etait date dans les memes proportions : une liste de quatre "correctifs a commits dedies" pour plus de 200 commits de divergence, et rien sur les modules ni sur la vraie base moteur (MariaDB 11.4, bases dc_*). Les valeurs de configuration sont desormais relevees du worldserver.conf en production, avec l effet de chaque cle. Ajoute aussi : la mise en garde sur sql/sylvania (le dossier n a pas une base cible unique, capital_siege.sql ecrit dans characters et non dans world), et la description de db-release-github.sh. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
e657f4fb96 |
Brasserie : Ook-Ook ne descendait jamais, tonneaux encastres, barre decalee
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>
|
||
|
SylvaniaCore deploy
|
b182593051 |
Distribution des bases : script de release, et les 2 tables du Siege
Le depot fournissait deja des schemas auth et characters vierges, mais pas les bases de contenu : personne ne pouvait monter une copie conforme du royaume. Elles ne peuvent pas vivre dans l historique git (dc_world pese 880 Mo, ~79 Mo gzippe, et GitHub refuse au-dela de 100 Mo par fichier) : le canal correct est l asset de Release, celui qu utilise deja l amont. sylvania/scripts/db-release-github.sh dumpe dc_world et dc_hotfixes en clair, calcule les empreintes et depose le tout en Release BROUILLON, a relire avant publication. Deux precautions apres verification des dumps reels : - MariaDB 11.4 ecrit ses tables en utf8mb4_uca1400_ai_ci, collation inconnue de MySQL 8 : un import s y arretait sur "Unknown collation". Le script la reecrit en utf8mb4_unicode_ci, reconnue des deux moteurs et de meme semantique, et refuse de produire un dump ou il en resterait. - Les tables de travail bak_* et tmp_* laissees par d anciennes maintenances (7 tables) sont exclues : ce n est pas du contenu. Test de restauration complet passe : 248 tables, updates a 332 lignes (le core ne rejouera donc pas sql/updates/world), 110 483 creature_template et 29 013 quest_template, aucune erreur. Par ailleurs capital_siege_state et capital_siege_history n existaient que dans sql/sylvania/capital_siege.sql, hors du mecanisme de mise a jour : une installation neuve avait un schema characters incomplet et le module ecrivait dans des tables absentes. Le patch est repris tel quel en fichier d update. Enfin, les prerequis annoncaient MySQL 8.0 alors que le serveur tourne sous MariaDB 11.4. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
6fac9ded3e |
README : section d installation de la base de donnees
L etape 3 se contentait de dire d importer les structures SQL de sql/base, ce qui envoie droit dans le mur : les bases world et hotfixes n y sont pas, et sql/base/dev ne contient que des tables vides. Un contributeur s est retrouve bloque sur l ecran de chargement apres avoir importe ces structures. La nouvelle section indique ou telecharger la base amont (release DB735.02 de DestinyCore), l ordre d import, le reglage Updates.EnableDatabases = 31 qui laisse le core appliquer sql/updates tout seul, et le sort de sql/sylvania. Elle documente aussi les deux messages de console (ResourceService.GetContentHandle et CMSG_GET_ACCOUNT_CHARACTER_LIST) qui sont normaux sur toute la lignee et ne sont pas des pannes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
SylvaniaCore deploy
|
8e9b65291f |
Brasserie : roulement des tonneaux, et sonde sur le reveil d Ook-Ook
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> |