Wirtschaften-Intent

Technischer Name: economy. Diese Ausbaustufe stellt wirtschaftliche Besuche dar: regulär anreisen, einen passenden Dienstleister aufsuchen, ruhig schauen, reden oder warten, sich verabschieden und den Schalter wieder verlassen. Es gibt keine tatsächlichen Käufe, Verkäufe, Auktionen, Gebote, Banktransfers oder Geldbewegungen. Es werden keine entsprechenden Interaktions- oder Transaktionshandler aufgerufen und keine wirtschaftlichen Fenster simuliert.

Mikroaktionen

Aktion	Ablauf
`economy_repair`	Einen echten reparaturfähigen Händler aufsuchen; nach abgeschlossener Szene sämtliche Ausrüstung kostenlos nativ reparieren. Keine Händlerinteraktion.
`economy_vendor_visit`	Einen freundlichen erreichbaren Händler aufsuchen, kurz umsehen, verabschieden und zurücktreten.
`economy_goods`	Beim Händler länger Waren betrachten. Die Darstellung richtet sich zum tatsächlichen Händler; eine passende Auslage ist keine Voraussetzung.
`economy_trade`	Begrüßen, Handelsgespräch darstellen, zuhören, nicken und verabschieden.
`economy_compare`	Zwei verschiedene erreichbare Händler nacheinander besuchen und Angebote betrachten. Ein einzelner Händler genügt nicht.
`economy_auction_visit`	Einen tatsächlichen Auktionator aufsuchen und das Auktionshaus kurz besuchen.
`economy_auctions`	Beim Auktionator eine längere ruhige Prüfphase darstellen.
`economy_bank_visit`	Einen tatsächlichen Bankier aufsuchen und die Bank kurz besuchen.
`economy_banking`	Am Bankschalter Gespräch und Prüfung darstellen.
`economy_supplies`	Ruhige Prüfung der Vorräte darstellen, ohne Inventarzugriff oder Änderungen.
`economy_wait`	Bei einem passenden Dienstleister auf Bedienung warten. Kein Warteschlangensystem.
`economy_finish`	Einen zuvor besuchten, noch anwesenden Dienstleister verabschieden und den Schalter verlassen.

Ziele und Ausführung

Migration: sql/custom/world/2026_10_27_03_adventure_economy.sql nach den bisherigen Intent-Migrationen. Sie ergänzt Katalogeinträge mit INSERT IGNORE; bearbeitete Definitionen, Gewichte und Positionen bleiben erhalten.

Der Tagesplan entscheidet zuerst anhand des Profils über das Vorhaben. Erst anschließend wählt der Ortsplaner ein passendes vorhandenes importiertes Ziel. Ein fehlender Händler-Eintrag darf den Intent im Tagesplan nicht ausschließen. Siedlungen, Gebiete und bekannte Serviceorte werden für Wirtschaften höher gewichtet; auch andere importierte Orte sind grundsätzlich verwendbar. Ausdrücklich eingestellte Ortsgewichte einschließlich Null behalten Vorrang. Fraktionszuordnung und normale Reiseprüfungen bleiben bestehen.

stormwind_economy_market, stormwind_economy_bank und stormwind_economy_auction sind zusätzliche gezielte Testpunkte. Sie begrenzen weder die Ortswahl noch die Verfügbarkeit des Intents für andere Fraktionen. An jedem anderen passenden Ort findet der Bot die wirklichen Dienstleister über ClientlessPerceptionMgr: Suchradius 100 Yards, native Fähigkeiten, Freundlichkeit, Phase und anschließende geprüfte lokale Annäherung. Dafür müssen keine einzelnen Händler oder deren Aufenthaltsorte vorgegeben werden. Es wird kein Handels-NPC aus einer Datenbankposition nachgespielt.

Die vorhandenen sozialen Fähigkeiten bleiben gemeinsam genutzt. Zielwahl prüft die nativen Rollen VENDOR, BANKER oder AUCTIONEER, Freundlichkeit, Lebendigkeit, Kampfzustand, Phase und den Aufenthaltsbereich. Vor der Annäherung muss der Dienstleister noch nicht vom Ankunftspunkt aus sichtbar sein. Der mögliche Gesprächsplatz und die tatsächliche Szene benötigen eine native Sichtlinie auf Augenhöhe über den Schalter hinweg. Wände bleiben blockierend. Nur ausdrücklich spezialisierte Testpunkte grenzen die Rollen zusätzlich ein: Händler im Marktbereich, Bankiers in der Bank, Auktionatoren im Auktionshaus. Das gilt auch für Warte- und Abschiedsszenen. Andere Bots sind keine Dienstleister. Nicht erreichbare Schalter werden nicht als Besuch gezählt. Die Prüfung bleibt während der Szene aktiv. Händlervergleiche wechseln ausdrücklich zu einer anderen GUID. Wiederholungsdämpfung berücksichtigt Aktionen, Ziele und Textvarianten.

Nach dem Abschied läuft der Bot über MMAP zum Ankunftspunkt zurück. Nur die bestätigte tatsächliche Ankunft erzeugt ECONOMY_VISIT_COMPLETE; ein gescheiterter Rückweg täuscht keinen Abschluss vor. Fehlende Dienstleister lösen eine reguläre Suche nach einem anderen Wirtschaftsziel aus. Das gilt auch, wenn keine der möglichen Serviceannäherungen einen erreichbaren Gesprächsplatz findet. Kampf, Intentwechsel und Offline beenden die Szene über das bestehende Reset-Verfahren.

Der technische Intentname ist auch für manuelle Aufträge und neue Tagespläne verfügbar. activity_affinity.economy steuert die Tagesplangewichtung (Standard 0,5; Arthoran 0,45). Bereits gespeicherte vollständige Tagespläne werden nicht verändert. Lokale Servicewege werden im Gehmodus und innerhalb der Location-Zone ausgeführt. Die Intentauswahl fragt den Ortskatalog nicht ab.

Beispiel für die Testserverkonsole:

clientless adventure intent 26 economy stormwind_economy_market 3600
clientless adventure micro 26 economy_compare
clientless adventure status 26

Die gezielte Mikroaktion setzt einen bereits angekommenen sicheren Bot voraus.

Prüfung

Automatisierte Prüfungen führen die produktive Rollen-/Umgebungswahl und Gestensequenzen aus, einschließlich Rollenverlust, zweitem Händler, verweigerter Navigation und bestätigter Abreise. Der Katalogtest führt die Migration aus und prüft Referenzen, Allianzgrenzen, native Servicevoraussetzungen und Idempotenz. Eine erfolgreiche Kompilierung allein ist keine Ingame-Abnahme.

Live-Prüfung am 27.10.2026

Der Testserver wurde mit -j10 gebaut, installiert und bis zur frischen Ready-Meldung mit lebendem Prozess und Port 8085 geprüft. Alle 29 Clientless-Testskripte bestanden.

Händlervergleich vollständig: Edna Mullby (1286) und Thurman Mullby (1285), unterschiedliche tatsächliche GUIDs, Gesprächspositionen und Gesten, ECONOMY_COMPARE_NEXT, Abreise und ECONOMY_VISIT_COMPLETE visits=2.
Auktionshaus vollständig: Auctioneer Chilton (8670), längere Prüfphase, Abschied, Abreise und bestätigter Abschluss.
Bank vollständig: Scott Westmill (43820) sowie ein automatisch ausgewählter weiterer Bankbesuch; tatsächliche Kundenseite, Abschied und bestätigter Rückweg. Die anfängliche Sichtprüfung auf den Körperpunkt hinter dem Schalter wurde durch geprüfte Annäherung und native Sicht auf Augenhöhe ersetzt. Dabei wird keine Kollisions- oder Sichtlinienprüfung umgangen.
Im finalen Stand wählte Arthoran nach dem Login selbstständig economy_banking bei Thomas Westmill (43822); lokale Wege liefen mit walk=1. Bank-, Händler- und Auktionshausrollen bleiben nach Location getrennt.
Gespeichertes Geld und vollständige Inventarzuordnung einschließlich Gegenstands-IDs und Stapelzahlen waren nach den drei Servicebereichen bytegleich zum Ausgangsstand. Temporäre Login-Profiländerungen wurden zurückgesetzt; der normale Initial-Intent bleibt unverändert.

Die technische Live-Prüfung ersetzt nicht die visuelle Ingame-Abnahme. Weitere Städte und eine Prüfung verschiedener gleichzeitig anwesender Bots sind noch nicht durchgeführt.

Auch der abschließende automatische Bankablauf im finalen Build endete mit ECONOMY_VISIT_COMPLETE action=economy_banking visits=1; anschließend begann selbstständig ein weiterer Besuch bei Newton Burnside (2456).

Korrektur der Planungshierarchie und des Imports

Die anfängliche Einschränkung auf drei Wirtschaftstestpunkte und die davon abhängige Tagesplanauswahl waren falsch. Sie wurden entfernt. Der Ortsimport hatte bereits stattgefunden; zum Diagnosezeitpunkt gab es 2.647 aktive Orte. Ein separater Fehler las SMALLINT-Karten-IDs mit GetUInt32, was im Debug-Core Null ergab. Dadurch wurden unter anderem Kalimdor- und Scherbenweltorte fälschlich Karte 0 zugeordnet. Import und Katalogladen verwenden nun GetUInt16. Die Weltdatenbank-Quelldaten selbst werden nicht geändert.

clientless adventure repairimport ergänzt den normalen Import um eine gezielte Reparatur: Nur Datensätze, deren Quelle, Koordinaten, Kategorie und Metadaten noch den alten automatisch erzeugten Werten entsprechen, werden berichtigt. Manuelle Orte und abweichende Bearbeitungen bleiben erhalten. Karten-, Gebiets-, Regions- und Fraktionsdaten werden neu abgeleitet; bei Wachen-POIs dient ein naher nativer Höhenanker statt der obersten Dachfläche als Bezug. Der normale Import bleibt additiv.

Die gezielte Reparatur wurde auf dem Testserver zweimal ausgeführt. Sie berichtigte 2.159 bestehende automatisch erzeugte Datensätze und ergänzte 217 nun verwertbare Quellorte (insgesamt 2.864 aktive Orte). Alle 16 manuellen Datensätze blieben vollständig unverändert. Der zweite Lauf war bytegleich zum ersten Ergebnis. Orgrimmar und Donnerfels liegen auf Karte 1, Unterstadt auf Karte 0, Silbermond auf Karte 530; alle vier sind als Horde-Orte zugeordnet.

Der abschließende Test nutzte ausschließlich den gewöhnlichen importierten Sturmwind-Ort poi_tele_954: Arthoran nahm über die generische Wahrnehmung einen etwa 68 Yards entfernten Bankier wahr, erreichte ihn über native Navigation im Gehmodus und begann selbstständig eine Bankgesprächsszene. Ein spezieller Bank-Testpunkt wurde für diesen Ablauf nicht verwendet. Build mit -j10, Installation und Neustart waren erfolgreich; alle 30 Clientless-Testskripte bestanden. Eine Reise mit einem Horde-Bot ist dadurch noch nicht ingame geprüft.

Die anschließende Abenteuer-Migration überführt die allgemeinen Wirtschafts- gewichte in ausdrückliche Location-/Intent-Katalogeinträge. Ein im Code versteckter Kategorie-Fallback entfällt damit; vorhandene angepasste Gewichte einschließlich Null behalten Vorrang.

Ergänzung: 2026_10_27_08_adventure_repair.sql ergänzt den Reparaturbesuch. Die vollständige Haltbarkeitswiederherstellung ist die ausdrücklich gewünschte Ausnahme von der rein performativen Wirtschaftsdarstellung.

10 KiB Raw Blame History