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.