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

Implement a way for the party leader to determine whether party members are still in-game #703

Closed
cleborys opened this issue Jan 21, 2021 · 2 comments · Fixed by #831
Closed

Comments

@cleborys
Copy link
Member

I just had @BlackYps fill me in on the current state of TMM and he brought this up as an open issue but we didn't find a ticket:

It seems that when a player exits a game (or maybe just a TMM game) early, they cannot queue up for TMM again before the game has finished since the party leader will believe they are in an active game. That seems to be because the party leader checks the player lists of active games in game_info to determine whether a party member is still in-game, but this list shows all players present at game start and not players currently in the game.

As far as I'm aware there is currently no way for the server to know that a player has left a game before it ended. BlackYps opened FAForever/downlords-faf-client#2125 for a message to be sent by the client in that case.
To resolve this it seems likely that either the player lists in game_info need to be updated on such messages or a player in-game status that is broadcasted should be added.

@BlackYps
Copy link
Collaborator

To be more precise the client checks the players' status that is set every time a message from the server comes in with the list of active games. Because of this is it probably easier (from the client's point of view) to have the player be removed from that list the server sends, because then we don't have to touch the client's logic that determines if a player is in a game.

@Askaholic
Copy link
Collaborator

This is another issue with the Game code being a complete mess. The Game.players property is pretty complicated:

server/server/games/game.py

Lines 167 to 190 in 2cd034c

def players(self):
"""
Players in the game
Depending on the state, it is either:
- (LOBBY) The currently connected players
- (LIVE) Players who participated in the game
- Empty list
:return: frozenset
"""
if self.state is GameState.LOBBY:
return frozenset(
player for player in self._connections.keys()
if player.id in self._player_options
)
else:
return frozenset(
player
for player, army in (
(player, self.get_player_option(player.id, "Army"))
for player in self._players
)
if army is not None and army >= 0
)

server/server/games/game.py

Lines 674 to 683 in 2cd034c

async def launch(self):
"""
Mark the game as live.
Freezes the set of active players so they are remembered if they drop.
:return: None
"""
assert self.state is GameState.LOBBY
self.launched_at = time.time()
self._players = self.players

It freezes the player list when the game is launched, because it needs to know who's game_player_stats records to update when the game finishes. It used to need this because game_player_stats contained the rating changes, but with the new leaderboard tables, maybe we can refactor to have the gps entries updated as soon as someone disconnects? Still kindof sketchy, because what if they haven't died, and they manage to reconnect later?

Still, I think we need to simplify the players property to just show currently connected players, and manage the player freezing through a separate attribute.

Askaholic added a commit that referenced this issue Sep 9, 2021
* Fix formatting

* Use connected players for team list in game_info

* Use connected players for num_players
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 a pull request may close this issue.

3 participants