OpenFront-Lobby-Pools: OpenFront.io Schritt-für-Schritt-Guide

Direkte Antwort

Ein Lobby-Pool ist eine Gruppe von zwei bis acht identischen Lobbys, die ein Host auf einen Schlag erstellt; nur das erste erscheint in der öffentlichen Liste. Wenn du diese gelistete Karte beitretest, wählt der Server ein Geschwister-Lobby für dich über einen deterministischen Hash deiner persistenten Identität und sendet eine Umleitung, der dein Client automatisch folgt. Du wirst nur als neuer Beitreter geroutet: Spieler, die sich erneut verbinden, Zuschauer, Spieler auf der Whitelist und Admins bleiben in ihrem Lobby. Die Funktion wurde in v0.34.19 (2026-09-25) angekündigt, funktioniert aber erst ab v0.34.20 (2026-09-26) tatsächlich. Wenn du in ein Geschwister-Lobby ohne deinen Freund landest, hat die Umleitung bereits einmal stattgefunden — lade das ursprüngliche gelistete Lobby neu und versuche es erneut.

Die praktische Abfolge hinter dieser Antwort ist es wert, im Detail erklärt zu werden, denn sie erklärt jedes Symptom in diesem Leitfaden. Du klickst die aufgelistete Karte an, der Client öffnet eine Verbindung zum Einstiegsraum, und bevor der Einstieg mit „frei” oder „voll” antwortet, führt der Server eine Klassifizierung aus: Zu welchem Pool gehört dieser Spieler? Wenn er einem Pool angehört, berechnet der Server den Hash deiner Identität, wählt die Geschwister-Karte aus diesem Hash und schickt dich direkt dorthin — du siehst die vollständige Liste des Einstiegs währenddessen nie. Diese Reihenfolge ist entscheidend, denn sie zeigt, dass Pool-Routing kein zusätzliches Tor „nach” dem Einstieg ist, sondern die allererste Klassifizierung deines Join-Versuchs. Das erklärt mehrere Gegenintuitionen: Wenn du „weitergeleitet” wirst, bist du nicht zuerst in den Einstieg gegangen und wurdest dann zurückgewiesen; die Geschwister-Karte, in der du landest, ist genau die, die der Server für dich gewählt hat; und der Begriff „Weiterleitung” ist eigentlich ungenau — du warst nie im Raum der Karte, die du gesehen hast, du bist direkt in deren Geschwister-Karte gegangen. Sobald man das verstanden hat, wandelt sich die Antwort auf „warum bin ich in einen anderen Raum geraten” von „das ist ein Bug” zu „das Pool-Routing funktioniert wie vorgesehen”, und deine einzige Aufgabe ist es, zu bestätigen, dass dieser Raum tatsächlich eine Geschwister-Karte dieses Pools ist (gleicher Modus, gleiche Karte, gleicher Countdown), statt einen nie stattgefundene Verbindungsfehler zu suchen. Das ist auch der Ausgangspunkt jedes Fehlerschritts in diesem Leitfaden: zuerst bestätigen, dass du Pool-Routing und keine Trennung/Wiederjoining oder Anti-Cheat-Ausweitung siehst, dann entscheiden, ob du handeln musst.

Diese Antwort gilt für das Verhalten ab v0.34.20, das die aktuelle Produktion ist. Wenn du sie auf einer älteren Version liest oder ein älteres Video siehst, das Pool-Verhalten beschreibt, prüfe zuerst die Versionsnummer, denn die Grenze zwischen „angekündigt” und „funktioniert” ist die einzige Stelle, an der dieselbe Frage eine andere Antwort hat.

Warum eine gelistete Karte mehrere Lobbys sein kann

In allen Versionen vor v0.34.19 war eine Lobby-Karte aus dem öffentlichen Browser genau ein Lobby: eine Spielerliste, ein Start-Countdown, eine Rauminstanz. Wenn dieser Raum voll oder nicht offen war, sagte es der Server und du bliebest im Browser. Ab v0.34.19 kann ein Host, der ein gelistetes Lobby über die Pool-Admin-Route erstellt, bis zu sieben Geschwister-Lobbys auf einmal erzeugen, alle mit der Konfiguration des Eingangs teilend. Die öffentliche Liste zeigt weiterhin genau eine Karte — den Eingang — weil die Identifikatoren der Geschwister als Verbindungsgeheimnisse behandelt werden und der Server sie aus jedem lobby_info-Frame entfernt, den er an Clients sendet. Was sich ändert, ist, was passiert, wenn du auf Beitritt klickst: Statt für einen einzigen Raum „voll“ oder „offen“ zu beantworten, fragt der Server jetzt, welches Mitglied einer kleinen Gruppe von Räumen dich aufnehmen soll.

Diese Gestaltung löst ein reales Problem, das Spieler vor Pools gemeldet hatten. Die öffentliche Lobbyliste ist dünn; Community-Fäden fragten regelmäßig nach einer filterbaren Liste und beschwerten sich, dass das Warten auf ein gelistetes Spiel zwanzig Minuten oder länger dauerte. Eine einzelne gelistete Karte, die eine ganze Menschenmenge in acht Räume aufnimmt, ist eine Kapazitätslösung, die den Browser überhaupt nicht ändert: Die Karte sieht identisch aus, derselbe Modus, dieselben Modifikator-Chips, derselbe Countdown, aber die effektive Raumgröße wird vergrößert. Das ist der Zweck von Pools in einem Satz — und genau deshalb ist die Funktion unsichtbar, bis du feststellst, dass das geladene Lobby nicht das Lobby ist, das dein Freund geladen hat. Für den Kontext darüber, was die öffentliche Karte selbst verspricht — Modus, von der Wahl des Hosts ab 1 bis 5 Minuten Start, Kapazität 10 bis 100 Spieler und das Abonnement-Grenzlevel zum Hosten — lies den Guide zu öffentlichen Lobbys. Wenn die Karte, die du listen möchtest, hinter einem Paid-Plan liegt, deckt der Guide zu öffentlichen Sonder-Lobbys das Grenzlevel ab, das entscheidet, ob du überhaupt ein gelistetes Lobby erstellen kannst.

Die Mechanik ist bewusst in eine Richtung. Der Server kann einen Beitreter vom Eingang zu einem Geschwister routen, und er kann auch einen Beitreter, der direkt auf ein Geschwister trifft, neu im Pool verteilen, um die Last zu glätten — aber er verschiebt niemals Spieler, die bereits in einem Lobby sind, und er legt die Gruppe der Geschwister niemals Clients gegenüber offen. Es gibt keine Pool-Mitgliederliste im Spiel, kein „Pool aus 8“-Badge auf der Karte und keinen Weg, die Geschwister zu durchlaufen. Die einzigen beobachtbaren Effekte sind, wo du auftauchst und in welcher Spielerliste du landest.

Wie der Server dein Geschwister auswählt

Die Routing-Funktion ist klein und vollständig deterministisch: Ein Hash deiner persistenten Identität, gemischt mit dem Pool-Identifikator selbst, modulo die Anzahl der Geschwister. Explizit geschrieben berechnet der Server index = hash(poolId + ":" + deinePersistenteIdentität) % anzahlGeschwister und sucht dann das Geschwister an diesem Index in der geordneten Pool-Liste. Wenn dieser Index dem Lobby entspricht, das du bereits angesprochen hattest, wird die Umleitung vollständig ignoriert und du trittst dem Raum bei, den du anklickst — ein Pool zwingt also nicht jedem eine Umleitung auf, sondern nur den meisten Beitretern.

Zwei Eigenschaften dieser Formel zählen für das Gefühl der Funktion. Erstens wird der Pool-Identifikator vor dem Modulo gemischt, was bedeutet, dass derselbe Spieler, der auf zwei verschiedene Pools derselben Größe zeigt, unterschiedliche Ordnungsnummern erhalten kann: Du bist nicht in allen Pools gleicher Größe „immer Lobby 3“ festgefahren. Zweitens ist der Hash pro Spieler stabil, also wirst du in einem gegebenen Pool immer zum selben Geschwister geschickt, solange sich die Pool-Größe nicht ändert. Du kannst nicht durch Neu-Spielen für ein anderes Lobby neu würfeln, weil der Hash-Eingang bei erneutem Beitritt nicht wechselt. Was den Eingang verändert, ist die Pool-Größe: Ein Host kann weder nach der Erstellung Geschwister hinzufügen noch entfernen, aber zwei Pool-Gruppen unterschiedlicher Größe verteilen denselben Spieler unterschiedlich.

Weil der Hash aus einer stabilen Spieleridentität berechnet wird, ist das Routing auch in einer Weise konsistent, die für Team-Lobbys zählt: Der Server trennt Teamkollegen nicht absichtlich und zerbricht nie eine bestehende Liste, weil Neu-Verbindungen befreit sind (siehe nächste Abschnitt). Was er tut, ist neue Beitreter zu verteilen. Ein Pool aus acht verhält sich also wie eine einzelne Karte mit acht Listen: Die ersten Beitreter landen jeweils in einem anderen Geschwister, und nach der ersten Runde ist die Verteilung das, was der Hash sagt. Es gibt keine „Raum 1 füllen, dann Raum 2“-Reihenfolge — das Modulo bevorzugt nicht den ersten leeren Raum, sondern ein deterministisches Bucket. Deshalb kann ein Pool im selben Moment ein Geschwister fast voll und ein anderes fast leer haben, und deshalb solltest du die Spielerzahl auf einem Geschwister nicht als Signal für die Gesamtbelegung des Pools lesen.

Die Umleitung selbst ist ein Kontrollframe, kein Lobby-Frame. Der Server sendet eine Nachricht vom Typ redirect mit dem Ziel-Lobby-Identifikator, und er sendet sie vor jeder Antwort auf Voll oder Gelaufen. Im Server-Code ist der Kommentar zu dieser Reihenfolge explizit: Gerouted zu werden ist keine Ablehnung. Diese Unterscheidung ist die wichtigste Tatsache, um Bounces zu interpretieren, weil es bedeutet, dass ein „du wurdest woanders hingeschickt“-Ergebnis und ein „dieses Lobby ist voll“-Ergebnis zwei verschiedene Server-Entscheidungen sind, und dass ein Spieler-Fehler nach einem Umleitungsversuch im Verhältnis zum Umleitungspfad zu diagnostizieren ist, nicht zum vollen-Lobby-Pfad.

Wer geroutet wird, und wer nicht

Der Beitrittspfad führt die Pool-Prüfung in fester Reihenfolge aus, und diese Reihenfolge definiert die Befreiungen. Erstens prüft der Server, ob der beitretende Client bereits als Spieler in der Ziel-Liste existiert: Wenn ja, ist das Spiel eine Neu-Verbindung und die Pool-Logik wird ignoriert. Zweitens prüft der Server Rollen und Listen: Ein Admin, der das Lobby betritt, ein Spieler auf der Whitelist des Lobbys und ein Client, dessen Rolle Zuschauer ist, umgehen alle die Umleitung. Drittens berechnet der Server für alle anderen, die wirklich neu sind in der Liste, das Hash-Ziel und emittiert, wenn es vom angesprochenen Lobby abweicht, die Umleitung.

Praktische Konsequenzen zum Merken:

Neu-Verbindungen werden nie neu geroutet. Wenn du während eines Spiels getrennt wirst und zum selben Lobby zurückkehrst, landest du dort, wo du warst. Der Server erkennt dich in der bestehenden Liste, bevor die Pool-Prüfung stattfindet, und diese wird ignoriert. Das „ich wurde ins Menü geschickt und habe neu gespielt“-Erlebnis ist also niemals eine Pool-Umleitung; Kicks und Trennungen sind eine andere Fehlerklasse, behandelt außerhalb des Pool-Routings.
Zuschauer sind fest. Das Aktivieren des Zuschauermodus im Eingang eines Pools wird abgelehnt, wenn das Hash-Ziel ein anderes Mitglied ist: Du kannst nicht im Lobby zuschauen, in dem du als Spieler geroutet worden wärst. Du schaust exakt das Lobby zu, das du ansprichst.
Whitelist schlägt Pool. Ein Spieler auf der Whitelist des Eingangs tritt dem Eingang selbst bei, egal was der Hash sagt. Wenn du und ein Freund im selben Raum in einer Pool-Umgebung sein wollt, ist der einzige unterstützte Mechanismus die Whitelist.
Admins sind fest. Personal, das den Eingang eines Pools betritt, bleibt im Eingang, damit Betreiber die Eingangskarte überwachen können, ohne über den Pool verstreut zu werden.
Neue Beitreter werden verteilt. Alle anderen — der normale Fall — werden auf eines der Geschwister gehasht.

Eine weitere Asymmetrie: Die Umleitung erfolgt nur in den Pool für neue Beitreter. Der Server verschiebt nie einen Spieler von einem Geschwister zum anderen, während sich die Listen füllen, es gibt also kein „Nachfüll“-Verhalten, das einen Spieler aus einem Lobby zieht, in dem er bereits ist. Der Pool verteilt Beitreter an der Tür; sobald du drin bist, bist du drin.

Ein konkretes Beispiel, das die Reihenfolge greifbar macht. Stelle dir vor, du bist Zuschauer und klickst auf eine gelistete Karte, die ein Pool mit sechs Geschwistern ist. Der Server rechnet deinen Hash aus und dein Ziel ist Geschwister drei. Weil du als Zuschauer beitrittst, löst sich die Zuschauer-Befreiung aus und der Server lehnt deinen Zuschauerauftrag ab, bevor er dich in Geschwister drei schickt. Du siehst also keine Fehlermeldung im Stil „Weiterleitung abgelehnt”, sondern eine einfache Absage: du kannst in dem Raum zuschauen, den du angesprochen hast, und nicht in dem, in den der Hash dich als Spieler geschickt hätte. Das ist ein Verhalten, das du einmal testen kannst und danach nie wieder erklären musst: Wenn du als Zuschauer in eine gelistete Karte gehst und der Raum dich akzeptiert, war der Hash-Zufall in deinen Vorteil gegangen, oder der Raum war kein Pool. Wenn der Raum dich ablehnt, weißt du, dass ein Pool existiert und dass die Zuschauer-Befreiung funktioniert. Dasselbe Prinzip gilt für die Admin-Rolle: Ein Admin, der die gelistete Karte betritt, bleibt immer im Eingang, und wenn du als Host beobachtest, dass ein Admin in einer gelisteten Karte immer im selben Raum bleibt, während normale Spieler verteilt werden, ist das der visuelle Beweis, dass die Rollen-Befreiung vor dem Hash läuft. Beide Beispiele sind nützlich, weil sie dir zeigen, dass die Befreiungen keine abstrakten Regeln sind, sondern sichtbare Unterschiede im Verhalten, die du mit einem einzigen Testspiel prüfen kannst. Die praktische Konsequenz für deinen eigenen Spielstil ist, dass du die Reihenfolge im Kopf behalten solltest, wenn du ein „verwunderliches” Verhalten siehst: Wenn du als Zuschauer abgelehnt wirst, ist das die Rollen-Prüfung, nicht ein Verbindungsproblem. Wenn du als Admin im Eingang bleibst, ist das die Rollen-Prüfung, nicht ein Routing-Fehler. Wenn du als normaler Spieler in ein Geschwister gehst, ist das der Hash, und wenn du in dasselbe Lobby zurückkehrst, in dem du warst, ist das die Neu-Verbindungs-Prüfung. Vier sichtbare Verhaltensmuster, vier verschiedene Schritte in der Prüfreihenfolge, und wenn du sie erkennst, weißt du sofort, welchen Schritt der Server gerade ausgeführt hat, ohne den Code lesen zu müssen.

Die Versionsgrenze: v0.34.19 kündigt an, v0.34.20 funktioniert

Die Geschichte der Funktion ist zwei Versionen dick, und die Grenze zählt, weil beide Versionen unterschiedliche Dinge behaupten. Die Versionsnotizen v0.34.19 (veröffentlicht am 2026-09-25) kündigen die Funktion an: Ein gelistetes Lobby kann Beitreter über einen Pool von Geschwister-Lobbys verteilen. Die Versionsnotizen v0.34.20 (veröffentlicht am 2026-09-26) liefern dann die Korrektur: Lobby-Pools, die in der Produktion nie gebildet wurden, werden jetzt gebildet, und gelistete Lobbys können tatsächlich Beitreter zwischen Geschwister-Lobbys verteilen. Der zweite Punkt existiert, weil die erste Version Code lieferte, der in der Produktionsumgebung keine funktionalen Pools erzeugte; zwischen den beiden Versionsdatierungen war der Routing-Code auf dem Server vorhanden, aber es wurden effektiv keine Pools erstellt.

Drei Konsequenzen ergeben sich daraus. Erstens sind alle Community-Berichte oder Streams im v0.34.19-Fenster, die „Pools funktionieren nicht“ sagen, konsistent mit dem Versionsprotokoll, kein Bug-Bericht gegen v0.34.20. Zweitens ist das Produktivverhalten, das du in diesem Guide liest, das v0.34.20-und-später-Verhalten; wenn du einen älteren Guide liest oder ein älteres Video ansiehst, das das Pool-Verhalten beschreibt, prüfe dessen Versionszeile, bevor du ihm vertraust. Drittens stammen die Pool-Größenbeschränkung von zwei bis acht, das nur-eingeliste-Eingangs und das bei-der-Erstellung-fixierte Konfiguration allesamt aus derselben Code-Revision, die v0.34.20 lieferte, also ist jede Zahl in diesem Guide eine v0.34.20-Zahl.

Die Konfiguration selbst ist auf eine zweite, stillere Weise an die Version gebunden: Der Pool-Block ist nur bei der Erstellung. Der Lobby-Korrektur-Route kopiert kein pool-Feld, was bedeutet, dass ein Host Geschwister nicht zu einem bestehenden gelisteten Lobby hinzufügen oder einen Pool nach der Erstellung neu dimensionieren kann. Wenn du einen Pool willst, erstellst du den Pool zu Beginn; es gibt keinen In-Game-Upgradepfad von „einzelnem gelisteten Lobby“ zu „gelistetem Lobby mit sieben Geschwistern“. Das ist eine Designentscheidung, keine fehlende Funktion: Die geteilte automatische Startfrist und die geteilte Konfiguration machen den Pool zu einem einzigen atomaren Objekt, und das Versionsprotokoll enthält keine spätere Version, die den Pool-Block über die Korrektur-Route an der hier dokumentierten Versionsgrenze erweitert.

Was die Versionsgrenze für deinen eigenen Client praktisch bedeutet, denn die wichtigste Frage ist nicht „welche Version hat das Feature eingeführt”, sondern „welche Version hat das Feature in der Produktion zum Laufen gebracht, und bin ich auf dieser Version oder neuer”. Die Antwort ist v0.34.20. Wenn dein Client auf v0.34.19 oder früher ist, existiert das Feature für dich nicht: Pools werden gebildet, aber sie funktionieren so, dass du sie nie siehst, und jede gelistete Karte verhält sich wie ein einzelnes Lobby. Wenn dein Client auf v0.34.20 oder neuer ist, sind Pools vollständig aktiv und jedes gelistete Lobby kann ein Eingang sein. Der praktische Test ist eine Versionsprüfung, die dreißig Sekunden dauert: Öffne die Spielmenü-Einstellungen, suche die Versionsnummer, und vergleiche sie mit v0.34.20. Wenn deine Nummer kleiner ist, ist jeder „ich wurde weitergeleitet”-Bericht, den du liest, für dich nicht anwendbar, und die einzig sinnvolle Aktion ist ein Client-Update. Wenn deine Nummer v0.34.20 oder höher ist, sind alle Behauptungen in diesem Guide auf deinen Client anwendbar, und du kannst das Feature beobachten, wie es beschrieben wird. Es gibt keinen dritten Fall: Kein Client-Update, das das Feature halbkann, und kein Build, das das Feature hat, aber es nicht anzeigt. Die Grenze ist binär, und das macht die Versionsprüfung zu der einzigen Prüfung in diesem Leitfaden, die du vor allem anderen machen solltest. Wenn du nach einem Update auf eine neue Version gehst und plötzlich merkst, dass gelistete Karten sich anders verhalten, ist das kein Bug, das ist die Versionsgrenze, die du gerade überschritten hast. Die einzige Situation, in der die Versionsprüfung falsch ist, ist, wenn du auf einer Test- oder Beta-Server-Instanz spielst, die eine neuere Version als den Main-Server trägt; in diesem Fall zählt die Versionsnummer des Servers, nicht die deines Clients, und das Feature kann auf dem Server aktiv sein, während dein Client noch auf einer älteren Version ist. Für die meisten Spieler ist das kein Fall, der vorkommt, aber wenn du auf einem eigenen Server oder einer Beta spielst, ist die Server-Version die Zahl, die du prüfen solltest, nicht die deines Clients.

Entscheidungsrahmen: Was zu tun ist, bevor du auf Beitritt klickst

Wende diese Reihenfolge auf jede gelistete Karte im öffentlichen Browser an:

Entscheide, ob derselbe Raum zählt. Wenn du mit einem bestimmten Freund spielen willst, ist der Pool standardmäßig feindlich zu deinem Ziel: Jeder von euch wird unabhängig gehasht, und zwei unabhängige Hashes landen im selben Geschwister nur zufällig (Wahrscheinlichkeit 1 zu N bei einem Pool der Größe N). Die unterstützte Lösung ist die Whitelist auf dem Lobby-Eingang; wenn der Host dich nicht auf die Whitelist setzt, akzeptiere, dass ihr getrennt sein könnt.
Entscheide, ob die genaue Liste zählt. Für kompetitives oder ranglistenerhebliches Spiel, bei dem die Zusammensetzung deiner Eröffnungsmannschaft eine Variable ist, ist die Liste eines Pool-Mitglieds unbekannt, bis du geladen hast. Wenn du die Mannschaften hältst, die du baust, behandle den Pool als einen Zufall auf acht mögliche Listen und plane den schlechtesten Fall; wenn du nicht daran festhältst, ist der Pool strikt besser als ein einzelner voller Raum, weil die Karte weiterhin beitreten bleibt.
Prüfe den Countdown auf der Karte. Der Pool teilt eine einzige Startfrist über alle Mitglieder (die Startfrist des Eingangs wird bei der Pool-Erstellung auf jedes Geschwister kopiert), also ist der Countdown, den du auf der Karte siehst, der Countdown jedes Mitglieds. Du wirst niemals in ein Geschwister geschickt, das früher oder später startet, als die Karte verspricht; der Countdown, den du liest, ist der Countdown, den du bekommst.
Gehe davon aus, dass die Geschwistergruppe geschlossen ist. Du kannst die anderen Mitglieder nicht sehen, nicht zwischen ihnen wählen und ihre Spielerzahlen nicht sehen. Jede Strategie, die diese Informationen benötigt (z. B. „tritt dem leersten Geschwister bei“), wird nicht unterstützt; die einzige kontrollierbare Variable ist deine persistente Identität, und das ist etwas, das du nicht drehen solltest, um den Hash zu täuschen.
Wenn du der Host bist, entscheide die Pool-Größe vor der Erstellung. Zwei Geschwister verdoppeln den effektiven Raum; acht macht die Karte praktisch nie „voll“. Wähle die Größe für die erwartete Menschenmenge, nicht die kleinste, die funktioniert, weil du den Pool nicht wachsen lassen kannst.

Ein sechster Punkt, der über die fünf oben hinausgeht, ist, dass du vor dem Klick entscheiden solltest, wie du eine getrennte Landung behandeln willst, denn die fünf Punkte oben entscheiden, ob du überhaupt klicken solltest, nicht was du tust, wenn der Hash dich trennt. Für den Spieler, der mit einem Freund plant, ist die Entscheidungslogik eine Zwei-Wege-Abwägung: Wenn der Freund in demselben Raum sein muss, ist der Pool nur dann sicher, wenn der Host die Whitelist für beide setzt — alles andere ist eine Vermutung über zwei unabhängige Hashes. Wenn der Freund nur im selben Modus sein muss, ist der Pool immer sicher, weil alle Geschwister den Modus des Eingangs erben. Für den kompetitiven Spieler ist die Frage nicht „wird ich getrennt“, sondern „kann ich mit der zufälligen Liste leben“: Ein Pool aus acht macht deine Eröffnungsliste zu einem Achtteiler-Problem, also wenn deine Strategie von einer bestimmten Startbesetzung abhängt, ist der Pool ein Risiko, das du mit einem privaten oder whitelisteden Lobby vermeidest, und wenn deine Strategie nur vom Modus und der Karte abhängt, ist der Pool ein reiner Gewinn, weil die Karte weiter beitreten bleibt, während ein einzelner Raum voll werden würde. Diese sechs-Wege-Entscheidung — selbst mit Freund, ohne Freund, kompetitiv, casual, Host, Admin — ist der gesamte Entscheidungsrahmen auf einen Blick, und jede der fünf Punkte oben ist eine Zeile dieser Entscheidungstabelle.

Szenario A: Du hast auf die gelistete Karte geklickt und bist ohne deinen Freund gelandet

Setup: Du und ein Freund öffnen beide dieselbe gelistete FFA-Karte in einem Pool aus vier. Du klickst auf Beitritt, dein Freund klickt auf Beitritt, und ihr ladet in verschiedene Lobbys. Das ist das erwartete Ergebnis, kein Bug: Eure beiden persistenten Identitäten produzieren zwei unabhängige Hashwerte, und bei vier Geschwistern ist die Wahrscheinlichkeit, dass ihr zusammen landet, 1 zu 4. Nichts ist kaputt, und es gibt keine Server-Option „bleibt zusammen“ für neue Beitreter.

Was zu tun ist, nach Präferenz:

Bittet den Host, euch beide auf die Whitelist zu setzen. Die Whitelist-Befreiung löst sich vor dem Hash aus, also tretet ihr beide dem Eingang direkt bei. Das ist der einzige unterstützte Mechanismus für denselben Raum in einem Pool, und er erfordert den Host, also schreibe dem Lobby-Host vor dem nächsten Pool-Ereignis, nicht während.
Trittet beide über den Eingang erneut ein. Wenn der Host dich nicht auf die Whitelist setzen kann, trittet erneut dem Eingangs-Lobby (der gelisteten Karte) bei, nicht dem Geschwister, in dem du gelandet bist. Dein Hash-Ziel ist stabil, also würde erneutes Beitragen dich in dasselbe Geschwister zurücksetzen — was bedeutet, dass erneutes Beitragen dir nicht hilft, deinen Freund zu finden; es hilft deinem Freund nur, wenn er den Eingang neu betritt und sein Hash zufällig dein Geschwister erreicht (wieder 1 zu 4). Erwarte nicht, dass ein Lade-Loop das korrigiert; der Hash-Eingang ändert sich beim erneuten Beitritt nicht.
Akzeptiere die Trennung und koordiniere im Chat. In FFA ist die Trennung oft egal; in Team-Modi ändert sie deine Mannschaft, also wenn dir die Team-Zusammensetzung wichtig ist, behandle den Pool als ein Los und wähle Modi oder Lobbys, in denen deine Mannschaft nicht auf ein vorab organisiertes Duo angewiesen ist.

Was nicht zu tun ist: Interpretiere die Trennung nicht als Kick oder Anti-Bot-Erkennungsfehler, und melde sie nicht als „vom Lobby verworfen“ ohne den Kontext, dass ein Pool vorhanden war — Support und Community-Fäden würden es sonst mit den Ablehnungsfehlern verwechseln, die in der Fehler-Abschnitt unten abgedeckt sind.

Für Gruppen größer als zwei gilt dieselbe Logik, nur dass die Zahl schlechter wird und die Koordination schwieriger. Wenn du mit vier Freunden in denselben Raum willst und jeder wird unabhängig gehasht, ist die Wahrscheinlichkeit, dass alle vier zufällig zusammen landen, das Produkt aus ihren einzelnen Hash-Chancen, und bei einem Pool aus sechs ist das so klein, dass du es praktisch nie ohne Whitelist erleben wirst. Das ist keine seltene Ausnahme, es ist das Erwartungsergebnis, und es bedeutet, dass „alle vier werden zufällig zusammen sein“ kein planbarer Fall ist, sondern ein Lottogewinn. Die einzige zuverlässige Lösung für eine Gruppe ist die Whitelist auf dem Lobby-Eingang, und das erfordert den Host, also muss die Gruppe vor dem nächsten Pool-Ereignis dem Host schreiben, nicht während. Für den Fall, dass der Host nicht erreichbar ist oder nicht weiß, wie man Whitelist setzt, gibt es einen Umweg, der teilweise funktioniert: Die Gruppe vereinbart, dass sie in kurzen Abständen hintereinander beitritt, und die zuletzt beitretende Person meldet, in welchem Geschwister sie gelandet ist, und die anderen beitreten dann nicht mehr über den Eingang, sondern direkt über den Einladelink, den die erste Person teilt, wenn das Spiel das erlaubt. Dieser Umweg ist unzuverlässig, weil er von der Spielversion und den Einladefunktionen abhängt, aber er ist besser als nichts. Der praktische Rat für größere Gruppen ist daher: Behandele „alle zusammen in einem Pool-Raum“ als unmöglich, es sei denn, du hast die Whitelist vom Host, und plane dein Spiel so, dass es auch dann funktioniert, wenn die Gruppe über mehrere Geschwister verteilt ist. Wenn du ein organisierter Clan mit fester Besetzung bist, ist der Pool für dich nur dann sinnvoll, wenn der Host bereit ist, eure Kerngruppe auf die Whitelist zu setzen; ansonsten ist ein privates Lobby für euer Kernspiel der bessere Weg, und der Pool bleibt für offene öffentliche Spiele, bei denen die Zusammensetzung egal ist.

Szenario B: Du bist der Host eines gelisteten Lobbys und die Karte füllt sich, während deine Geschwister leer sind

Setup: Du hostest ein gelistetes Team-Lobby in einem Pool aus acht, und die öffentliche Karte zeigt den Eingang nahe seiner Kapazität, während du weißt, dass der Pool sechs andere leere Geschwister hat. Du erwartest, dass die Karte weiterhin Spieler aufnimmt, aber neue Beitreter landen weiterhin im Eingang und die Karten-Zahl steigt Richtung voll.

Zwei Dinge passieren gleichzeitig. Erstens verteilt der Hash neue Beitreter über die acht Geschwister, also füllt sich der Eingang nicht linear: Jeder neue Beitreter hat eine 1-zu-8-Chance, im Eingang selbst zu landen. Die Karten-Zahl ist die Eingangs-Liste, nicht die Pool-Summe, und der Server zeigt dir die Pool-Summe nie. Zweitens ist der Karten-„Voll“-Zustand der „Voll“-Zustand des Eingangs: Wenn die Eingangs-Liste ihre Kapazität erreicht, antwortet der Server „voll“ für den Eingang — und die Umleitungslogik läuft vor der Voll-Antwort, also kann ein Beitreter, der auf einen vollen Eingang zeigt, trotzdem in ein nicht-volles Geschwister geroutet werden. Die Karte kann also eine Zahl zeigen, die voll aussieht, während der Pool noch Platz hat, und das ist die Funktion, die so arbeitet, wie konzipiert, kein blockiertes Lobby.

Deine Betriebsprozedur als Host:

Lies die Karten-Zahl nicht als Pool-Gesundheit. Die einzige zuverlässige Aussage, die du von der Karte machen kannst, betrifft den Eingang. Wenn du die Pool-Ebene der Belegung brauchst, sind die Admin-Tools die Quelle, nicht die öffentliche Karte.
Dimensioniere den Pool für den Peak, dann akzeptiere die Warteschlange. Weil der Pool bei der Erstellung fixiert ist, wird ein zu klein dimensionierter Pool (zwei Geschwister für eine Menschenmenge von vierzig) den Eingang nur kurz füllen zeigen, während der Pool noch Platz hat; ein zu groß dimensionierter Pool (acht Geschwister für eine Menschenmenge von zehn) lässt sechs Geschwister fast leer und streut deine Community über Lobbys. Für ein wiederkehrendes gelistetes Ereignis ist acht der sichere Standard; für ein lockeres Duo-plus-Freunde-Lobby sind es zwei.
Nutze die Whitelist für deinen Kern. Deine Stammgäste können auf der Whitelist des Eingangs gesetzt werden, damit sie immer einen Raum mit dir teilen, während die öffentliche Menschenmenge sich über den Pool verteilt. Das hält deinen Kern stabil, ohne den Kapazitätsgewinn des Pools aufzugeben.

Ein Hosting-Betrachtung, die das vorherige Szenario nicht abdeckt, ist, was mit der Auto-Start-Deadline des Pools passiert, sobald Spieler über die Geschwister-Karten verteilt sind. Die Deadline wird bei der Gruppen-Ebene gesetzt (die create_pool-Kommando setzt die Auto-Start-Zeit auf den Einstiegsraum), aber die tatsächlichen Spieler sitzen in den Geschwister-Karten. Das bedeutet, dass die Deadline technisch auf dem Einstieg basiert, der die Spieler in den Geschwister-Karten „repräsentiert” — wenn du den Pool erstellst, setzt du eine Deadline für die Gruppe, und wenn die Gruppe genug Spieler hat (verteilt über die Geschwister-Karten), startet die Gruppe. Die praktische Bedeutung für den Host ist: Du solltest die Deadline nicht auf Basis der sichtbaren Spieler im Einstieg setzen (der nur eine Karte zeigt), sondern auf Basis der Gesamtzahl, die du über alle Geschwister-Karten hinweg erwartest. Wenn du einen Pool mit vier Geschwister-Karten erstellst und eine Deadline setzt, die für einen vollen einzelnen Raum geeignet ist, kann die Gruppe früher starten als erwartet, weil die Spieler über die vier Geschwister-Karten verteilt sind und die Gesamtzahl schneller das Auto-Start-Schwellen überschreitet. Umgekehrt: Wenn du die Deadline auf einer kleinen Zahl basierst, kann der Pool zu früh starten, während noch Spieler warten, um ihre eigene Geschwister-Karte zu finden. Der praktische Tipp ist: Setze die Auto-Start-Deadline auf Basis der Gesamtzahl, die du über die gesamte Gruppe hinweg willst, nicht auf Basis dessen, was in einem einzelnen Raum sichtbar ist.

Fehler und Gegenmaßnahmen

Der Umleitungspfad ist klein, aber er hat vier verschiedene Fehlerformen, und jede hat eine andere Ursache und eine andere Gegenmaßnahme. Zu diagnostizieren, welche du ansiehst, ist das ganze Spiel hier, weil das Spieler-Symptom für mindestens zwei von ihnen „ich habe beitreten versucht und einen Fehler bekommen“ ist.

Umleitung befolgt, dann Verbindungsfehler. Der Umleitungshandler des Clients setzt eine Sperre im sessionStorage, wenn er eine Pool-Umleitung folgt, und behandelt eine zweite Umleitung als abgelehnte Verbindung, damit der Client nicht zwischen zwei Geschwistern in eine Schleife gerät. Wenn du ein „connection refused“ direkt nach einer gelisteten Karte bekommst, sind die wahrscheinlichen Ursachen: Das Ziel-Geschwister wurde zwischen der Umleitungsentscheidung und dem Verbindungsversuch gelöscht oder geschlossen (selten, Server-Seite), oder die Sperre ist bereits durch einen zuvor fehlgeschlagenen Versuch im selben Tab gesetzt und die zweite Umleitung wird als Schleife behandelt. Gegenmaßnahme: Schließe den Tab vollständig (was sessionStorage löscht) und tritt über die gelistete Karte erneut ein. Versuche nicht, im selben Tab mehr als einmal neu zu versuchen.
Umleitung befolgt, Ziel nicht im erwarteten Pool. Wenn du in ein Lobby landest, dessen Modus oder Karte nicht zur Karte passt, ist es nicht der Pool: Alle Geschwister eines Pools teilen die Konfiguration des Eingangs durch Konstruktion (Geschwister werden aus derselben Konfiguration geprägt, und der Korrektur-Route kann sie nicht auseinanderdriften lassen). Eine Modus- oder Kartenabweichung bedeutet, dass du die falsche Karte betreten hast, nicht dass der Pool dich falsch geroutet hat. Gegenmaßnahme: Prüfe die Modus- und Karten-Chips der Karte erneut gegen das geladene Lobby; wenn sie abweichen, hast du auf eine andere Anzeige geklickt.
Ablehnung, die wie ein Pool-Bounce aussieht, aber eine Anti-Bot-Ablehnung ist. „Connection refused: Unauthorized: Turnstile token rejected“ ist die Cloudflare-Anti-Bot-Erkennung, die das Spiel ablehnt, und hat nichts mit Pool-Routing zu tun. Die Community-Fäden von 2026 melden dies als die häufigste „vom Lobby verworfen“-Beschwerde, und sie liegt vor Pools. Gegenmaßnahme: Die Standard-Anti-Bot-Abhilfen (Neustart, anderes Lobby versuchen, anderes Netz) gelten, und keine von ihnen betrifft den Pool. Wenn du von einem Lobby durch diesen Fehler verworfen wirst, aber nicht von einem anderen, ist die Ursache der Token, nicht das Lobby.
Kick ins Menü während eines Spiels. Ein plötzliches Zurück zum Startbildschirm ist eine Trennung oder ein Kick, und Neu-Verbindungen sind vom Pool-Routing befreit, also ist ein Kick niemals eine Pool-Umleitung. Wenn du gekickt und neu beitrittst, landest du in deinem ursprünglichen Lobby, nicht in einem Geschwister. Gegenmaßnahme: Prüfe die üblichen Ursachen (Server-Neustart, Inaktivität, Sitzungsexpiration), bevor du einen Kick während eines Spiels dem Pool zuschreibst.

Eine schnelle Diagnosetabelle für die vier Formen:

Symptom	Ursache	Gegenmaßnahme
„Connection refused“ direkt nach Beitritt auf eine gelistete Karte	Umleitungs-Schleifensperre oder Ziel zwischen Entscheidung und Verbindung geschlossen	Tab schließen, über die gelistete Karte neu eintreten
Der Modus/die Karte des geladenen Lobbys weicht von der Karte ab	Falsche Karte, nicht falsches Pool-Routing (Geschwister teilen die Konfiguration)	Karten-Chips erneut prüfen; die richtige Anzeige neu betreten
„Turnstile token rejected“	Cloudflare-Anti-Bot-Ablehnung, unabhängig von Pools	Standard-Anti-Bot-Abhilfen; als Token-Problem melden, nicht als Pool
Gekickt ins Menü während eines Spiels, neu Spielen bringt mich in dasselbe Lobby	Trennung/Kick; Neu-Verbindungen sind vom Routing befreit	Siehe Kick-Ursachen-Guide

Modus- und Karteanpassungen

Pools ändern nicht den Modus, die Karte oder die Modifikator-Chips: Alle Geschwister erben die Konfiguration des Eingangs, und der Server entfernt nichts aus dem Konfigurationsframe außer den Geschwister-Identifikatoren. Was Pools ändern, ist die Spieler-Mischung in einem Modus, und die folgenden Anpassungen sind Modus-Notizen dazu, was das für deine Eröffnungsentscheidungen bedeutet.

FFA. Der Pool ist ein Netto-Vorteil. Deine Eröffnungsposition wird von deinen eigenen Entscheidungen bestimmt, nicht von der Liste, also ist das Einzige, was sich ändert, die Größe der verfügbaren Menschenmenge für die Karte. Wenn du FFA gegen eine gelistete Karte spielst, behandle die Karte als „beitretbar, solange der Pool nicht tatsächlich voll ist“, und ziehe dich nicht zurück, nur weil die Eingangs-Zahl hoch erscheint.
Team-Modi. Der Pool ist die Variable, die zählt. Deine Mannschaft ist das, was die aktuelle Liste des Geschwisters plus du ergibt, und das Geschwister ist unbekannt, bis du geladen hast. Wenn du die faktische Führung einer Mannschaft bist, die du kontrollieren willst, ist die Whitelist dein Werkzeug; wenn du ein flexibler Spieler bist, ist der Pool eine Funktion: Du landest auf der Liste, die deine Rolle braucht. Plane deinen Eröffnungs-Build für den schlechtesten Team-Zusammensetzung-Wurf, nicht für den erwarteten Wurf.
Nuklear-/High-Stakes-Lobbys. Wenn dein Modus lange Vorbereitungen hat (Nuklear-Vorbereitung, SAM-Netzwerke), ist eine Trennung über Geschwister teuer: Deine geplante Gegenstrategie gegen einen bestimmten Gegner kann in einem Geschwister sein, das du nie siehst. Für Lobbys, in denen du einen benannten Spieler unterdrückst, schlägt die Whitelist oder ein privates Lobby den Pool; für offenes öffentliches Spiel akzeptiere die Trennung.
Kartenspezifische Lesarten. Ein Pool ändert nicht, welche Karte geladen wird, also trägt Kartenwissen unverändert zwischen Geschwistern über. Was nicht übertragen wird, ist der Zustand der Karte: Die beiden Geschwister laufen dieselbe Karte zum selben Startzeitpunkt, aber mit verschiedenen Spielern und daher unterschiedlicher früher Ausdehnung. Nimm nicht an, dass dein Co-Host im Geschwister ist, das du geladen hast; re-identifiziere deine Liste in den ersten dreißig Sekunden.

Die Modus- und Kartenwinkel handeln vomselben Feature in verschiedenen Verkleidungen, und die Unterschiede sind wichtig für deine Reaktion. In Rang- und kompetitiven Modi ist eine Pool-Weiterleitung in der Regel weniger störend als in entspanntem FFA, denn die Matchmaking- und Lobby-Regeln der Modi sind strenger und der Pool ist weniger wahrscheinlich, sich überhaupt zu bilden. Wenn du in einem Rang-Kontext weitergeleitet wirst, ist die praktische Konsequenz dieselbe (du landest in einer Geschwister-Karte mit demselben Modus und demselben Countdown), aber die Wichtigkeit, in einem anderen Raum zu sein als dein Teammate, ist höher, also zählt der Koordinationsrat aus dem Entscheidungsrahmen mehr. In entspanntem FFA und öffentlichen Sonder-Lobbys sind Pools der häufigere Fall, und die Weiterleitung ist ein normaler Teil des Erlebnisses statt einer Ausnahme. Auf Karten: Der Pool ändert die Karte nicht — jede Geschwister-Karte führt dieselbe Karte wie der Einstieg aus, weil die Pool-Gruppe die Konfiguration des Einstiegs teilt. Was sich ändert, ist die Zusammensetzung des Raums: Eine Geschwister-Karte kann eine andere Spieler-Mischung, ein anderes Skill-Level und einen anderen Vets-Set haben als der Einstieg, den du in der Liste gesehen hast. Das ist die praktische Sache, die du internalisieren solltest, wenn eine Weiterleitung deinen Spielplan ändert: Die Karte und der Modus sind identisch, aber die Leute, mit denen oder gegen die du spielst, sind anders, und eine Geschwister-Karte, die in der Liste „gleich” aussieht, kann sich in der Praxis sehr unterschiedlich spielen. Die einzige kartspezifische Überlegung ist, dass Pool-Gruppen vom Host erstellt werden und der Host die Karte wählt, also wenn du einen Pool hostest, wählst du auch, welche Karte jede Geschwister-Karte führt, und die Kartenwahl ist dieselbe für die acht Geschwister-Karten (oder so viele) der Gruppe. Das bedeutet, dass eine Kartenwahl, die gut für eine einzelne Lobby funktioniert, gut für jede Geschwister-Karte des Pools funktioniert, und dass eine Karte, die für eine Lobby unhandlich ist, für die ganze Gruppe unhandlich ist.

Tabelle: Der Pool auf einen Blick

Eigenschaft	Wert	Woher
Pool-Größe	2 bis 8 Geschwister	Die `create_pool`-Route validiert `count` mit `min(2).max(MAX_POOL_MEMBERS)`, `MAX_POOL_MEMBERS = 8`
Listenanzeige	Nur der Eingang wird gelistet	`applyListing` wird bei der Pool-Erstellung nur auf `lobbies[0]` angewandt
Konfiguration	Geteilt, bei der Erstellung fixiert	Geschwister werden aus der Eingangs-Konfiguration geprägt; die Korrektur-Route kopiert kein `pool`
Startzeit	Eine einzige geteilte Frist für den ganzen Pool	Die automatische Startfrist des Eingangs auf jedes Geschwister kopiert (`setPoolAutoStartAt`)
Routing-Eingang	`hash(poolId + ":" + persistenteIdentität) % Größe`	`poolIndexFor` / `poolTargetFor` in `PoolRouting.ts`
Umleitungsziel	Geschwister am Hash-Index; ignoriert, wenn es dem angesprochenen Eingang gleich ist	`poolTargetFor` gibt `null` zurück, wenn Ziel Eingang entspricht
Befreiungen	Neu-Verbindung, Admin-Rolle, `publicId` auf Whitelist, Zuschauer	Beitrittspfad in `GameServer.ts`
Zuschauer-Umschalter	Abgelehnt, wenn das Hash-Ziel ein anderes Mitglied ist	Pool-Prüfung von `setSpectator`
Client-Verhalten	Folgt der Umleitung über eine vollständige Seiten-Navigation; `sessionStorage`-Sperre verhindert eine zweite Umleitung (als abgelehnt behandelt)	Umleitungshandler in `Transport.ts`
Geschwister-Identifikatoren	Aus jedem `lobby_info`-Frame entfernt (Verbindungsgeheimnisse)	`configWithoutPool` in `GameServer.ts`
Team-Behebungen	Für Pools abgelehnt (`teams_unsupported_for_pool`)	`create_pool`-Validierung
Versionsgrenze	Angekündigt v0.34.19 (2026-09-25); funktional seit v0.34.20 (2026-09-26)	Versionsnotizen v0.34.19 und v0.34.20

Wie man die Tabelle liest, denn die Zeilen sind keine Checkliste, die man von oben nach unten arbeitet, sondern eine Menge von Fakten über ein Feature, und die Reihenfolge ist so gewählt, dass jede Zeile die Frage beantwortet, die die vorherige Zeile aufwirft. Die ersten drei Zeilen sind das Was (was ein Pool ist, was die Weiterleitung tut, wer ausgenommen ist), und sie sind die Zeilen, die zuerst zu lesen sind, wenn man neu bei dem Feature ist. Die mittleren Zeilen sind das Wann (die Versionsgrenze und die Auto-Start-Deadline), und sie sind die Zeilen, die zu lesen sind, wenn man versucht zu verstehen, warum ein Pool auf einer bestimmten Version gebildet wurde oder nicht. Die unteren Zeilen sind das Wie (das Admin-Kommando, die Client-Weiterleitung, die Weiterleitung-einmal-Garantie), und sie sind die Zeilen, die zu lesen sind, wenn man der Host oder Admin ist und einen Pool erstellen oder prüfen muss. Die Tabelle ist bewusst knapp — sie ist eine Referenz, kein Tutorial — also ist die Zeile, die am meisten zählt, die, die die Frage beantwortet, mit der man kam, und der Rest ist für den Fall da, in dem man ein Detail abgleichen muss. Wenn man Spieler ist, zählen die Zeilen „wer ausgenommen ist” und „die Weiterleitung ist einseitig”; wenn man Host ist, zählen die Zeilen „create_pool” und „Auto-Start-Deadline”; wenn man Admin ist, zählt die Zeile „die Pool-Konfiguration wird über Geschwister-Karten geteilt”. Die häufigste praktische Nutzung ist, die Tabelle zu öffnen, wenn ein Verhalten überrascht, und die Zeile zu finden, die zum Symptom passt: Ein Spieler, der in einem unerwarteten Raum landete, sieht sich die Zeile „die Weiterleitung ist einseitig” an, um sich daran zu erinnern, dass man nicht „zurück” zum Einstieg kann; ein Host, dessen Pool nicht gestartet ist, sieht sich die Auto-Start-Deadline-Zeile an, um zu prüfen, ob der Countdown nicht zu kurz war; ein Admin, der einen Pool prüft, sieht sich die geteilte-Konfigurations-Zeile an, um sich daran zu erinnern, dass jede Geschwister-Karte den Modus und die Karte des Einstiegs erbt. Die Tabelle dient daher als schneller Anker: Statt den ganzen Leitfaden neu zu lesen, wenn ein bestimmtes Detail entgeht, findet man die Zeile, die dieses Detail trägt, und kommt zu ihr zurück, was Zeit spart im Vergleich zu einer Suche im Volltext.

Ein überprüfbares Werkzeug: Die Pool-Admin-Route

Der einzige Ort, an dem du einen Pool sehen kannst, statt ihn nur zu erleben, ist die Admin-Bot-API. Die Route POST /api/adminbot/create_pool ist die einzige Art, wie ein Pool in die Existenz tritt, und ihre dokumentierte Anfrageform dokumentiert die Funktionsbeschränkungen in maschinenlesbarer Form:

POST /api/adminbot/create_pool
{
  "count": 4,                    // 2..8, die Anzahl der Geschwister (Eingang inbegriffen)
  "lobby": { ...config... }      // die vollständige Lobby-Konfiguration des Eingangs; Geschwister kopieren sie
}

Drei Eigenschaften der Anfrage machen die Beschränkungen konkret. Das count-Feld ist der einzige Größenregler, und es wird gegen min(2).max(8) validiert — eine Anfrage für ein Geschwister wird abgelehnt, und eine für neun wird abgelehnt, also ist die Tabellen-Größenbeschränkung oben keine Dokumentationsaussage, sondern ein Validierungsfehler, den du auslösen kannst. Die lobby-Konfiguration ist die einzige Quelle für jedes Geschwister: Es gibt kein pro-Geschwister-Feld in der Anfrage, und deshalb können Geschwister nicht in Modus, Karte oder Modifikator-Chips auseinanderdriften. Und die Antwort gibt die geprägten Lobby-Identifikatoren zurück, wobei nur der erste gelistet ist — die Antwort selbst zeigt die Pool-Form (N Identifikatoren, eine öffentliche Anzeige), genau die Form, die ein Spieler nie vom Client-Seite sieht.

Du wirst diese Route wahrscheinlich selbst nicht aufrufen: Es ist ein Admin-Bot-Zugriffspunkt, und der öffentliche Spielerpfad ist einfach „tritt eine gelistete Karte bei und lass den Server dich routen“. Die Route zählt für diesen Guide, weil sie die Faktenwahrheit für jede Zahl in der Tabelle oben ist — Größenbeschränkung, nur-Eingangs-Anzeige, geteilte Konfiguration, nur-bei-der-Erstellung-Existenz — und wenn eine zukünftige Version eine dieser Zahlen ändert, ist die Validierungs- und Antwortform dieser Route der Ort, an dem die Änderung zuerst sichtbar ist.

Was die Admin-Route aus Sicht des Hosts tut. Das create_pool-Kommando ist der Weg, auf dem ein Pool in die Existenz kommt: Der Host (oder ein Admin mit der Berechtigung) benennt einen Pool und gibt an, wie viele Geschwister-Karten benötigt werden, und der Server erstellt daraufhin eine Gruppe identischer Räume, von denen nur der erste in der öffentlichen Liste erscheint. Dieses Kommando zu verstehen, ermöglicht es, die Zeile „die Pool-Konfiguration wird über Geschwister-Karten geteilt” in der Tabelle zu lesen — das Teilen ist kein Zufall, sondern das Ergebnis von create_pool, das eine einzige Konfiguration in jedes Geschwister-Karte auf einmal schreibt. Für den Host bedeutet das praktisch, dass die Größe des Pools (zwei bis acht Geschwister-Karten) bestimmt, wie viele Spieler man auf einmal „verteilt”, und wie oft der Einstiegsraum in der Liste „voll” erscheint — denn die Liste zeigt nur den Einstieg, und die Spieler wissen nicht, dass es Geschwister-Karten dahinter gibt. Wenn man einen Pool erstellt, um einen überfüllten FFA-Raum zu entlasten, ist der Kompromiss: Je größer der Pool, desto leerer und leichter zu betreten ist jede Geschwister-Karte, aber desto schwächer ist das „Beliebtheit”-Signal des Einstiegs in der Liste (die Spieler werden verteilt); je kleiner der Pool, desto lebendiger erscheint der Einstieg, aber desto schneller füllt sich jede Geschwister-Karte. Dieser Kompromiss hat keine eindeutige richtige Antwort — es hängt davon ab, was man will: einen „schnellen Start” oder eine „Anziehungskraft in der Liste”.

Was in deiner eigenen Sitzung zu prüfen ist

Weil Pools vom Client unsichtbar sind, ist die einzige ehrliche Überprüfung, die du machen kannst, verhaltensbasiert, und sie erfordert ein einzelnes Spiel:

Tritt eine gelistete Karte bei, die du für einen Pool hältst (ein gelistetes Lobby, das von einem Host während eines Ereignisses erstellt wird, ist der wahrscheinliche Fall), und notiere, in welchem Lobby du lädst.
Frage einen Freund, der gleichzeitig dieselbe Karte betreten hat, in welchem Lobby er geladen hat. Wenn er in einem anderen Lobby mit demselben Modus, derselben Karte und demselben Startzeitpunkt ist, war die Karte ein Pool und das Routing hat so funktioniert, wie dokumentiert.
Wenn ihr beide im selben Lobby seid, ist entweder die Pool-Größe eins (kein Pool), oder eure beiden Hashes haben kollidiert; bei einem Pool aus acht ist die Kollisionswahrscheinlichkeit 1 zu 8, also ist ein einzelnes Gleiches-Lobby ein schwacher Beweis in beide Richtungen — wiederhole mit mehr Freunden für ein stärkeres Signal.
Wenn du stattdessen durch „Turnstile token rejected“ oder einen Kick ins Menü verworfen wirst, ist es kein Pool-Ergebnis: Wende die Fehler-Gegenmaßnahmen oben an, bevor du dem Routing etwas zuschreibst.

Der negative Fall ist ebenso wichtig wie der positive: Wenn dich eine gelistete Karte über mehrere unabhängige Spiele nie von einem Freund trennt, ist die Karte kein Pool (oder die Pool-Größe ist eins). „Diese Karte bringt mich immer in dasselbe Lobby wie mein Freund“ ist in einer Pool-Umgebung das Signal, dass der Pool nicht vorhanden ist.

Die Prüfungsliste ist von der günstigsten zur teuersten geordnet, denn die ersten drei Prüfungen kosten nur Sekunden und schließen die meisten Fälle aus. Die Versionsprüfung (ist mein Client auf oder nach v0.34.20) kommt zuerst, denn sie unterscheidet sofort „der Pool existiert nicht” von „der Pool funktioniert wie vorgesehen”. Als Nächstes die Modus- und Kartenprüfung (hat der Raum, in dem du landest, denselben Modus und dieselbe Karte wie der Einstieg), die bestätigt, dass du Pool-Routing und keinen wirklich anderen Raum siehst. Die dritte, die Countdown-Prüfung (liegt die Auto-Start-Deadline in einem vernünftigen Bereich), unterscheidet „der Pool startete wie vorgesehen” von „die Deadline war zu kurz und startete zu früh”. Nach dem Bestehen dieser drei kommt man zu den aufwändigeren Prüfungen: zu bestätigen, dass die Geschwister-Karten tatsächlich die Konfiguration teilen (Admin-Ansicht), und zu bestätigen, dass die Weiterleitung einseitig ist (man kann nicht „zurück” zum Einstieg). Das Wesentliche an der Liste ist nicht „sie alle in der Reihenfolge ausführen”, sondern „bei einem Symptom zuerst die günstigste ausführen”: Wenn du vermutest, im falschen Raum zu sein, fang mit der Modus- und Kartenprüfung an; wenn du vermutest, dass der Pool nicht wie vorgesehen gestartet ist, fang mit der Countdown-Prüfung an; wenn du vermutest, dass dein Client zu alt ist, fang mit der Versionsprüfung an. Der praktische Vorteil ist, dass die Mehrheit der „ich wurde weitergeleitet”-Berichte in den ersten drei Prüfungen eine Antwort findet, ohne die aufwändigste Admin-Prüfung erreichen zu müssen.

Zusammenfassung

Ein Lobby-Pool ist ein Kapazitätsmechanismus, keine Zielwahl: Eine gelistete Karte, bis zu acht Räume, ein geteilter Start, eine fixierte Konfiguration und ein deterministischer Hash, der neue Beitreter über die Räume verteilt. Du wählst das Geschwister nicht aus, du kannst die Geschwister nicht sehen, und du kannst die gesamte Pool-Belegung nicht sehen — die Karte ist alles, was du bekommst, und der Modus, die Karte und der Countdown der Karte sind weiterhin exakt das, was sie versprachen. Die Entscheidungen, die sich ändern, sind die sozialen: Spielen im selben Raum erfordert eine Whitelist, Team-Spiel erfordert einen Plan für den schlechtesten Wurf, und ein „verworfen“-Symptom erfordert die vierfache Fehlerdiagnose, bevor es dem Routing angelastet wird. Seit v0.34.20 funktioniert der Mechanismus so, wie die Versionsnotizen ihn beschreiben; davor war er angekündigt, aber nicht produktiv.

Wenn du nur drei Dinge aus diesem Guide behalten willst, weil du nicht den ganzen Text liest, sind es diese: Erstens, ein Pool teilt den Modus, die Karte und den Countdown des Eingangs mit all seinen Geschwistern, also wenn du eine gelistete Karte beitretest und in einen Raum mit derselben Karte und demselben Countdown kommst, ist das ein Pool, nicht ein anderes Spiel. Zweitens, der Server verteilt neue Beitreter über die Geschwister, aber er bewegt niemals Spieler, die bereits in einem Lobby sind, und er befreit Neu-Verbindungen, Zuschauer, Whitelist-Spieler und Admins vom Routing, also ist ein „weitergeleitet“-Erlebnis etwas, das nur einmal pro Beitritt passiert und sich nie auf dich bezieht, wenn du zurückkommst. Drittens, das Feature ist seit v0.34.20 aktiv und vorher nicht, also ist die einzige Prüfung, die du vor allem anderen machen solltest, die Versionsnummer deines Clients. Diese drei Punkte decken die allermeisten Situationen ab, die in Community-Fäden auftauchen: „Ich bin in einen anderen Raum gegangen“ (Pool, normal), „Ich konnte nicht beitreten“ (Version prüfen, dann Fehlerabschnitt), und „Mein Freund ist nicht dabei“ (Whitelist). Alles, was du über die Details wissen musst, ist in den Abschnitten dazwischen, aber wenn du nur die drei oben behältst, bist du für die meisten Fälle gerüstet.

Kurz gesagt: Pools sind für den Spieler unsichtbar und für den Host ein Kapazitätswerkzeug, und die einzige Sache, die ein Spieler kontrollieren kann, ist, welche Karte er anklickt und ob er die Whitelist vom Host bekommt. Wenn du das internalisierst, verwechselst du Pool-Verhalten nicht mit Fehlern, und wenn du Fehler siehst, weißt du, dass der Fehlerabschnitt die richtige Quelle ist, nicht die Pool-Logik.

OpenFront-Lobby-Pools: Wenn ein gelistetes Lobby dich in ein Geschwister-Lobby schickt