Viano-Core/doc/clientless/2026-11-01-raid-test-investigation.md

Ursachenanalyse: Raidtest 01.11.2026, 22/23 Uhr

Nur Diagnose; kein Produktionscode, Botplan, Loader oder Serverzustand geändert. Branch feature/clientless-player-core; vorhandene Checkpoints/WIP erhalten.

1. Bestätigter Aufbruchblocker: falsche Zielvariante

Vorbereitung verwendete instance_visit_at_6354. BuildInstanceVariants in AdventureLocationMgr.cpp bevorzugt bei Raids mit vorhandener 25er-Normalvariante Difficulty1 für den Basisschlüssel. Difficulty0 wird als _d0 erzeugt. Native MapDifficulty.dbc für Karte671: modes0/1/2/3 haben10/25/10/25 Plätze. Dies wurde direkt aus der installierten DBC gelesen, nicht aus Namen geraten. Die passende 10er-Normalvariante ist instance_visit_at_6354_d0; native Eligibility für Renren bestätigt map671/content1/own1/invitation1 für beide Schlüssel.

Zusätzliche Inkonsistenz: InstanceCapacity=min(20,maxPlayers) begrenzt die 25er- Variante auf20, während Name und Difficulty bei25 bleiben. GroupPlan übernimmt InstanceCapacity. Complete verlangt exakt Capacity Mitglieder plus Rollen: capacity20 benötigt2T/4H/14D; tatsächlich sind10Bots mit2T/2H/6D in Gruppe2. Complete ist somit false, CheckFullGroup aktiviert keinen frühen Abreisehandoff. Um23:00 blockiert Begin vor ResolveInstance/Queue(travel_to_node) in WaitingGroup. Der korrekte Eingangspfad wird folglich gar nicht angefordert. Aktuell alle10 im selben raid-Intent/WaitingGroup. Kein Beleg für ein Problem der Bastionroute.

Der falsche Basisschlüssel war ein Fehler der Testvorbereitung. Die20/25- Inkonsistenz ist ein separater Implementierungsfehler. Ein bloßer Teleport oder Reisereset kann beides nicht beheben. Der vorhandene Variantentest erwartet explizit20 für25er-Modi; Tests decken diese fehlerhafte Semantik daher nicht auf. Keine Tests/Builds in dieser reinen Diagnose gestartet.

2. Bestätigte Zerstreuungskette: Reiseablehnung und ungebundener Fallback

Historisches rotiertes Navigationlog:22:00:02 guid159 bei (-8864.300,682.378,97.943), ZielAllison(-8867.790,673.673,97.986). NAV_PLAN calculated1/complete1/type0x1, Weg9.38yd,4Punkte,maxZDelta0.03, finalDistance0.08 und reason ok. NAV_START trotzdem PathRejected. Fünf Recoveryversuche zu anderen Graphankern schlagen ebenfalls fehl; Flugfallback kann den Startplatz nicht erreichen.22:00:04 RECOVERY_FAILED und INTENT_ARRIVAL_REJECT beim vereinbarten Treffpunkt.

Fallback schützt einen aktiven Instanzbesuch sowie Botgruppenmitglieder mit GroupOverride, aber nicht den Treffpunkt einer Gruppenbildung beim Leader. Er durchsucht ALLE Allowed-Locations und priorisiert andere Maps lediglich mit Distanzaufschlag100000. Es gibt keine Bindung an vereinbarten Treffpunkt, Sturmwind oder aktuelle Hauptstadt. Logs zeigen Allison->GildedRose->weitere SW-Orte->Eisenschmiede->andere Hauptstädte, insgesamt37 Ersatzwahlen beim Leader. AdoptGroup übernimmt jeweils den Laufzeitzustand des Leaders. Mitglieder beenden laufende Taxi/Flug/Transport-Schritte vor dem Wechsel; deshalb verfolgen sie zeitversetzt verschiedene alte Ziele und verteilen sich über Kontinente.

Die genaue geometrische Ursache der ERSTEN PathRejected-Ablehnung ist offen. MMAP hat einen vollständigen Weg geliefert. Nachfolgende Ausführungsprüfungen umfassen AllowsSegment und den für Gruppen installierten GroundPathValidator (Höhenprobe/Steigung/LOS). Beide können ohne präzises NAV_REJECT-Log abbrechen. Die vorhandenen Logs rechtfertigen keine eindeutige Schuldzuweisung an eine bestimmte Höhen-/LOS-Probe. Zur Behebung diesen Ort gezielt reproduzieren und Ablehnungszweig/Koordinaten/erwartete und gemessene Höhe diagnostizieren; keine pauschale Abschaltung von Sicherheitsprüfungen.

3. Zwei beim Stundenwechsel verzögerte Mitglieder

Um23:00 warteten164/165 noch auf eine Leaderroute für die alte Gruppenbildung. Queue hängt Botmitgliedern route_source an; der Executor wartet bis15Sekunden auf eine geteilte Route, danach erfolgt eigenständige Anschlussplanung. SetWanted fordert während aktiver Reise StopAtNode an; Switching wartet auf Busy=false und führt gegebenenfalls einen Graphknoten-Handover aus. Nachfolgende native Diagnosen: beide travel_to_node stormwind_tradecenter Completed/Arrived und raid/WaitingGroup. Die anfängliche Aussage eines dauerhaften Intent-Hängers ist nicht belegt; das beobachtete Warten war vorübergehend.

Gezielte Korrekturen für einen Folgetest

• Testziel explizit instance_visit_at_6354_d0; Difficulty0/capacity10/2T2H6D zusammen mit nativer Gruppen-Difficulty und Complete überprüfen.
• 25er-Modi nicht als20er-Gruppe für einen25er-Raid vollständig melden; konsistente tatsächliche Kapazität oder ausdrückliche Nichtunterstützung.
• Formationstreffpunkt beim Leader stabil halten; Fehlschlag führt zu lokaler Wiederholung/Diagnose, nicht automatischem Hauptstadtwechsel.
• Anfangsablehnung in GoldenerRose mit genauer Ausführungsdiagnostik reproduzieren.
• Regressionen für vollständige10er-Gruppe/früheAbreise, Treffpunktbindung bei Reisefehler, Stundenwechsel mit ausstehender geteilter Route und20/25-Konsistenz.

Belege: checkpoints/2026-11-01-raid-2200/initial-navigation-failure.log, investigation-console.log, reset-console.log und verified-db.tsv. Server.log enthält die Formation-Fallbacks und Mergefolge. Gameplay/Instanzanreise unbestätigt.

Zusatz: drei Nutzerfragen zu Portalen und Kolonne, ca.23:17–23:21

1. Eisenschmiede: Portalspawn217855/GO195141/Spell65728 ist gebunden an edge1827 portal_use, enabled1/cost1, vonportal_go_217855_source nach portal_go_217855_target (VerwüsteteLande). Renren erreichte Quelle tatsächlich; 23:09:48 folgte laut Log free_flight direkt zurBastion statt portal_use. Start wurde verworfen: no reachable open takeoff point, outdoor0, Diagnosecounter surface/indoor/area/column/mmap/movement=0/0/0/1/63/0. Danach Recovery über virtuelleStraße wird vom safetyAdapter abgelehnt. Also Portalbenutzung in dieser Folge NICHT ausgeführt, keine nachgewiesene native Portalzugangsverweigerung. Replan anQuelle: start->free_flight wiederholt. Plannerportalguard gilt nur isPortalSource && previous enthältCurrentState; Quellknoten alsStartwurzel fällt dadurch aus demGuard. Ein interaktivesPortal teleportiert anders als einAreaTrigger nicht beim bloßenAnlaufen.

2. Sturmwind-Schattenhochland: spawn200627/GO207694/Spell85545, edge1801, Quelle(-8186.15,413.729,116.75), Ziel(-4890.07,-6626.74,10.2846), map0. Enabled1/cost1. DB zeigt KEINE eingehende festeKante zurQuelle. Zurückliegender Livebeleg Elanora16:57:17 benutztPortal nativ mit arrivalError0; Voraussetzungen nicht pauschal alsGrund behaupten. Level80+-AdventureUnlock existiert. Aktuelle Route zumBastioneingang: SWtradecenter->taxi2->taxi6->IFportalQuelle, danach freieFlugplanung/Recovery. Nur dynamischerAnschluss kannSWPortal verbinden (allgemeineBrücken max200yd, Flugkandidaten16/Plan und6/Ursprung). Offline geometrische Kandidatenrangberechnung OHNEArea/Prereq/FlightFilter: SWportalQuelle steht vonSWtradecenter sowietaxi2 sogar aufRang1 der Makrokandidaten. Damit ist reineDistanzsortierung NICHT alsAblehnungsgrund belegt. Es fehlen personenbezogene Logs zu Kandidatenbudget/Estimate-Ablehnung und Folgeverbindung abPortalziel. Exakten verlorenenRoutenvergleich erst mit gezieltemPlantrace behaupten. Keine Runtimeplanung/Teleport zuTest erzwungen.

3. Kolonne: AdventureInteractionMgr kehrt beiBotLed vorGroupTravelMgr::Follow zurück. Botgruppenmitglieder adoptierenExecutorroute (AdoptRoute), teilen also Makroziel/Route, nicht automatisch individuellePositionen. Die allgemeine Formation()/Follow-Steuerung wird dabei nicht verwendet. AdaptRoad läuft nur imStartRecordedEdgePath, nicht für lokaleMMAP-Zuläufe/local_bridge/start. AdaptRoad erhält den gemeinsamenEndpunkt; wennSeitversatz unsicher ist, zweiter Versuch mitside0. Damit kann selbstStraßenadapter aufgleicheLinie zurückfallen. NativeTaxiflüge haben identischen nativenPfad ohne separateKolonnenversätze. EigeneFreeFlight hat sharedTrail mit3.5s+slot*0.6s Startverzögerung nur wenn passenderLeaderflightRecord mit gleichemZiel vorhanden. Kein allgemeiner Abstandsregler über alleReisemodi; keinePortalWarteaufstellung. Nutzerbeobachtung desÜbereinanderlaufens passt zu diesen Integrationslücken; keinBeleg, dass jedeFormationkomponente deaktiviert wäre.

Belege Zusatz: ironforge-portal-route-evidence.log; Sourceprüfung der erwähnten Methoden und nur lesendeWorldDB-Abfragen. KeineBot-/Codeänderung/Build/Restart.