Files
Viano-Core/doc/clientless/last.txt
T
Nico 440c53acd7
clang PCH / build (push) Canceled after 0s
GCC PCH / build (push) Canceled after 0s
Validate profession scenes and fix native workstation and area targeting
2026-10-27 18:01:03 +01:00

64 lines
5.8 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
27.10.2026 – Berufs-Ausbau fortgesetzt, gebaut und auf Testserver installiert.
Migration _05 angewendet; 37 Testskripte bestanden. Native Arbeitsplatz-Sichtlinie
und numerische Location-Feldtypen korrigiert. Live: echter Amboss 201415,
Work-Emote 233, Abschluss/Wegtreten; Kräuteraktion verweigert; Geld/Inventar
unverändert. Elwynn als Gebiet über travel_to_node erreicht, sechs lokale
progressive Suchwegpunkte vollständig absolviert. Visuelle Abnahme und echtes
Ressourcenziel in freier Wildbahn offen. Separater Travel-Handover-Loop dokumentiert.
Details: profession-intent.md und SESSION-RESUME.md. Kein Push.
› OK stop, er findet ja den weg schon wieder nicht. Es sieht so aus, als würde er den virtuellen entry auf der Kante sturmwind Hafen - sturmwind gate verwenden. Er reitet diese auch lang aber nach einem Stück bricht er ab. Warum? Er mü…
1. Der Planer bewertet den restlichen Weg zur Taverne zunächst nur anhand der Luftlinienentfernung. Ob MMAP ihn tatsächlich laufen kann, prüft er erst am Ausstieg.
2. Dort scheitert der lokale Anschluss mit PathRejected.
3. Die Fehlerbehandlung sperrt nur diesen einzelnen Ausstiegspunkt. Deshalb wählt der Planer beim nächsten Versuch einen benachbarten Punkt derselben Kante – statt zuverlässig bis zum regulären Endknoten weiterzureisen.
4. Nach fünf Fehlversuchen übernimmt der Adventure-Manager und wählt die Stadtbank als Ersatzort. Dadurch wird das ursprüngliche Tavernen-Ziel aufgegeben.
Das Weiterfahren bis zum echten Knoten fehlt hier als wirksame Rückfallstrategie. Sturmwind Gate und der Greifenmeister werden zwar im Suchlauf geprüft, aber nicht als zwingender nächster Schritt über die weiterhin nutzbare
aufgezeichnete Kante angesteuert.
Beim Fliegen kommt eine zweite Einschränkung hinzu: Die aktuelle Konfiguration lässt gewöhnliche Flugstrecken erst ab 600 Yards zu. Die hier geplanten lokalen Anschlüsse liegen bei ungefähr 260–300 Yards und werden dadurch
ausgeschlossen. Flugfähigkeit allein genügt der aktuellen Auswahl also nicht.
Die Korrektur muss deshalb an der Reiseplanung ansetzen: nach gescheitertem virtuellem Ausstieg die nutzbare Kante bis zum regulären Knoten weiterverfolgen und Flug als Alternative bei blockiertem Bodenweg berücksichtigen. Für die
Taverne wäre dabei ein erreichbarer Landeplatz draußen mit anschließendem Fußweg erforderlich.
Worked for 1m 20s • 07:44
› Das Problem besteht also darin, wie unser Graphmanager alternativen wählt und mit fehlversuchen umgeht. Nach 5 gescheiterten virtuellen Exits die komplette Reise ab zu brechen ist natürlich Unsinn. Auch ist es unsinn, den Bot den
virtuellen exit nur 5 Mal probieren zu lassen, eine bessere Alternative wäre, ihn diesen in einem regulärem Zeitabstand regelmäßig erneut prüfen zu lassen, während der prüfung reitet er weiter zum regulärem Node Ziel, er darf auch auf
einer Kante nicht einfach mitten drinn umkehren, sondern muss zumindest zum nächsten NOde, virtuelle sind hier gleichberechtigt mit den anderen. SO verhindern wir, dass er auf der Strecke hin und herläuft weil er keinen virtuellen
exit findet. In unserem konkreten Beispiel heißt das, Arthoran läuft die reguläre route zum Tor von Sturmwind und prüft regelmäig ob er den virtuellen exit nehmen kann, beim scheitern läuft er weiter bis er irgendwann einen gültigen
virtuellen exit findet oder an der nächsten Node angekommen ist. Außerdem müssen wir bei der Auswahl des freien fliegens die Auswahlkriterien für eine normale Reise von einem Fallback für unerereichbare Ziele behandeln. Grundsätzlich
gilt: der Bot versucht erstmal immer so nah wie er kann an sein Zeil heran zu kommen. Wenn er feststellt, das keine reguläre Route zum Ziel führt, oder die Reise abgebrochen ist und er nicht mehr weiter kommt, dann soll er natürlich
auch das freie fliegen prüfen, ohn Regelen, die wir künstlich für normale Reisen gesetzt haben.
• Ich ändere die Reiseausführung so, dass ein fehlgeschlagener virtueller Ausstieg die laufende Kante nicht mehr abbricht: Arthoran folgt ihr weiter zum nächsten Knoten und prüft unterwegs in festen Abständen neue Ausstiegsmöglichkeiten. Für den freien Flug trenne ich die normale Reisewahl vom Rückfall bei blockiertem Bodenweg; die nativen Flug-, Kollisions- und Landeprüfungen bleiben dabei erhalten.
• Ran git status --short --branch; cat src/server/game/World/ClientlessTravelGraphMgr.h | tail -150; cat src/server/game/World/ClientlessFlightMgr.h
└ };
#define sClientlessFlightMgr ClientlessFlightMgr::instance()
#endif
+ 217 lines (^t to expand)
• Explored
└ Read ClientlessActionExecutorMgr.cpp, ClientlessActionExecutorMgr.h
Read ClientlessTravelGraphMgr.cpp
Read ClientlessFlightMgr.cpp
+ Show details
■ Conversation interrupted - use /feedback if something went wrong
› DU hast wohl Probleme mit der Internetverbindung, probier es nochmal
■ Conversation interrupted - use /feedback if something went wrong
› gut das klappt nicht, ich ahne auch warum. Speicher mal bitte den aktuellen Stand unserer Unterhaltungen und Konversationen so, dass du später ohne Probleme fortsetzen kannst.
■ Conversation interrupted - use /feedback if something went wrong
› A