# Instanzbesuche Stand: 27.10.2026. Verbindliche Nutzervorgaben und Umsetzung des Intents `instance`. Eigenständiger AdventureBot-Intent, getrennt vom offenen Abenteuer und von DungeonBots. Keine Kampf-KI nötig. ## Zeitmodell Die Besuchsdauer ergibt sich aus dem verbleibenden Zeitblock, für den der Instanzeingang als Location gewählt wurde. Es gibt keine zusätzliche volle Aufenthaltsdauer ab Ankunft. Anreise und Vorbereitung verbrauchen Blockzeit. Die letzten fünf Minuten sind für Rückkehr, scheinbare Orientierung und Rast nach dem Besuch reserviert. Nutzerbeispiel: ein Stundenblock, 40 Minuten Anreise, 15 Minuten Aufenthalt in der Instanz, anschließend fünf Minuten Orientierung/Rast draußen. Maßgeblich bleiben absolute Zeitpunkte: Blockende und Beginn der Nachruhe (Blockende minus 300 Sekunden). Serverausfall/Offlinezeit verlängern den Block nicht; ein Neustart startet den Besuch nicht erneut. Noch technisch auszugestaltender Randfall: Ist bei Ankunft bereits die Nachruhephase erreicht, darf kein negativer oder künstlich verlängerter Instanzaufenthalt entstehen. Naheliegende Umsetzung: Eintritt auslassen und verbleibende Zeit zur Nachruhe nutzen. Das ist eine Implementierungsableitung, keine zusätzliche ausdrücklich beantwortete Nutzerentscheidung. ## Sichtbarer und verborgener Ablauf Reguläre Anreise zum Eingang, kurze passende Vorbereitung, tatsächlicher bestätigter Eintritt über den vorhandenen Übergang. Fehlgeschlagener Eintritt startet keine verborgene Aufenthaltsphase. Arthoran wartet direkt hinter dem Eingang in seiner nativen Instanzkopie. Er durchläuft den Dungeon nicht, kämpft nicht und simuliert keine Beute oder Erfolge. Unabhängige Spieler/Gruppen sollen ihn beim eigenen Eintritt nicht sehen. Native Instanzzuweisung und vorhandene Bindungen beachten; bloß die Karten-ID zu vergleichen genügt nicht, die Instanz-ID ist ebenfalls relevant. Keine gemeinsame Bot-Gruppe oder sonstige geteilte Bindung für diesen Solobesuch neu erzeugen. Bestehende DungeonBots bleiben unabhängig. Beim Neustart loggt er am gespeicherten Instanzstandort wieder ein und wartet nur bis zum ursprünglichen Rückkehrzeitpunkt. Dazu müssen Besuchsphase, Blockende, Instanz-/Eingangs-/Ausgangszuordnung erhalten bleiben; ist der Zeitpunkt inzwischen verstrichen, folgt die Rückkehr ohne neue Wartezeit. ## Orte und Rückkehr Die Instanzinnenräume werden keine normalen Aufenthaltslocations. Die vorhandenen Eingangs-/Ausgangsknoten des TravelGraph liefern die Übergänge; der Außenwelteingang ist das wählbare Reiseziel. Hat die Instanz einen eigenen Ausgang, ergibt sich die Rückkehrposition aus diesem Ausgang. Fehlt ein gesonderter Ausgang, erfolgt die Rückkehr am Eingang. Kein willkürlicher Stadt-/Heimatteleport. Ein entfernter Hinterausgang benötigt bei abstrahiertem Aufenthalt eine ausdrückliche technische Rückkehrbehandlung; eine vollständige MMAP-Durchquerung des Dungeons ist nicht Teil des Auftrags. ## Bestätigte Daten und bestehender Core Die Test-World-DB `areatrigger_teleport` enthält lesbare Bezeichnungen: | Trigger | Name | Zielkarte | Zielposition | |---|---|---|---| | 78 | Deadmines Entrance Target | 36 | -14.5732, -385.475, 62.4561 | | 119 | Deadmines Exit Front Target | 0 | -11208, 1676.41, 24.5716 | | 121 | Deadmines Rear Exit Target | 0 | -11341, 1576.55, 93.7284 | Alle sechs Knoten `portal_at_{78,119,121}_{source,target}` sind bereits in `vcore_clientless_travel_node` vorhanden. Ihre Kommentare enthalten derzeit nur `Auto-imported AreaTrigger source/target`. Die semantischen Namen bleiben in der nativen World-Tabelle verfügbar. Quelle der Triggerpositionen ist zusätzlich `AreaTrigger.dbc`; Quelle/Zielkarte dienen zur belastbaren Richtungszuordnung. Namen sind Hinweise, keine alleinige Zugangsfreigabe. `MapManager::CreateMapForPlayer` verwendet vorhandene Spieler-/Gruppenbindungen und sonst eine neue Instanz-ID. Bei Login wird eine gespeicherte Instanz-ID nur mit verfügbarer Karte beziehungsweise passender Instanzspeicherung wiederhergestellt. `InstanceMap::AddPlayerToMap` erzeugt native Instanzspeicher und Solobindungen. Neustart und abgelaufene Instanzspeicherung müssen deshalb auch mit einem echten Wiederanmeldetest geprüft werden. Vor diesem Ausbau erzeugte `AdventureBehaviorMgr::Online` einen neuen flüchtigen Record und startete gegebenenfalls das Lua-Initialintent. Jetzt hat die dauerhafte Wiederaufnahme des Besuchs davor Vorrang. Der Phasen-/Persistenzplan und die gezielten Tests sind im folgenden Implementierungsabschnitt beschrieben. Der historische Datenbefund allein belegt keine Gameplay-Abnahme. ## Implementierung und Bedienung Der Verhaltensmanager führt feste Phasen statt zufälliger Dungeon-Mikroaktionen aus: Anreise, zehn Sekunden Vorbereitung am echten Eingang, Eintritt, Aufenthalt, Rückkehr und Nachruhe. Es gibt keine Kampf-/Beute-/Dungeon-Routenlogik. Eine zu späte Ankunft überspringt den Eintritt und nutzt die verbleibende Zeit zur Rast. Während eines Aufenthalts wird ein Intentwechsel erst nach der Rückkehr ausgeführt. Die ursprüngliche Besuchsfrist wird dadurch nicht verlängert. `sql/custom/world/2026_10_27_07_adventure_instances.sql` erzeugt aus vorhandenen nativen Teleporten, Instanzvorlagen und Graphquellknoten Außenwelt-Eingangsorte `instance_visit_at_` sowie einen editierbaren Zuordnungskatalog `vcore_adventure_instance`. Auf der Test-DB ergaben sich 108 Eingangsaliase. Die alten Portalpunkte/Graphknoten bleiben unverändert. Instanzkarten werden weiterhin nicht als normale Aufenthaltsorte ausgewählt. `exit_trigger=0` lässt den Laufzeitadapter einen passenden nativen Ausgang zur Außenkarte des Eingangs suchen. Benannte Hinterausgänge haben Vorrang vor dem Vorderausgang; Quelle/Zielkarte und vorhandene Graphknoten werden geprüft. Eine ausdrückliche Triggerzuordnung im Katalog hat Vorrang vor der Namensheuristik. Native Zugangsbedingungen bleiben wirksam. Gruppierte Bots sowie bereits mit anderen Spielern oder Gruppen geteilte Instanzbindungen werden zurückgewiesen. Die verborgene Durchquerung bis zu einem entfernten Ausgang wird abstrahiert: Am Rückkehrzeitpunkt wird innerhalb derselben Instanzkopie zum realen Ausgangstrigger umgesetzt und dessen nativer Handler ausgeführt. Das ist kein behaupteter MMAP-Lauf durch den Dungeon. Ohne Ausgang oder bei nativer Wiederanmelde-Rettung aus einer abgelaufenen Instanz wird die zugeordnete Außenposition verwendet. Ein verweigerter Ausgang gilt nicht als Rückkehr. Nach bestätigter Rückkehr wird einmal ein bei Besuchsbeginn gezogener Zufallswert von 0–50 Prozent der maximalen HP dargestellt. Bei vorher voller Gesundheit bleiben 50–100 Prozent HP. Bereits vorhandene Verletzungen werden nicht geheilt; die Darstellung tötet den Bot nicht. Normale Regeneration bleibt aktiv. Der Wert wird gespeichert und beim Neustart nicht neu gewürfelt. Die additive Charakter-Migration `sql/custom/characters/2026_10_27_00_adventure_instance_visit.sql` speichert Besuchsphase, absolute Frist, Trigger, Instanz-ID und Verletzungsmarker. Charakterzustand und Besuchsphase/Verletzungsmarker werden gemeinsam über die native asynchrone Transaktionsverbindung gespeichert. Erst deren bestätigter Abschluss erlaubt das Fortschreiten. Die synchrone Verbindung kann die ASYNC-only-Statements des nativen Charakterspeichers nicht ausführen. Ein WorldScript im optionalen Adventure-Skript meldet beim Serverstart nur Charaktere mit gespeichertem Besuch erneut mit dem Adventure-Controller an. Die Wiederaufnahme hat Vorrang vor dem normalen Lua-Initialintent. Fehlt die Besuchstabelle, bleibt diese Wiederanmeldung inaktiv; andere Clientless-Systeme werden davon nicht abhängig. Serverkonsole: ```text clientless adventure intent 26 instance instance_visit_at_101 3600 clientless adventure status 26 ``` Trigger 101 ist das Verlies in Sturmwind, Trigger 78 die Todesminen. Der Tagesplan kennt `instance` mit eigener Intentgewichtung (Standard 0,5); bestehende gespeicherte Tagespläne werden nicht umgeschrieben. Regressionen: `test_adventure_instance_begin.py` prüft die produktive Anreise über den vorhandenen Ortsplaner mit lokalem MMAP-Anschluss; `test_adventure_instance.py` führt den produktiven Phasenablauf mit nativen Übergangsadaptern aus; `test_adventure_instance_catalog.py` führt die Migrationen auf Schemafixtures aus; `test_adventure_instance_persistence.py` führt produktives Speichern/Wiederherstellen mit Transaktionsadapter aus; `test_adventure_instance_autoresume.py` führt das tatsächliche Startup-Skript aus. ## Technischer Live-Test am 27.10.2026 - Debug-Build mit `-j10` und Installation erfolgreich. Abschließender vollständiger Lauf: **44 Testskripte bestanden**, Log `/tmp/vcore-instance-tests-final.log`. - Beide Migrationen auf Test-DB angewendet; Collation der neuen Tabellen stimmt mit `utf8mb4_unicode_ci` der vorhandenen Ortsdaten überein. 108 neue Aliase, insgesamt 2.973 geladene Locations / 3.966 Worldpoints. - Die anfängliche Instanzanreise über den isolierten Portalnode führte in vorhandene Graph-Recovery-Schleifen. Die Anreise verwendet jetzt den bestehenden Ortsplaner mit lokalem MMAP-Anschluss. Auch dort trat auf dieser Strecke eine bestehende Graphschleife auf. Dieses Reiseproblem wurde ausdrücklich nicht repariert. **Die reguläre Fernanreise ist nicht erfolgreich live verifiziert.** - Für den isolierten Instanztest wurde ausschließlich der ausgeloggte Testbot administrativ am echten Außenwelt-Knoten `portal_at_101_source` positioniert (-8761.85, 848.557, 87.8052). Danach liefen lokaler MMAP-Anschluss, zehn Sekunden Vorbereitung und der tatsächliche native Trigger 101 regulär. - `INSTANCE_ENTERED guid=26 map=34 instance=1` bestätigt das Verlies. Gespeicherter Charakterstand direkt hinter dem Eingang: (48.9849, 0.483882, -16.3942). - Echter geordneter Serverneustart während Phase 3. Der Startup-Hook meldete Arthoran automatisch mit normalem Lua-Profil wieder an; `INSTANCE_RESUME` bestätigte erneut Karte 34, **Instanz-ID 1**, dieselbe absolute Frist und unveränderten Verletzungsmarker. Keine manuelle Anmeldung für diesen Restart. - Für die zeitnahe Rückkehrprüfung wurde nach sauberem Serverstopp nur das gespeicherte Blockende des bestätigten Innenaufenthalts auf einen verkürzten Testblock gesetzt. Ursprünglicher Wert in `/tmp/vcore-instance-live-original-deadline.tsv`. Der Produktivablauf verlängert oder verkürzt normale Nutzerblöcke nicht. - Rückkehr über nativen Ausgang 503 auf Karte 0, Position (-8766.11, 845.499, 87.9952). Zuerst zweimal gültiger Zufallswert 0 Prozent; ein weiterer regulär gestarteter sechsminütiger Testblock ergab **17 Prozent**: `INSTANCE_RETURNED ... lossPercent=17 health=2165 maxHealth=2609`. Die Charakter-DB bestätigte gleichzeitig Phase 5, `injury_applied=1` und 2165 HP. - Erneute Anmeldung während der Nachruhe bestätigte `INSTANCE_RESUME phase=5`, dieselbe Frist und `injuryApplied=1`, ohne Neuwurf oder erneute Verletzung. Normale Gesundheitsregeneration bleibt aktiv. Nachruhe wird bei neuem explizitem Auftrag sauber beendet; die ersten beiden Nachruhen wurden für die weiteren Tests bewusst unterbrochen. - Normales Profil in Quelle und Installation ist bytegleich restauriert (SHA256 `26b11c3108e6ecc5dbc59d1852b4103ca4e818148603a34c02a470c969dc659b`). Keine temporären Lua-Overrides. Geld/Inventar nach abschließendem `saveall` unverändert: SHA256 `8d40931782d05219466ba9fd077ce7acd3e02bd53eb63f6e96115042c620d26a`. Beim ersten Liveversuch wurde ein falscher Transaktionsweg erkannt: nativer Charakterspeicher plus synchrone Verbindung führte zum Debug-Abbruch. Dieser Fehler ist behoben: `AsyncCommitTransaction` führt die native Transaktion auf der passenden Worker-Verbindung aus und liefert den bestätigten Abschluss zurück. Regression und nachfolgende echte Speicher-/Neustarttests bestanden. Historisches Fehlerlog: `/tmp/vcore-instance-first-live-DBErrors.log`. Der Nutzer verzichtet ausdrücklich auf eine weitere visuelle Abnahme. Ein echter Todesminen-Hinterausgang und zwei voneinander unabhängige gleichzeitig betretene Instanzkopien wurden noch nicht live getestet; Quell-/Zielzuordnung, geteilte Bindungssperre, Hinterausgang und fehlender Ausgang sind durch produktive Adaptertests abgedeckt.