Repository navigation
feat(velocity)!: fill the fullest lobby below a 100-player cap - #89
Merged
Merged
Conversation
Least-occupied-first and the fleet's one-lobby Ready buffer put every player in a lobby of their own: the empty spare was always the least occupied, the first join allocated it, the autoscaler started another empty one, and the next join took that. Joins, lobby kicks and outdated-lobby moves now go to the fullest lobby below GROUNDS_LOBBY_PLAYER_CAP (default 100), and to an emptier one only when every lobby is at the cap. Counts are the larger of the network count and this proxy's own, plus this proxy's open reservations: each pick reserves a place for the player under one lock until they reach a server, leave, or 15s pass, so a burst of joins on one proxy cannot overfill a lobby. Across proxies the cap stays soft by the network count's lag. The plugin instance exposes pickLobby(UUID, String?) with JDK types so plugin-match can place returning players with the same rule and the same reservations, by reflection. BREAKING CHANGE: lobbies fill fullest-first instead of evenly.
pickLobby(UUID, String?, String?) takes the lobby a player queued from as a preference: it wins while it is a current lobby below the cap, counting this proxy's reservations, and the fill rule decides otherwise. plugin-match passes it for returns after a match.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
On stage every player ends up in a lobby of their own. Least-occupied-first (#71) plus the lobby fleet's Ready buffer of 1 cause it: the empty spare is always the least occupied, the first join allocates it, the autoscaler starts another empty spare, and the next join takes that one. Loki shows this on 2026-10-17 between 15:06 and 15:24: lusu007 went to
xrdh2, lusu008 tozlql6, and wohendriik toslxtk, a lobby created at 15:07:52 right afterzlql6was allocated.What
LobbySelection.pick: the fullest current lobby below the cap. When every lobby is at the cap, the least occupied one takes the overflow. Ties break on the name. The outdated-lobby rules stay as they were.LobbyPlacement: each pick reserves a place for the player under one lock. A reservation lasts until the player reaches a server (ServerPostConnectEvent), leaves the proxy, or 15 s pass. A lobby's count ismax(network count, this proxy's playersConnected) + open reservations, so a burst of joins on one proxy cannot overfill a lobby. Across the two proxies the cap is soft: the other proxy's joins show up only through the network count, about 2 s late (service-player sessions, cached).LobbyKickListener, excluding the kicking lobby) and outdated-lobby moves.GROUNDS_LOBBY_PLAYER_CAPsets the cap (default 100). It has noGROUNDS_AGONES_prefix because plugin-match reads it too.GroundsPluginAgones.pickLobby(UUID, String?, String?)uses only JDK types, so plugin-match can call it by reflection (the same pattern it uses for plugin-analytics). Match returns then use the same rule and the same reservations. The third argument is a preferred lobby (the one the player queued from). It wins while it is a current lobby below the cap, counting reservations; otherwise the fill rule decides.Tests
Rollout
Bundle the release into the velocity image (containers), then bump the image tag in deploy. The deploy change for stage (the fleet floor and buffer, plus the cap env) is a separate PR.