OpenFront-lobbypools: wanneer een gelijst lobby je naar een zusterlobby stuurt

Direct antwoord

Een lobby-pool is een groep van twee tot acht identieke lobbies die een host in één keer creëert; alleen de eerste verschijnt in de openbare lijst. Wanneer je deze gelijste kaart joint, kiest de server een zusterlobby voor jou via een deterministische hash van je persistente identiteit en stuurt een redirect die je client automatisch opvolgt. Je wordt alleen gerooteerd als nieuwe komst: spelers die zich opnieuw verbinden, toeschouwers, whitelisted spelers en admins blijven in hun lobby. De functie is aangekondigd in v0.34.19 (2026-09-25) maar werkt pas echt vanaf v0.34.20 (2026-09-26). Als je in een zusterlobby belandt zonder je vriend, dan is de redirect al een keer gebeurd — laad de originele gelijste lobby opnieuw en probeer opnieuw.

Deze hele handleiding beschrijft het gedrag vanaf v0.34.20, dat de huidige productie is. Als je deze leest terwijl je een oudere client draait, of een ouder video of een oud community-bericht bekijkt dat poolgedrag beschrijft, controleer dan eerst de versienummer: de enige plaats waar dezelfde vraag een ander antwoord krijgt is de grens tussen v0.34.19 (aangekondigd maar niet productief) en v0.34.20 (werkt). Daarbuiten is het gedrag dat hier staat stabiel, en is de rest van de handleiding onafhankelijk van je exacte subversie.

Om het geheel compleet te maken nog een paar grenzen die je uit het korte antwoord moet trekken. De hash is stabiel per speler in een gegeven pool, dus je kunt de uitkomst niet veranderen door opnieuw te joinen; je kunt alleen de uitkomst veranderen door op een andere poolgrootte te tikken, en dat is iets wat de host beslist, niet jij. De redirect wordt vóór elk vol- of gestart-antwoord gestuurd, wat betekent dat een “je werd ergens anders naartoe gestuurd”-uitslag en een “deze lobby is vol”-uitslag twee verschillende beslissingen zijn, en je een spelersfout na een redirectpoging moet diagnosticeren ten opzichte van het redirectpad. En de pool deelt één enkele startdeadline over alle leden, dus de countdown die je op de kaart leest is voor elk lid dezelfde — je wordt nooit naar een zusterlobby gestuurd die eerder of later start dan de kaart belooft. Al deze eigenschappen samen betekenen dat wat je ziet — dezelfde modus, dezelfde kaart, dezelfde teller — nooit wijzigt, en alleen de spelersmix en de exacte lijst veranderen, wat de hele reden is waarom je de sociale beslissingen moet maken vóórdat je klikt in plaats van erna.

Waarom één gelijste kaart meerdere lobbies kan zijn

In alle versies vóór v0.34.19 was een lobbykaart in de open browser precies één lobby: één spelerslijst, één start-teller, één ruimte. Als die ruimte vol of niet open was, zei de server dat en bleef je in de browser. Vanaf v0.34.19 kan een host die een gelijste lobby aanmaakt via de pool-adminroute tot zeven zusterlobbies tegelijk creëren, allemaal deels de configuratie van de ingang. De openbare lijst toont nog steeds precies één kaart — de ingang — omdat de zusterlobby-id’s worden behandeld als verbindingssleutels en de server ze uit elk lobby_info-frame verwijdert dat hij naar clients stuurt. Wat verandert, is wat er gebeurt als je op joinen klikt: in plaats van “vol” of “open” te beantwoorden voor één ruimte, vraagt de server nu welk lid van een kleine groep ruimtes jou moet ontvangen.

Dit ontwerp lost een echt probleem op dat spelers vóór pools meldden. De openbare lobbylijst is dun; community-draden vroegen regelmatig om een filterbare lijst en klaagden dat het wachten op een gelijste match twintig minuten of langer kon duren. Eén gelijste kaart die een hele menigte over acht ruimtes verspreidt, is een capaciteitsoplossing die de browser helemaal niet verandert: de kaart ziet er identiek uit, zelfde modus, zelfde modifikatiechips, zelfde countdown, maar de effectieve ruimtegrootte is vergroot. Dat is het doel van pools in één zin — en precies waarom de functie onzichtbaar is totdat je vaststelt dat de geladen lobby niet de lobby is die je vriend heeft geladen. Voor de context over wat de open kaart zelf belooft — modus, door de host gekozen start van 1 tot 5 minuten, capaciteit van 10 tot 100 spelers en de abonnementsdrempel voor hosting — lees de handleiding over publieke lobbies. Als de kaart die je wilt lijsten achter een betaald plan zit, dekt de handleiding over publieke speciale lobbies de drempel af die bepaalt of je überhaupt een gelijste lobby kunt creëren.

De mechaniek is bewust eenrichtings. De server kan een komst van de ingang naar een zusterlobby routeren, en hij kan ook een komst die direct op een zusterlobby tikt opnieuw over de pool verspreiden om de belasting te gladden — maar hij verplaatst nooit spelers die al in een lobby zitten en onthult de zusterlobbygroep nooit aan clients. Er is geen poolledenlijst in-game, geen “pool van 8”-badge op de kaart en geen manier om door de zusterlobbies te bladeren. De enige waarneembare effecten zijn waar je verschijnt en in welke spelerslijst je belandt.

Hoe de server je zusterlobby kiest

De routingfunctie is klein en volledig deterministisch: een hash van je persistente identiteit, gemengd met de pool-id zelf, modulo het aantal zusterlobbies. Expliciet geschreven berekent de server index = hash(poolId + ":" + jouwPersistenteIdentiteit) % aantalZusterlobbies en zoekt dan de zusterlobby op die index in de geordende pool-lijst. Als die index overeenkomt met de lobby die je al aanstuurde, wordt de redirect volledig genegeerd en join je de ruimte die je aanklikte — een pool dwingt dus niet iedereen een redirect op, alleen de meerderheid van de komsten.

Twee eigenschappen van deze formule tellen voor het gevoel van de functie. Ten eerste wordt de pool-id gemengd vóór het modulo, wat betekent dat dezelfde speler die op twee verschillende pools van gelijke grootte tikt verschillende volgnummers kan krijgen: je bent niet in alle pools van gelijke grootte “altijd lobby 3” vastgezet. Ten tweede is de hash per speler stabiel, dus in een gegeven pool word je altijd naar dezelfde zusterlobby gestuurd zolang de poolgrootte niet verandert. Je kunt niet opnieuw rollen voor een andere lobby door opnieuw te joinen, omdat de hash-ingang niet verandert bij hernieuwde komst. Wat de ingang wel verandert, is de poolgrootte: een host kan na creatie geen zusterlobbies toevoegen of verwijderen, maar twee poolgroepen van verschillende grootte verspreiden dezelfde speler anders.

Omdat de hash wordt berekend uit een stabiele spelersidentiteit, is de routing ook op een manier consistent die voor teamlobbies telt: de server scheidt teamgenoten niet opzettelijk en breekt nooit een bestaande lijst, omdat hernieuwde verbindingen exempt zijn (zie de volgende sectie). Wat hij doet, is nieuwe komsten verspreiden. Een pool van acht gedraagt zich dus als één kaart met acht lijsten: de eerste komsten landen elk in een andere zusterlobby, en na de eerste ronde is de verdeling wat de hash zegt. Er is geen “vul ruimte 1, dan ruimte 2”-volgorde — het modulo favoriseert niet de eerste lege ruimte, maar een deterministisch bucket. Daarom kan een pool op hetzelfde moment één zusterlobby bijna vol en een andere bijna leeg hebben, en daarom zou je het aantal spelers op een zusterlobby niet als signaal moeten lezen voor de totale poolbezetting.

De redirect zelf is een controlframe, geen lobbyframe. De server stuurt een bericht van het type redirect met de id van de doellobby, en hij stuurt het vóór elk vol- of gestart-antwoord. In de servercode is de commentaar over deze volgorde expliciet: gerooteerd worden is geen afwijzing. Dit onderscheid is de belangrijkste feitelijke voor het interpreteren van bounces, omdat het betekent dat een “je werd ergens anders naartoe gestuurd”-uitslag en een “deze lobby is vol”-uitslag twee verschillende serverbeslissingen zijn, en dat een spelersfout na een redirectpoging moet worden gediagnosticeerd ten opzichte van het redirectpad, niet het vol-lobby-pad.

Wie wordt gerooteerd, en wie niet

Het toetredingspad voert de poolcheck in een vaste volgorde uit, en die volgorde definieert de exempties. Ten eerste controleert de server of de binnentredende client al als speler in de doellijst bestaat: zo ja, dan is het spel een herverbinding en wordt de poollogica genegeerd. Ten tweede controleert de server rollen en lijsten: een admin die de lobby betreedt, een speler op de whitelisted lijst van de lobby en een client met de toeschouwersrol omzeilen allemaal de redirect. Ten derde, voor iedereen anders die werkelijk nieuw is in de lijst, berekent de server het hashdoel en emit de redirect als het verschilt van de lobby die je aanstuurde.

Praktische consequenties om te onthouden:

• Herverbindingen worden nooit opnieuw gerooteerd. Als je tijdens een match word afgebroken en naar dezelfde lobby terugkeert, belandt je waar je was. De server herkent je in de bestaande lijst vóór de poolcheck, en die wordt genegeerd. De “ik werd naar het menu gestuurd en opnieuw gespeeld”-ervaring is dus nooit een pool-redirect; kicks en afbreken zijn een andere foutklasse, afgehandeld buiten het pool-routing.
• Toeschouwers zijn vastgezet. Inschakelen van toeschouwersmodus in de pool-ingang wordt afgewezen als het hashdoel een ander lid is: je kunt niet toekijken in de lobby waarin je als speler zou zijn gerooteerd. Je kijkt exact de lobby toe die je aanstuurt.
• Whitelist verslaat de pool. Een speler op de whitelisted lijst van de ingang joint de ingang zelf, wat de hash ook zegt. Als jij en een vriend in dezelfde ruimte willen in een poolomgeving, is het enige ondersteunde mechanisme de whitelist.
• Admins zijn vastgezet. Personeel dat de pool-ingang betreedt, blijft in de ingang, zodat beheerders de inkaart kunnen bewaken zonder over de pool verspreid te worden.
• Nieuwe komsten worden verspreid. Iedereen anders — het normale geval — wordt gehasht naar één van de zusterlobbies.

Een extra asymmetrie: de redirect gaat alleen naar de pool voor nieuwe komsten. De server verplaatst nooit een speler van een zusterlobby naar een andere terwijl de lijsten vullen, er is dus geen “aanvullen”-gedrag dat een speler uit een lobby trekt waar hij al is. De pool verspreidt komsten aan de deur; zodra je erin zit, zit je erin.

Een concreet voorbeeld maakt de volgorde tastbaar. Stel je bent toeschouwer en klik je een gelijste kaart aan die een pool van zes is. De server berekent eerst of je al als speler in de doellijst staat (nee), dan of je de toeschouwersrol hebt (ja), en omdat die check vóór de hash komt, kijk je exact de lobby toe die je aanstuurt en word je niet over de zes verspreid. Als je in plaats daarvan een nieuwe speler bent, dan draait de hash en loop je naar één van de zes. Die volgorde is waarom toeschouwers vastgezet zijn en waarom nieuwe komsten verspreid worden in dezelfde sessie, en waarom je als toeschouwer nooit een andere zusterlobby zult zien dan de kaart die je aanklikt.

De versiegrens: v0.34.19 kondigt aan, v0.34.20 doet het werken

Het verhaal van de functie is twee versies dik, en de grens telt, omdat beide versies verschillende dingen claimen. De versie-opmerkingen v0.34.19 (gepubliceerd 2026-09-25) kondigen de functie aan: een gelijste lobby kan komsten verspreiden over een pool van zusterlobbies. De versie-opmerkingen v0.34.20 (gepubliceerd 2026-09-26) leveren dan de fix: lobby-pools die in productie nooit werden gevormd, worden nu gevormd, en gelijste lobbies kunnen werkelijk komsten verspreiden over zusterlobbies. Het tweede punt bestaat omdat de eerste versie code leverde die in de productieomgeving geen werkende pools produceerde; tussen de twee versiedatums stond de routingcode op de server maar werden er effectief geen pools gemaakt.

Drie consequenties volgen daaruit. Ten eerste zijn alle community-rapporten of streams in het v0.34.19-tijdvenster die zeggen “pools werken niet” consistent met het versielog, geen bugrapport tegen v0.34.20. Ten tweede is het productiegedrag dat je in deze handleiding leest het v0.34.20-en-later-gedrag; als je een oudere handleiding leest of een ouder video bekijkt dat het poolgedrag beschrijft, controleer zijn versierij vóórdat je hem vertrouwt. Ten derde komen de poolgroottebeperking van twee tot acht, het alleen-gepubliceerde-ingang en de bij-creatie-vastgezette configuratie allemaal uit dezelfde coderevisie die v0.34.20 leverde, dus elk getal in deze handleiding is een v0.34.20-getal.

De configuratie zelf is ook op een tweede, stillerere manier aan de versie gebonden: de poolblok is alleen bij creatie. De lobby-fixroute kopieert geen pool-veld, wat betekent dat een host geen zusterlobbies kan toevoegen aan een bestaande gelijste lobby of een pool na creatie opnieuw dimensioneren. Als je een pool wilt, maak je de pool aan het begin; er is geen “upgrade tijdens het spel” van “enkele gelijste lobby” naar “gelijste lobby met zeven zusterlobbies”. Dat is een ontwerpbeslissing, geen ontbrekende functie: de gedeelde automatische startdeadline en de gedeelde configuratie maken de pool één atomair object, en het versielog bevat geen latere versie die de poolblok via de fixroute uitbreidt op de hier gedocumenteerde versiegrens.

Een praktisch gevolg dat hier nog niet aan is toegevoegd, is dat de versiegrens bepaalt welke getallen je kunt vertrouwen. Als je een oudere handleiding leest die een poolgrootte van drie tot zes citeert, of een pool van acht noemt terwijl een oudere bron een ander maximum zegt, dan is die bron waarschijnlijk geschreven vóórdat de definitieve validatie in v0.34.20 landde. De enige getallen die hier staan — twee tot acht leden, alleen de ingang gelijst, configuratie vastgezet bij creatie — zijn v0.34.20-getallen, en als een latere versie ze verandert, is de pool-adminroute de plek waar je die verandering eerst zult zien, omdat de validatie en de antwoordvorm daar de feitelijke waarheid zijn voor elk getal in de tabel. Voor het spel zelf betekent dat: de versie van je client is de eerste filter, en alleen nadat je die hebt bevestigd, mag je de rest van de handleiding toepassen op wat je ziet.

Beslisframework: wat te doen vóór je op joinen klikt

Pas deze volgorde toe op elke gelijste kaart in de open browser:

1. Beslis of dezelfde ruimte telt. Als je joint om met een specifieke vriend te spelen, is de pool standaard vijandig aan je doel: elk van jullie wordt onafhankelijk gehasht, en twee onafhankelijke hashes landen in dezelfde zusterlobby alleen per toeval (kans 1 op N voor een pool van grootte N). De ondersteunde oplossing is de whitelist op de lobby-ingang; als de host je niet whitelisted, accepteer dan dat je gescheiden kunt worden.
2. Beslis of de exacte lijst telt. Voor competitief of ranglijstrelevant spel waar de samenstelling van je openingsploeg een variabele is, is de lijst van een poollid onbekend totdat je geladen hebt. Als je je ploegen aanhoudt, behandel de pool dan als een loterij over acht mogelijke lijsten en plan de slechtste uitkomst; als je niet vasthoudt, is de pool strikt beter dan één volde ruimte, want de kaart blijft joinbaar.
3. Controleer de start-teller op de kaart. De pool deelt één enkele startdeadline over alle leden (de startdeadline van de ingang wordt bij poolcreatie naar elke zusterlobby gekopieerd), dus de countdown die je op de kaart ziet is de countdown van elk lid. Je wordt nooit naar een zusterlobby gestuurd die eerder of later start dan de kaart belooft; de teller die je leest is de teller die je krijgt.
4. Ga ervan uit dat de zusterlobbygroep gesloten is. Je kunt de andere leden niet zien, niet tussen hen kiezen en hun spelersaantallen niet zien. Elke strategie die die informatie nodig heeft (bijv. “join de leegste zusterlobby”) wordt niet ondersteund; de enige controleerbare variabele is je persistente identiteit, en dat is iets dat je niet zou moeten draaien om de hash te slagen.
5. Als je de host bent, beslis de poolgrootte vóór creatie. Twee zusterlobbies verdubbelen de effectieve ruimte; acht maakt de kaart bijna nooit “vol”. Kies de grootte voor de verwachte menigte, niet de kleinste die werkt, omdat je de pool niet kunt laten groeien.

De volgorde hierboven is bewust van de goedkoopste check naar de duurste, omdat de eerste twee vragen vaak het hele antwoord al zijn en de rest overbodig maken. Als dezelfde ruimte niet telt en je een vriend wilt, dan is de witte-lijst het enige mechanisme en hoef je de rest van het framework niet te doorlopen; als de exacte lijst wel telt en je ploeg vasthoudt, dan is het antwoord “plan de slechtste loterij” en heb je de start-teller alleen nodig om te weten of de countdown voor de hele pool geldig is. De reden om de start-teller als derde te houden is dat die de enige harde belofte van de kaart is — de modus, de kaart en de teller — en als die drie kloppen met wat je geladen hebt, dan werkt de pool zoals ontworpen en is alles anders een verkeerde kaart of een storing, niet een routingfout.

Scenario A: je hebt op de gelijste kaart geklikt en bent zonder je vriend beland

Setup: jij en een vriend openen allebei dezelfde gelijste FFA-kaart in een pool van vier. Je klikt op joinen, je vriend klikt op joinen, en jullie laden in verschillende lobbies. Dat is het verwachte resultaat, geen bug: jullie twee persistente identiteiten produceren twee onafhankelijke hashwaarden, en met vier zusterlobbies is de kans dat jullie samen landen 1 op 4. Niets is kapot, en er is geen serveroptie “blijf samen” voor nieuwe komsten.

Wat te doen, in volgorde van voorkeur:

• Vraag de host om jullie allebei te whitelissen. De whitelist-exemptie treedt vóór de hash af, dus jullie joinen allebei de ingang direct. Dat is het enige ondersteunde zelfde-ruimte-mechanisme in een pool, en het vereist de host, dus stuur een bericht aan de lobbyhost vóór het volgende pool-gebeuren, niet tijdens.
• Join opnieuw via de ingang samen. Als de host je niet kan whitelissen, join opnieuw de in-lobby (de gelijste kaart) in plaats van de zusterlobby waar je belandde. Je hashdoel is stabiel, dus opnieuw joinen zet je terug in dezelfde zusterlobby — wat betekent dat opnieuw joinen je niet helpt om je vriend te vinden; het helpt je vriend alleen als hij opnieuw de ingang joint en zijn hash per toeval je zusterlobby bereikt (weer 1 op 4). Verwacht niet dat een laad-lijn dat corrigeert; de hash-ingang verandert niet bij hernieuwde komst.
• Accepteer de scheiding en coördineer in chat. In FFA is de scheiding vaak onbelangrijk; in teammodi verandert het je ploeg, dus als de ploegsamenstelling je iets is, behandel de pool dan als een loterij en kies modi of lobbies waar je ploeg niet afhankelijk is van een vooraf gearceerde duo.

Wat niet te doen is: interpreteer de scheiding niet als een kick of anti-bot-detectie-fout, en meld hem niet als “uit de lobby gewezen” zonder de context dat een pool aanwezig was — support en community-draden zouden hem anders verwarren met de weigeringfouten die in de storingen-sectie hieronder worden gedekt.

Nadat je bevestigt hebt dat de scheiding echt is en geen storing, is de volgende vraag wat je in het spel zelf doet, en dat hangt van de modus af. In FFA is er geen cross-lobby-chat en geen manier om je vriend te vinden tijdens het spel, dus de scheiding is praktisch irrelevant en je speelt gewoon in de lobby waarin je belandt. In een teammodus verandert de scheiding je ploeg, en dan is de vraag of je de modus had moeten kiezen: als je wist dat je een vriend wilde en de host de whitelist niet zou zetten, dan was de moduskeuze al een gok die je had moeten afwegen vóórdat je klikte, niet iets dat je na het laden kunt ongedaan maken. De praktische regel is: beslis vóór de klik of je de scheiding kunt accepteren in de modus die je speelt, en als het antwoord nee is, dan is de oplossing de modus of de lobby kiezen (een privélobby of een whitelist-lobby), niet de pool omzeilen, want die bestaat niet.

Scenario B: je bent de host van een gelijste lobby en de kaart vult terwijl je zusterlobbies leeg zijn

Setup: je host een gelijste teamlobby in een pool van acht, en de open kaart toont de ingang dicht bij zijn capaciteit, terwijl je weet dat de pool zes andere lege zusterlobbies heeft. Je verwacht dat de kaart blijft opsporen spelers, maar nieuwe komsten landen blijft in de ingang en het kaartgetal klimt richting vol.

Twee dingen gebeuren tegelijk. Ten eerste verspreidt de hash nieuwe komsten over de acht zusterlobbies, dus de ingang vult niet lineair: elke nieuwe komst heeft een 1-op-8-kans om in de ingang zelf te landen. Het kaartgetal is de inlijst, niet de poolsom, en de server toont je de poolsom nooit. Ten tweede is de “vol”-status van de kaart de “vol”-status van de ingang: wanneer de inlijst zijn capaciteit bereikt, antwoordt de server “vol” voor de ingang — en de redirectlogica loopt vóór het vol-antwoord, dus een komst die op een volle ingang tikt kan toch naar een niet-volle zusterlobby worden gerooteerd. De kaart kan dus een getal tonen dat vol lijkt terwijl de pool nog ruimte heeft, en dat is de functie die werkt zoals ontworpen, geen geblokte lobby.

Jouw bedrijfsproceduur als host:

• Lees het kaartgetal niet als poolgezondheid. Het enige betrouwbare statement dat je van de kaart kunt maken betreft de ingang. Als je de poolniveau-bezetting nodig hebt, zijn de administratiehulpmiddelen de bron, niet de open kaart.
• Dimensioneer de pool voor de piek, accepteer dan de wachtrij. Omdat de pool bij creatie is vastgezet, zal een pool die te klein is gedimensioneerd (twee zusterlobbies voor een menigte van veertig) de ingang slechts kort vol tonen terwijl de pool nog ruimte heeft; een pool die te groot is gedimensioneerd (acht zusterlobbies voor een menigte van tien) laat zes zusterlobbies bijna leeg spreiden en spreidt je community over lobbies. Voor een terugkerend gelijst evenement is acht de veilige standaard; voor een losse duo-plus-vriendenlobby zijn het twee.
• Gebruik de whitelist voor je kern. Je vaste spelers kunnen op de ingangs-whitelist worden gezet zodat ze altijd een ruimte met je delen, terwijl de openbare menigte zich over de pool verspreidt. Dat houdt je kern stabiel zonder het capaciteitsvoordeel van de pool op te geven.

Een veelgemaakte host-fout die je hier moet vermijden is de pool te sluiten of een nieuwe lobby te creëren omdat de ingang “vol” toont, terwijl de pool nog ruimte heeft. Als je dat doet, verlies je het capaciteitsvoordeel van de pool en stuur je de openbare menigte weg, terwijl de andere zes zusterlobbies nog lege plaatsen hebben. De juiste reactie als host is: laat de pool draaien, controleer via de administratiehulpmiddelen of de pooltotaalbezetting werkelijk de capaciteit benadert, en als dat zo is, dan is de pool volledig benut en mag je afsluiten. Als de pooltotaalbezetting nog laag is maar de ingang “vol” toont, dan is dat de gewenste toestand — de redirect stuurdt nieuwe komsten naar de lege leden en de kaart blijft joinbaar — en dan moet je de pool laten draaien totdat de administratiehulpmiddelen aantonen dat de pool inderdaad vol is. Het onderscheid tussen “ingangs-vol” en “pool-vol” is de hele reden waarom de pool bestaat, en als je die verwarrt, ontdoet je de pool van het werk dat hij zou moeten doen.

Storingen en tegengaan

Het redirectpad is klein, maar het heeft vier verschillende storingvormen, en elke heeft een andere oorzaak en een ander tegengaan. Diagnosticeren welke je bekijkt is het hele spel hier, omdat het spelerssymptoom voor minstens twee van hen “ik heb proberen te joinen en een fout gekregen” is.

1. Redirect opgevolgd, dan verbindingsfout. De redirecthandler van de client zet een vergrendeling in sessionStorage als hij een pool-redirect opvolgt en behandelt een tweede redirect als een geweigerde verbinding, zodat de client niet tussen twee zusterlobbies kan vastlopen. Als je direct na een gelijste kaart een “connection refused” krijgt, zijn de waarschijnlijke oorzaken: het doelzusterlobby werd tussen de redirectbeslissing en de verbindingspoging gewist of gesloten (zeldzaam, serverkant), of de vergrendeling staat al door een eerdere mislukte poging in hetzelfde tabblad en de tweede redirect wordt als lus behandeld. Tegengaan: sluit het tabblad volledig (wat sessionStorage wist) en join opnieuw via de gelijste kaart. Probeer niet meer dan één keer opnieuw in hetzelfde tabblad.
2. Redirect opgevolgd, doel niet in de verwachte pool. Als je in een lobby belandt waarvan modus of kaart niet bij de kaart past, is het niet de pool: alle zusterlobbies van een pool delen de configuratie van de ingang bij constructie (zusterlobbies worden uit dezelfde configuratie gepraagd, en de fixroute kan ze niet uit elkaar laten lopen). Een modus- of kaartafwijking betekent dat je de verkeerde kaart joinde, niet dat de pool je verkeerd gerooteerd heeft. Tegengaan: controleer de modus- en kaartchips van de kaart opnieuw tegen de geladen lobby; als ze verschillen, klikte je op een andere listing.
3. Weigering die eruitziet als een pool-bounce maar een anti-bot-weigering is. “Connection refused: Unauthorized: Turnstile token rejected” is de Cloudflare-anti-bot-detectie die het spel weigert, en heeft niets met pool-routing te maken. De community-draden van 2026 rapporteren dit als de meest voorkomende “uit de lobby gewezen”-klacht, en het ligt vóór pools. Tegengaan: de standaard anti-bot-oplossingen (herstart, probeer een andere lobby, probeer een ander netwerk) gelden, en geen van hen raakt de pool aan. Als je door deze fout uit een lobby word gewezen maar niet uit een andere, is de oorzaak de token, niet de lobby.
4. Kick naar het menu tijdens een match. Een plotselinge terugkeer naar het startscherm is een afbreken of een kick, en herverbindingen zijn van pool-routing exempt, dus een kick is nooit een pool-redirect. Als je word gekickt en opnieuw join, belandt je in je oorspronkelijke lobby, niet in een zusterlobby. Tegengaan: controleer de gangbare oorzaken (serverherstart, inactiviteit, sessie-expiratie) voordat je een kick tijdens een match aan de pool toeschrijft.

Een snelle diagnostiektafel voor de vier vormen:

Symptoom	Oorzaak	Tegengaan
”Connection refused” direct na join op een gelijste kaart	Redirect-lusvergrendeling of doel tussen beslissing en verbinding gesloten	Tabblad sluiten, opnieuw joinen via de gelijste kaart
De modus/de kaart van de geladen lobby verschilt van de kaart	Verkeerde kaart, niet verkeerde pool-routing (zusterlobbies delen de configuratie)	Kaartchips opnieuw controleren; de juiste listing opnieuw joinen
”Turnstile token rejected”	Cloudflare-anti-bot-weigering, onafhankelijk van pools	Standaard anti-bot-oplossingen; melden als tokenprobleem, niet als pool
Gekickt naar het menu tijdens een match, opnieuw spelen brengt me naar dezelfde lobby	Afbreken/kick; herverbindingen zijn van routing exempt	Zie de kickoorzaken-handleiding

Modus- en kaartaanpassingen

Pools veranderen de modus niet, de kaart niet of de modifikatiechips niet: alle zusterlobbies erven de configuratie van de ingang, en de server verwijdert niets uit het configuratieframe behalve de zusterlobby-id’s. Wat pools veranderen is de spelersmix in een modus, en de volgende aanpassingen zijn modusnotities over wat dat betekent voor je openingsbeslissingen.

• FFA. De pool is een netto-voordeel. Je openingspositie wordt bepaald door je eigen beslissingen, niet door de lijst, dus het enige dat verandert is de grootte van de beschikbare menigte voor de kaart. Als je FFA speelt tegen een gelijste kaart, behandel de kaart dan als “joinbaar zolang de pool niet werkelijk vol is”, en trek je niet terug omdat het ingetal hoog lijkt.
• Teammodi. De pool is de variabele die telt. Je ploeg is wat de huidige lijst van de zusterlobby plus jij oplevert, en de zusterlobby is onbekend totdat je geladen hebt. Als je de facto leider bent van een ploeg die je wilt besturen, is de whitelist je gereedschap; als je een flexibele speler bent, is de pool een functie: je belandt op de lijst die je rol nodig heeft. Plan je openingsbouw voor de slechtste ploegsamenstelling-loterij, niet voor de verwachte loterij.
• Nucleaire / hoge-inzet-lobbies. Als je modus lange voorbereidingen heeft (nucleaire voorbereiding, SAM-netwerken), is een scheiding over zusterlobbies kostbaar: je geplande tegenstrategie tegen een specifieke tegenstander kan in een zusterlobby zijn die je nooit zult zien. Voor lobbies waarin je een genoemde speler onderdrukt, verslaat de whitelist of een privélobby de pool; voor openbaar open spel accepteer de scheiding.
• Kaartspecifieke lezingen. Een pool verandert niet welke kaart geladen wordt, dus kaartkennis gaat ongewijzigd tussen zusterlobbies over. Wat niet overgaat, is de toestand van de kaart: de twee zusterlobbies draaien dezelfde kaart op hetzelfde starttijdstip, maar met verschillende spelers en dus een andere vroege uitbreiding. Neem niet aan dat je teamgenoot in de zusterlobby is die je geladen hebt; heridentificeer je lijst in de eerste dertig seconden.

Een extra modusnotitie over wat de pool doet met je voorbereidingsstrategie. In modi waarin je een tegenstrategie plant tegen een specifieke tegenstander of tegen een specifieke samenstelling — je onderdrukt een genoemde speler, je bouwt tegen een bepaalde kern — verandert de pool de voorwaarde die je strategie op is gebouwd, want je weet niet tegen welke samenstelling je zult beginnen. De twee manieren om daarmee om te gaan zijn de whitelist (zodat je kern stabiel is en je tegenstander voorspelbaar blijft) of een privélobby (zodat je hele compositie vast is). In openbaar open spel waar de compositie per definitie onbekend is, is de pool geen probleem maar juist het punt: je strategie moet dan op de verwachting over de samenstelling werken, niet op een specifieke samenstelling, en dat is een andere soort besluit dan in een vaste lobby. De regel is dus niet “de pool is slecht voor je strategie”, maar “als je strategie afhangt van een specifieke samenstelling, dan moet je de pool omzeilen of accepteren dat de samenstelling elke keer anders is”.

Tafel: de pool in één oogopslag

Eigenschap	Waarde	Vandaar
Poolgrootte	2 tot 8 zusterlobbies	De create_pool-route valideert count met min(2).max(MAX_POOL_MEMBERS), MAX_POOL_MEMBERS = 8
Listing	Alleen de ingang staat gelijst	applyListing wordt bij poolcreatie alleen op lobbies[0] toegepast
Configuratie	Gedeeld, vastgezet bij creatie	Zusterlobbies worden uit de inconfiguratie gepraagd; de fixroute kopieert geen pool
Starttijd	Eén enkele gedeelde deadline voor de hele pool	De automatische startdeadline van de ingang naar elke zusterlobby gekopieerd (setPoolAutoStartAt)
Routing-ingang	hash(poolId + ":" + persistenteIdentiteit) % grootte	poolIndexFor / poolTargetFor in PoolRouting.ts
Redirectdoel	Zusterlobby op de hash-index; genegeerd als hij op de aangestuurde ingang gelijk is	poolTargetFor geeft null terug als doel ingang is
Exempties	Herverbinding, adminrol, publicId op whitelist, toeschouwers	Toetredingspad in GameServer.ts
Toeschouwer-schakelaar	Afgewezen als het hashdoel een ander lid is	Poolcheck van setSpectator
Clientgedrag	Volgt de redirect via een volledige paginanavigatie; sessionStorage-vergrendeling voorkomt een tweede redirect (als geweigerd behandeld)	Redirecthandler in Transport.ts
Zusterlobby-id’s	Verwijderd uit elk lobby_info-frame (verbindingsleutels)	configWithoutPool in GameServer.ts
Team-fixes	Afgewezen voor pools (teams_unsupported_for_pool)	create_pool-validatie
Versiegrens	Aangekondigd v0.34.19 (2026-09-25); werkend sinds v0.34.20 (2026-09-26)	Versie-opmerkingen v0.34.19 en v0.34.20

Een tweede manier om de tabel te gebruiken is als een onafhankelijke toets voor wat je ziet, en dat werkt per rij in beide richtingen. Als de tabel zegt dat alleen de ingang gelijst is, en je ziet in de open browser twee kaarten die identiek lijken, dan is de tabel het bewijs dat er geen tweede kaart bestaat en je op een andere listing hebt gekeken. Als de tabel zegt dat de zusterlobby-id’s uit elk frame worden verwijderd, en je probeert een zusterlobby te vinden door de id te raden, dan is de tabel het bewijs dat dat pad niet bestaat en je het via de adminroute moet zoeken. Deze “omgekeerde” lezing — de tabel als ontkracht van een verwachting die je uit een ander spel of een andere versie hebt overgenomen — is precies wat de tabel nuttig maakt, want de meeste verwachtingen die spelers meenemen (“je kunt een pool kiezen”, “de zusterlobby verschijnt in de lijst”, “de poolgrootte is instelbaar na creatie”) worden door de tabel één voor één ontkracht, en als je de tabel zo leest voordat je een besluit neemt, voorkom je de drie meest voorkomende verkeerde aannames in de community-draden.

Deze tabel is het enige stuk in de handleiding waar je een getal kunt controleren tegen wat je ziet, want de andere secties beschrijven gedrag en deze tabel beschrijft feiten.

Een verifieerbaar gereedschap: de pool-adminroute

De enige plek waar je een pool kunt zien in plaats van hem alleen te ervaren, is de administratie-bot-API. De route POST /api/adminbot/create_pool is de enige manier waarop een pool in de bestaande treedt, en zijn gedocumenteerde aanvraagvorm documenteert de functiebeperkingen in machineleesbare vorm:

POST /api/adminbot/create_pool
{
  "count": 4,                    // 2..8, het aantal zusterlobbies (ingang inbegrepen)
  "lobby": { ...config... }      // de volledige lobbyconfiguratie van de ingang; zusterlobbies kopiëren hem
}

Drie eigenschappen van de aanvraag maken de beperkingen concreet. Het count-veld is de enige grootteregelaar, en het wordt gegen min(2).max(8) gevalideerd — een aanvraag voor één zusterlobby wordt afgewezen, en een voor negen wordt afgewezen, dus de tabelgroottebeperking hierboven is geen documentatiestatement maar een validatiefout die je kunt triggeren. De lobby-configuratie is de enige bron voor elke zusterlobby: er is geen per-zusterlobby-veld in de aanvraag, en daarom kunnen zusterlobbies niet in modus, kaart of modifikatiechips uit elkaar lopen. En het antwoord geeft de gepraaide lobby-id’s terug, waarbij alleen de eerste gelijst is — het antwoord zelf toont de poolvorm (N id’s, één openbare listing), exact de vorm die een speler nooit van de clientkant ziet.

Je gaat deze route waarschijnlijk niet zelf aanroepen: het is een administratie-bot-toegangspunt, en het openbare spelpad is simpelweg “join een gelijste kaart en laat de server je routeren”. De route telt voor deze handleiding omdat hij de feitelijke waarheid is voor elk getal in de tabel hierboven — groottebeperking, alleen-gepubliceerde-ingang, gedeelde configuratie, alleen-bij-creatie-bestaan — en als een toekomstige versie een van die getallen verandert, is de validatie- en antwoordvorm van deze route de plek waar de verandering eerst zichtbaar zal zijn.

Voor de speler die deze route zelf nooit zal aanroepen, is het nuttig om te weten wat de route niet doet, omdat dat de grenzen van het feature definieert. De route creëert de pool in één stap en geeft de gepraaide lobby-id’s terug; ze wijzigt geen bestaande pool, voegt geen zusterlobby toe aan een bestaande gelijste lobby, en kan de poolgrootte niet na creatie veranderen. Dat betekent dat als een host een pool van twee heeft aangemaakt en later merkt dat hij er acht nodig had, de enige optie is de pool te beëindigen en een nieuwe pool van acht aan te maken, wat een nieuwe lobbyid betekent en dus een nieuwe gelijste kaart. Voor een terugkerend evenement is dat een eenmalige beslissing die je vóór het evenement neemt; voor een losse sessie betekent het dat de poolgrootte een vooraf besloten variabel is, niet iets dat je tijdens het spel kunt aanpassen. De route is dus het bewijs dat de pool een atomair object is: de beslissing over grootte, configuratie en listing wordt één keer genomen, en alles dat daarna gebeurt is het gevolg van die één beslissing.

Wat in je eigen sessie te controleren is

Omdat pools van de client onzichtbaar zijn, is de enige eerlijke verificatie die je kunt doen gedragsgestemd, en die vereist één enkel spel:

1. Join een gelijste kaart die je voor een pool houdt (een gelijste lobby die door een host tijdens een evenement is aangemaakt, is het waarschijnlijke geval) en noteer in welke lobby je laadt.
2. Vraag een vriend die tegelijk dezelfde kaart joinde in welke lobby hij laadt. Als hij in een andere lobby met dezelfde modus, dezelfde kaart en hetzelfde starttijdstip is, was de kaart een pool en heeft de routing gewerkt zoals gedocumenteerd.
3. Als jullie allebei in dezelfde lobby zijn, is de poolgrootte dan één (geen pool) of hebben jullie twee hashes gecollideerd; met een pool van acht is de botsingskans 1 op 8, dus is één enkel zelfde-lobby een zwak bewijs aan beide kanten — herhaal met meer vrienden voor een sterker signaal.
4. Als je in plaats daarvan door een “Turnstile token rejected” of een kick naar het menu word gewezen, is het geen pool-uitslag: pas de storingstegengaan hierboven toe vóórdat je de routing iets toeschrijft.

De negatieve caso is zo belangrijk als de positieve: als een gelijste kaart je over meerdere onafhankelijke spellen niet van een vriend scheidt, is de kaart dan geen pool (of is de poolgrootte één). “Deze kaart brengt me altijd in dezelfde lobby als mijn vriend” is in een poolomgeving het signaal dat de pool niet aanwezig is.

Deze checklijst is bewust van de goedkoopste check naar de duurste, en de eerste twee vragen sluiten de meeste gevallen al af voordat je verder hoeft te kijken. Als je in een andere lobby belandt dan je vriend en je weet dat de kaart een pool is, dan is het antwoord al gegeven door de routing- en exemptierij: of je vriend is herverbonden (en dus exempt) of hij staat op de whitelist (en dus exempt) of jullie hashes hebben gecollideerd (1 op N). Als je in plaats daarvan een foutkader ziet direct na join, dan is het antwoord de clientgedrag-rij en de oplossing is het tabblad sluiten en opnieuw joinen via de gelijste kaart, niet het probleem opnieuw proberen in hetzelfde tabblad. De reden om de checklijst in deze volgorde te lezen is dat elke check een andere laag van het probleem benadert — eerst of het een pool is, dan of de routing het gedaan heeft, dan of het een clientprobleem is, en tenslotte of het een versieprobleem is — en als je de volgorde omdraait, spendeer je tijd aan een dure check (de versienummer) die een goedkope check (het tabblad sluiten) had kunnen overbodig maken.

Samenvatting

Een lobby-pool is een capaciteitsmechanisme, geen doelkeuze: één gelijste kaart, tot acht ruimtes, één gedeelde start, één vastgezette configuratie en een deterministische hash die nieuwe komsten over de ruimtes verspreidt. Je kiest de zusterlobby niet, je kunt de zusterlobbies niet zien, en je kunt de totale poolbezetting niet zien — de kaart is alles wat je krijgt, en de modus, de kaart en de teller van de kaart zijn nog exact wat ze beloofden. De beslissingen die veranderen zijn de sociale: spelen in dezelfde ruimte vereist een whitelist, teamspeel vereist een plan voor de slechtste loterij, en een “gewezen”-symptoom vereist de vierledige storingdiagnose vóórdat het aan de routing wordt toegeschreven. Sinds v0.34.20 werkt het mechanisme zoals de versie-opmerkingen het beschrijven; vóórdat was het aangekondigd maar niet productief.

Als je alleen drie dingen uit deze handleiding wilt onthouden omdat je de rest niet leest, zijn het deze: eerst, een pool deelt de modus, de kaart en de countdown van de ingang met al zijn leden, dus als je een gelijste kaart joint en in een ruimte met dezelfde modus, dezelfde kaart en dezelfde countdown belandt, dan is dat een pool en niet een ander spel. Tweede, de server verspreidt nieuwe komsten over de leden maar verplaatst nooit spelers die al in een lobby zitten, en herverbindingen, toeschouwers, whitelist-spelers en admins zijn exempt van het routing, dus een “weggestuurd”-ervaring is iets dat maar één keer per join gebeurt en je nooit raakt als je terugkeert. Derde, het feature is actief sinds v0.34.20 en daarvóór niet, dus de enige check die je vóór alles anders moet doen is de versienummer van je client. Deze drie punten dekken de meeste situaties die in de community-draden naar voren komen, en als je ze internaliseert, verwar je poolgedrag niet meer met storingen en weet je dat de storingsectie de juiste bron is als je iets ziet dat niet hieronder valt.

Eén laatste grens die je uit dit geheel moet trekken is wat de pool niet voor je beslist. De pool beslist niet voor welke zusterlobby je gaat (dat is de hash), het beslist niet of je samen met een vriend belandt (dat is de whitelist), het beslist niet of de compositie past bij je rol (dat is je eigen beslissing vóór de klik), en het beslist niet of de kaart de juiste is voor wat je wilt spelen (dat is de kaartkeuze in de open browser). De pool doet precies één ding: het verspreidt nieuwe komsten over een groep identieke ruimtes zodat de gelijste kaart joinbaar blijft terwijl de effectieve capaciteit groter is dan één ruimte. Als je die één functie los kunt zien van alles wat je de pool soms toedraagt — samen spelen, een bepaalde lijst, een bepaalde tegenstander — dan heb je de hele handleiding geïnternaliseerd, want alles wat je daarna ziet is of de pool die ene functie doet (goed, geen storing) of iets anders dat een storing is (zie de storingsectie).