Viano-Core/doc/clientless/browser-and-pvp.md

AdventureBot-Gruppen, Browser und PvP

Stand: Implementierung gebaut (-j10), alle120Clientless-Tests erfolgreich; noch nicht installiert/live abgenommen. Dungeon-, Raid- und PvP-Intents verwenden die bestehenden Tagespläne. pvp ist neu und wird bei der Profilerzeugung als gewichtete Aktivitätspräferenz angeboten. Bestehende Profile können activity_affinity.pvp ausdrücklich setzen; sonst gilt im Planer ein kleiner, durch Aggression gewichteter Standardwert.

Abreise und Rollen

Dungeon-/Raidbesuche starten selbstständig erst mit vollständiger geeigneter Gruppe. Dungeonrollen:1Tank,1Heiler,3DD. Raidrollen richten sich nach der bestehenden Zielkapazität: bis10Mitglieder2/2/6,20Mitglieder2/4/14, 25Mitglieder2/6/17. Die bereits vorhandenen Kapazitätsgrenzen der Locations bleiben maßgeblich. Profile legen Botrollen fest, Spielerrollen werden aus vorhandenen Gruppenrollen beziehungsweise ihrer Spezialisierung ermittelt.

Die erste tatsächliche Abreise gibt die gesamte Botgruppe für den laufenden Intent frei. Spätere Austritte und Rollenlücken stoppen diese Reise nicht und lösen keinen Browserwechsel aus. Gespeicherte laufende Instanzbesuche werden weiterhin wiederaufgenommen. Spielergeführte Gruppen folgen ihrem Spieler; Bots melden diese Gruppen nicht eigenmächtig an.

Unvollständige Botgruppen und einzelne Bots warten am aktuellen Ort und melden sich bei zulässigem Browser an. Native Prüfungen für Level, Erweiterung, Gegenstandsstufe, Zugänge, Sperren, Rollen und Accountrechte bleiben erhalten. Die lokalen Cataclysm-DBC-Daten enthalten die Drachenseele-Flügel416/417 als Stufe85-Angebote mit2Tanks,6Heilern und17DDs. Ihr TypeID ist1 (Dungeon), die Karte ist jedoch ein Raid. Die Botregeln unterscheiden deshalb anhand der tatsächlichen Karte; sie behandeln diese Angebote nicht versehentlich als Fünfer-Dungeons. Die native Anmeldung dieser Type1-Flügel nutzt die vorhandene Dungeonfinder- Berechtigung, nicht den separaten Legacy-Raidbrowser-Schalter. Der Bot-Schalter für Raidbeitritt bleibt trotzdem anhand der tatsächlichen Raidkarte wirksam. DungeonFinder.OptionsMask wurde nicht verändert. Die Browserwahl verwendet zugängliche Angebote, nicht zwangsläufig das vorher im Tagesplan ausgewählte Reiseziel. Rolle und Angebot werden nativ bestätigt; Vermittlung und Teleport bleiben Aufgaben des vorhandenen Cores.

Schalter

Konfiguration	Standard
Clientless.Browser.Dungeon.QueueEnabled	1
Clientless.Browser.Dungeon.JoinEnabled	1
Clientless.Browser.Raid.QueueEnabled	1
Clientless.Browser.Raid.JoinEnabled	0
Clientless.Browser.Battleground.QueueEnabled	1
Clientless.Browser.Battleground.JoinEnabled	0
Clientless.Browser.AllowBotOnlyTests	0

QueueEnabled erlaubt das Anmelden. JoinEnabled erlaubt es, Bots tatsächlich in eine vermittelte Besetzung aufzunehmen. Bei abgeschaltetem Beitritt bleiben sie in der Suche, werden aber nicht in Angebote für Spieler eingerechnet und reservieren keine Plätze in startenden Partien.

Im Normalbetrieb braucht jede vermittelte Besetzung mindestens einen echten, verbundenen Spieler. Ein nach Verbindungsabbruch noch vorhandener Registereintrag reicht nicht: Die Realm-Verbindung muss offen sein. Die zweite Verbindung darf beim regulären Instanztransfer wechseln. Eine beliebige Person in einer anderen Warteschlange zählt nicht. Prüfung erfolgt vor dem Angebot und vor dem Beitritt erneut. LFG-Gruppen mit Bots erhalten einen echten Spieler als Anführer. Reine Botbesetzungen sind nur mit AllowBotOnlyTests=1 möglich; zusätzlich müssen Queue und Join für den jeweiligen Browser aktiviert sein. Diese Testausnahme ersetzt weder Mindestgrößen noch native Zugangsvoraussetzungen. Vorhandene Low-Population-Regeln des Servers bleiben davon getrennt. Gruppen ohne Clientless-Teilnehmer behalten ihren Ablauf.

Die Regeln sind generische CPC-Admission-Regeln. DungeonFinding und Battlegrounds hängen dafür nicht vom AdventureBot-System ab. Die Adventure-KI wählt lediglich Anmeldungen und Rollen. Keine zusätzlichen externen Dienste oder Netzwerkschnittstellen.

PvP

Ein PvP-Block mit Hauptstadtslocation bedeutet direkte Schlachtfeldsuche. Welt-PvP-Ziele kommen aus zulässigen Gebietslocations von TolBarad/TolBarad-Halbinsel, Höllenfeuerhalbinsel, Zangarmarschen, Nagrand und den Wäldern von Terokkar. Gebietskatalog, Fraktion, tatsächliches Mindestlevel und Fluganforderungen gelten auch hier. Für Welt-PvP genügt eine geeignete Gruppe ab zwei Mitgliedern; fehlen Mitglieder, geht der Bot stattdessen in die Schlachtfeldsuche. Diese läuft über die nativen normalen Schlachtfelder, nicht über Arena oder gewertetes PvP. UnterStufe45 wird Kriegshymnenschlucht angefragt, danach ein zufälliges Schlachtfeld; unterStufe10 erfolgt keine Anmeldung und kein neu generierter PvP-Block. Bei Schlachtfeld-Gruppensuche werden die nativen Levelbereiche der gewünschten Schlachtfeldvorlage verglichen, einschließlich der Mindeststufe für Zufallssuche. Die nativen Prüfungen entscheiden endgültig.

Derzeit geht es um Anmeldung und Beitritt. Spezifische Quest-, Flaggenträger-, Basen- und Bossmechaniken sind damit nicht implementiert. Welt-PvP benutzt zunächst vorhandene Erkundungsaktionen und die bisherigen persönlichkeitsabhängigen PvP-Angriffsregeln. Schlachtfeld-/Raidbeitritt ist daher standardmäßig gesperrt.

Gruppen zusammenführen

Während der Gruppenbildung steigt die Wechselbereitschaft mit der verstrichenen Zeit. Größere passende Botgruppen werden bevorzugt. Auch Mitglieder kleinerer unvollständiger Botgruppen können wechseln, insbesondere um einen offenen Rollenplatz zu besetzen. Offene Einladungen reservieren bereits Rollenplätze; die eigene Reservierung verhindert nicht die Annahme. Überzählige Rollen aus falsch besetzten Gruppen dürfen auch in kleinere passende Gruppen wechseln, und das Vervollständigen einer zulässigen Gruppe hat Vorrang. Bereits abgereiste Anführer schützen auch Mitglieder, deren persönlicher Plan noch Gruppenbildung anzeigt. Ziel und Voraussetzungen der aufnehmenden Gruppe gelten. Die native Einladung/Annahme erfolgt im Worldthread; bei Ablehnung wird die ursprüngliche Gruppe soweit möglich wiederhergestellt.120Sekunden Wechselpause und eine eindeutige Rangfolge gleich großer Gruppen verhindern Pendeln. Spielergeführte Gruppen, volle passende Gruppen, laufende Reisen und bereits laufende Browsergruppen werden nicht automatisch umverteilt. Die feste Sammelfrist am Stundenende wird nicht verlängert.

Validierung und Betrieb

Vor jedem Build Loader/Testannahme pausieren und sicheren Logout abwarten. Während der laufenden Schiffsaufzeichnung darf bei verbleibenden Bots auch nach fünfMinuten kein Shutdown erzwungen werden: Build dann zurückstellen. Installation und Neustart erst nach Freigabe für die Aufzeichnung. Zugehörige Tests: test_browser_admission.py, test_group_role_composition.py, test_adventure_instance_begin.py, test_adventure_groups.py, test_browser_participants.py, test_browser_match_order.py, test_browser_bg_brackets.py. Rollenabfragen werden außerhalb der Versorgungs- und Kampfaktionen beantwortet, nur solange die native Abfrage noch offen ist. Alle120Clientless-Testskripte wurden ausgeführt und bestanden. Sechs ältere Adapter benötigten die neuen Zustandsfelder/Schnittstellen; zusätzliche Assertions prüfen PvP-Persistenz, Browser-Wartephasen, Wiederaufnahme begonnener Reisen und AFK-Schutz während der Suche. Der vollständige CMake-Build und der abschließende inkrementelle Build liefen mit-j10 erfolgreich durch. Beide Config-Dateien wurden auf die vereinbarten Browserwerte geprüft. Details und Logs: doc/clientless/checkpoints/2026-10-31-browser/validation-status.json und regression/final-summary.json. Der vorherige114/120-Lauf samt Fehlerlogs ist als Diagnose erhalten; die behobenen Fälle wurden gezielt erneut ausgeführt.

Der Testserver war nach dem externen Umgebungsneustart bereits offline. Es wurden keine Bots für den Build zwangsausgeloggt, keine laufenden Transporte unterbrochen und kein Server durch diesen Arbeitslauf gestoppt. Loader und TestBot-Ausführung bleiben pausiert (Config0/0); ursprünglicher TestBot-Wert1 ist in resumed-build-state.json gespeichert. Installation/Start erst nach Freigabe. Vor dem nächsten zulässigen Start die sieben zuletzt verbliebenen Bots anhand restart-recovery-needed.json für Zustandsprüfungen vorsehen.

Diese Tests prüfen Regeln und echte extrahierte Produktionsfunktionen mit Adaptern. Ein tatsächlicher Browser-Beitritt mit echten Spielern und die visuelle Abnahme stehen aus. Es wurde weder installiert noch ein Worldserver gestartet.