Opened 8 years ago

Closed 7 years ago

#3686 closed defect (fixed)

Lobby - Slow rating updates break rejoining

Reported by: elexis Owned by:
Priority: Should Have Milestone: Alpha 22
Component: Multiplayer lobby Keywords:
Cc: scythetwirler Patch:

Description (last modified by shookees)

Since some days there are experimental lobby changes to reduce the updates that the bot sends. This definitely helps with the performance, but it has a side effect.

It takes like 2-3 seconds for the ratinglist to appear.

  • If you join a game before the ratinglist is loaded, you will join under "username".
  • If you join a game after the ratinglist is loaded, you will join as "username (rating)".

This means that it's sometimes impossible to rejoin games without understanding this bug.


Solution: Send the ratinglist / rating for the current user instantaneously and/or prohibit lobby joins before the rating is loaded.

Change History (15)

comment:1 by Josh, 8 years ago

It was non-optimal to include the rating in the username in the first place. It should be an independent variable. For example, I don't believe the current system allows players to rejoin lobby games by direct IP.

in reply to:  1 comment:2 by leper, 8 years ago

Replying to Josh:

I don't believe the current system allows players to rejoin lobby games by direct IP.

It does though.

comment:3 by elexis, 8 years ago

Milestone: Alpha 20Backlog

Backlogging due to lack of progress.

comment:4 by elexis, 8 years ago

Still happens with #3022, just less frequently.

comment:5 by elexis, 8 years ago

Keywords: simple added

comment:6 by scythetwirler, 8 years ago

Should happen even less often (if at all) with the latest optimizations to the bot.

comment:7 by elexis, 7 years ago

Still occurs as of Alpha 21. It can be solved by the client clicking on his own user profile before joining, so it should be fixable by issuing that request on init in lobby.js, or finding some bug in XPartaMupp.py (which would require ejabberd to debug).

comment:8 by Josh, 7 years ago

I am still of the opinion that the rating should be stored separately. Adding a rating lookup function to the C++ side would allow for that.

comment:9 by elexis, 7 years ago

Milestone: BacklogAlpha 22
Priority: Must HaveRelease Blocker

This is happening too often.

comment:10 by shookees, 7 years ago

Description: modified (diff)

Games shouldn't be identified by name, especially when it is not constant

comment:11 by elexis, 7 years ago

refs #4621

comment:12 by elexis, 7 years ago

Keywords: simple removed
Patch: Phab:D670

comment:13 by elexis, 7 years ago

In 19828:

Allow lobby players to rejoin games, even if the rating changed meanwhile or if the lobby bot didn't provide the most recent rating.

Refs #3686
Differential Revision: https://code.wildfiregames.com/D670
Reviewed By: Imarok

comment:14 by elexis, 7 years ago

Milestone: Alpha 22Backlog
Patch: Phab:D670
Priority: Release BlockerShould Have

With r19828 the three cases where players can't rejoin games anymore are covered:

  • lobby bot being too slow with providing players the ratinglist on init or not providing it at all
  • #4621: lobby bot not providing the updated ratinglist to players returning from a rated game
  • Also if a player plays a rated game and rejoins a game started before then works.

So it is not imminent to fix anymore. But the original issue of the lobby bot being too slow described here is probably still not fixed. We should report whether we could still experience the issue.

Removing the rating from the nickname has the advantage of being able to remove that 4 line workaround, but will also need many new lines in all GUI pages that display playernames (gamesetup, session, summary, replaymenu) and sounds like material for a separate ticket. However replacing the simulation playername with a GUI generated one will be needed for #3307.

comment:15 by elexis, 7 years ago

Milestone: BacklogAlpha 22
Resolution: fixed
Status: newclosed

Calling this fixed.

Removing the rating from the nick must be carefully considered and should be done in a separate ticket.

The bot is now allowed to be slow, the other reported bug is reported at #4621.

Note: See TracTickets for help on using tickets.