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.