Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue/#995 Improve player state tracking #997

Merged

Conversation

Askaholic
Copy link
Collaborator

@Askaholic Askaholic commented Jan 3, 2024

The state tracking was pretty messed up by the fact that the HOSTING and JOINING states don't get set until the game sends back GPGNet messages, so clients could do a game_host and then before their game was opened they could join a matchmaker queue. Once their game opened their player state would be set to HOSTING and any matches that they got would be stuck in the queue until they manually stopped searching because the matchmaker would refuse to launch matches when one of the players had a state other than SEARCHING_LADDER. Even if they closed their game instance, the player state would then be set to IDLE which still would not allow matches to launch.

This also makes an adjustment to how players are considered to be in a game. Now, if players disconnect from the lobby server without sending a GameState: Idle command they will still be considered part of the lobby. This is closer to how the behavior used to be except when someone does leave the game through the 'happy path' by closing their game, they should be completely removed from the internal state and consequently only be re-added when the host sends a new PlayerOption for them. This hopefully will reduce some of the issues that people have reported with there being more people in the lobby when they connect than it says in the client view.

Related to #995
We won't mark it as closing since we should deploy these changes first and watch the logs to see if the issue has actually been solved. There may be other ways still in which the state tracking can go awry.

@Askaholic Askaholic force-pushed the issue/#995-player-state-tracking branch from e91cadc to a080c77 Compare January 4, 2024 01:10
@Askaholic Askaholic force-pushed the issue/#995-player-state-tracking branch from a080c77 to 2633b9b Compare January 4, 2024 01:42
We need to protect against double game_host/join messages which means we
need to establish a time window after a game_launch message is sent
during which we are waiting to see that the game has opened and don't
let the client do any other game related actions. This also means we
need to clean up the GameConnection objects which would previously stick
around forever if a client never responded to a game_launch message.
@Askaholic Askaholic force-pushed the issue/#995-player-state-tracking branch from 2633b9b to c1145b8 Compare January 4, 2024 06:05
@Askaholic Askaholic force-pushed the issue/#995-player-state-tracking branch from c1145b8 to 40a51ba Compare January 4, 2024 06:40
@Askaholic Askaholic merged commit 8dcdbc2 into FAForever:develop Jan 5, 2024
7 of 8 checks passed
@Askaholic Askaholic deleted the issue/#995-player-state-tracking branch January 5, 2024 03:04
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.

None yet

1 participant