Skip to content

feat(lobby): Retry failed peer connections and block the start until everyone is connected - #669

Open
tintinhamans wants to merge 26 commits into
GeneralsOnlineDevelopmentTeam:mainfrom
tintinhamans:arctic/go/feat/lobby-connection-retry-v2
Open

tintinhamans wants to merge 26 commits into
GeneralsOnlineDevelopmentTeam:mainfrom
tintinhamans:arctic/go/feat/lobby-connection-retry-v2

Conversation

@tintinhamans

Copy link
Copy Markdown

Merge after #656 and #625. The branch merges #625 into the network stack, so the diff against main shows both; the only new code is the last commit.

In a custom lobby a peer link that fails to come up is dropped after two signalling attempts and nothing tries it again. The host can still press Start with a player who has no link to the others, and a failed link in a quick match sends everyone out of the lobby.

This retries failed peer links. The later joiner of a pair keeps signalling, a manual lobby stays open when links run out, and the button turns into "Retry connections" while a link is down. A retry uses a longer timeout than the first negotiation, and an incoming connection gets the same timeouts. A peer that left cleanly is never retried, it is dropped from the mesh as #625 does.

Start follows one rule. It is enabled only when every human in the lobby has a slot and we hold a connected link to every human. The mesh check and the final check before the match both use that rule, and a start attempt that no longer matches the lobby is dropped. If the lobby lists someone the game has no slot for, the lobby is refreshed every few seconds. The 30 second timeout of the mesh check from #625 still ends the check and gives the Start button back.

One new key in the connection group of the service config, read like the others from #656: connection.reconnect_timeout_ms (30000, clamped between 10000 and 60000). connection.retry_signalling is already there from #656 and gates the retry. A missing key keeps the default.

Tested: x86 Release z_generals builds. Not played yet.

tintinhamans and others added 14 commits October 24, 2026 21:26
…ile::getFileInfo(), StdBIGFile::getFileInfo() (TheSuperHackers#3415)

(cherry picked from commit b805c12)
…File (TheSuperHackers#3505)

Both classes are identical apart from their name and contain no platform specific code.
Nothing in them depends on the BIG format either: they open a file from an offset and a
size inside the archive file. ArchiveFile takes over their functions and is no longer an
abstract class.

(cherry picked from commit 52a777a)
…ystem into BIGFileSystem (TheSuperHackers#3505)

Both classes are identical apart from their name and go through the local file system
for all file access. The one class that remains sits next to ArchiveFileSystem in
Core/GameEngine.

(cherry picked from commit e4b4d1e)
…e loadBigFilesFromDirectory (TheSuperHackers#3505)

loadMods refers to BIG files, which nothing else in ArchiveFileSystem does. It becomes a
virtual function that BIGFileSystem implements. loadBigFilesFromDirectory is renamed to
loadArchiveFilesFromDirectory, because the base class is not tied to one archive format.

(cherry picked from commit f299561)
@tintinhamans
tintinhamans force-pushed the arctic/go/feat/lobby-connection-retry-v2 branch from 70788e8 to 6f8af97 Compare October 25, 2026 05:21
@tintinhamans
tintinhamans force-pushed the arctic/go/feat/lobby-connection-retry-v2 branch from 6f8af97 to 26b98fa Compare October 25, 2026 11:16
@tintinhamans
tintinhamans force-pushed the arctic/go/feat/lobby-connection-retry-v2 branch from 26b98fa to 4525f55 Compare October 25, 2026 12:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants