Viano-Core/doc/clientless/group-observation-followups.md

Umsetzung begonnen am 30.10.2026

Die unten dokumentierten Besprechungspunkte wurden anschließend zur Umsetzung freigegeben. Quellcodekorrekturen und Regressionstests sind in Arbeit. Installation und Neustart bleiben ausdrücklich gesperrt, während der Nutzer Routen aufzeichnet. Details und abschließender Prüfstand folgen in 2026-10-30-travel-fixes.md. Native Raid-Zulassung bleibt unverändert.

Nachverfolgung nach dem Gruppentest vom 30.10.2026

Nutzerentscheidung nach dem Bericht:

• Berichtspunkt 1, Gruppenwiederherstellung ohne Gilde: für einen späteren Fix vormerken. Nicht während der anschließenden Besprechung implementieren.
• Berichtspunkt 4, Portalvoraussetzungen in der Routenplanung: ebenfalls für einen späteren Fix vormerken. Native Zugangsbeschränkungen beibehalten.
• Berichtspunkt 5, abgewiesener Raidbeitritt: zunächst als korrekt greifende Instanzbeitrittsbeschränkung behandeln, nicht als zu beseitigenden Fehler.

Erklärung der Transportlücke

Der bestehende Rücktransfer zum aufgezeichneten Deckstand liegt hinter der Deckmodell-Auswahl in ClientlessTransportDeckMgr::Update. Modelle werden nur für Bravery 176310 und Tiefenbahn 176080–176086 geladen. Kraken 190536 fällt vor Rückwegprüfung und ReturnToRecordedStand mit return true heraus. Dadurch startet der Ausstieg direkt, auch wenn der Passagier an einer Zwischenposition steht. Der generelle Fallback ist somit zu eng an die freie Bordnavigation gekoppelt und greift auf Kraken nicht. Dasselbe Modell-Gate ist für andere Transporttypen ohne Decknetz relevant.

Tholgar blieb laut Log mit passenger=1 und Transport-GUID 17 angebunden. Er war nicht nachweislich von Bord gefallen. Der Verlust-Fallback setzt erst beim fehlenden Transport während der Phase Riding Recovering=true. Er ist damit für diesen Fall nicht zuständig. Ein echter Verlust während Boarding/Leaving ist durch diesen Einstieg ebenfalls nicht allgemein abgedeckt; erwartetes Absteigen und versehentliches Fallen müssten dort ausdrücklich unterschieden werden. Nach Failed gibt es derzeit zusätzlich eine Wiederaufnahme des noch angebundenen Passagiers ohne Fortschrittsübernahme des begonnenen Ausstiegs.

Erklärung der Flugprobleme

Flugfähigkeit ersetzt keine Kartenübergänge; dafür werden weiterhin Schiffe, Zeppeline und Portale benötigt. Zusätzlich verlangt der echte Flugstart unter anderem einen lebenden, kampffreien, nicht fahrenden, nicht fallenden Bot im Freien. Das Planungsmodell kann einen Flug vorher bereits als günstig einstufen. Logs zeigen Fehlstarts an Gasthäusern, abgewiesene Abflughöhen und fehlende sichere Landepunkte. Die allgemeine Fehlermeldung unterscheidet nicht alle Startzustände; der exakte Zustand ist daher nicht für jede Ablehnung nachgewiesen.

Für Festung der Stürme sind erfolgreiche letzte Flugabschnitte konkret belegt: unter anderem Nimbin 74 und Noranda 53, je 27 Segmente über 736,81 Yards, FLIGHT_LANDED ... error=0.00, anschließend bestätigter Instanzeintritt. Das belegt einen funktionierenden konkreten Weg, nicht die Zuverlässigkeit sämtlicher Start-, Übergangs- und Landekombinationen anderer Ziele.

Für den nächsten Fix ausdrücklich vorgemerkt

Ein- und Aussteigen von Schiffen

• Den sicheren Rücktransfer zum aufgezeichneten Deckstand unabhängig davon ermöglichen, ob für das Fahrzeug bereits ein freies Decknetz vorhanden ist. Die bestehenden Bedingungen für einen stehenden Transport und eine sichere Passagierbindung beibehalten.
• Einen unterbrochenen Ausstieg beim nächsten geeigneten Halt sinnvoll fortsetzen beziehungsweise zuerst zum normalen Stand zurückkehren. Keine dauernde Wiederaufnahme vom falschen Startpunkt mit derselben Acht-Yards-Ablehnung.
• Verlorene Passagiere auch während Boarding und Leaving erfassen. Einen echten Sturz vom vorgesehenen Absteigen unterscheiden und bei tatsächlichem Verlust die bereits vereinbarte Rettung zum aufgezeichneten Anleger einsetzen.

Durchgängige Instanzanreise flugfähiger Bots und Gruppen

Die Nutzerfrage betrifft die tatsächliche Erreichbarkeit des Ziels, nicht das Vorhandensein der Flugfähigkeit. Für flugfähige Bots müssen Übergänge zwischen Kalimdor, den Östlichen Königreichen, Scherbenwelt und Nordend über die vorhandenen Verbindungen nutzbar sein. Diese Erreichbarkeit ist im nächsten Fix konkret zu prüfen. Bei nicht flugfähigen Horde-Bots sind fehlende Verbindungen zwischen Kalimdor und den Östlichen Königreichen weiterhin eine bekannte Einschränkung.

Überdachungen und ein ungeeigneter erster Landeversuch sind keine ausreichende Begründung, die Reise aufzugeben oder dauerhaft neu zu planen:

• Aus einem überdachten Startbereich zunächst auf gültigem Bodenweg eine erreichbare freie Abflugfläche suchen und ansteuern, anschließend abheben.
• Am Ziel alternative sichere Landeflächen mit validiertem Bodenanschluss zum Instanzeingang suchen. Ein einzelner abgewiesener Punkt darf nicht den gesamten Reiseweg unbrauchbar machen.
• Die Sicherheitsprüfungen für Geometrie, Höhen, Kollisionen, Gebiete und native Voraussetzungen erhalten. Die Suche und Verkettung der Reiseabschnitte verbessern, statt Prüfungen abzuschalten oder normale Reisen durch Teleports zu ersetzen.
• Gruppenanführer und Mitglieder getrennt erfassen: gemeinsame Route, Kartenwechsel, Anschlussverlust, Zielwechsel und Fortschritt müssen erklärbar sein. Die tatsächliche Ankunft am Eingang getrennt von einer anschließend korrekt abgewiesenen Instanzzulassung beurteilen; Berichtspunkt 5 bleibt gültig.

Temporäre Telemetrie für die Untersuchung

Der Nutzer erlaubt für diesen nächsten Fix ausdrücklich temporäre Telemetrie im Code. Sie ist jetzt nur vorgemerkt, noch nicht implementiert. Jede entsprechende Instrumentierung erhält einen eindeutigen Codevermerk, zum Beispiel:

// TEMPORARY_ADVENTURE_TRAVEL_TELEMETRY:
// Remove before development completion / vor Entwicklungsabschluss entfernen.

Erfassen sollen wir mindestens:

• Bot-, Gruppen- und Anführer-ID sowie eine zusammenhängende Reise-/Abschnitt-ID;
• geplantes Instanzziel, tatsächlich verfolgtes Ziel und Gründe für Zielwechsel;
• Graphroute, Kartenübergänge, gewähltes Reisemittel und konkrete Ablehnungsgründe;
• Zustand bei Flugstart: drinnen/draußen, Kampf, Wasser, Fallen, Taxi, Transport, Teleport, Reitfertigkeit, gelernte Berechtigungen und gewähltes Reittier;
• gesuchte Abflug- und Landekandidaten, ihre Bodenanschlüsse und Ablehnungsgründe;
• Fortschritt, Stillstand, Wiederholungen, Zeit pro Abschnitt und Fallbacks;
• erreichten Eingang und das davon getrennte Ergebnis der nativen Zulassung.

Die Erfassung gezielt auf die relevanten Instanz-/Raidanreisen begrenzen und wiederholte identische Meldungen zusammenfassen. Sie soll Ursachen nachvollziehbar machen, ohne erneut pro Tick tausende gleiche Fehlermeldungen zu erzeugen. Vor Abschluss der Entwicklung die temporäre Instrumentierung entfernen und dies als eigenen Abschlussprüfpunkt behandeln.