You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are planning on moving rating data from the current tables to new more generic tables created in this PR: FAForever/db#197. The purpose of these new tables is to support more than 2 rating types, primarily for team matchmaking.
The client needs to be able to store arbitrarily many different rating types for each player. This means among other things, moving the globalRating and leaderboardRating properties on the Player class to some get/set table with string keys. Each rating type (referred to in the database as a leaderboard) has a technical name used to identify it. The technical names for global and ladder are global and ladder_1v1 respectively as defined here FAForever/db#217. We may want to add a KnownRatingType enum with these values as there are special cases for them all over the code.
I'm against spawning more KnownSmthType. You just wrote in Zulip:
For a similar reason I don’t think we want an enum for LadderQueue. Which queues are available depends entirely on the server. Some queues may not be permanent (special event queues that run for a month or whatever). At most I think it would be ok to have a special case for 1v1 because that is pretty much guaranteed to be permanent
That's why we do not need to hardcode rating type technical names either. What if we would like to display a rating for some temporary event queue? It will require changing the client code, that is not acceptable, right?
Maybe we can receive all ratings entirely from the server (or rest API) along with their parent queue titles and populate the UI with them?
Yes but currently global and ladder ratings have special cases everywhere. We won't be able to get rid of them in one pass, we will need to do it incrementally.
We are planning on moving rating data from the current tables to new more generic tables created in this PR: FAForever/db#197. The purpose of these new tables is to support more than 2 rating types, primarily for team matchmaking.
The client needs to be able to store arbitrarily many different rating types for each player. This means among other things, moving the
globalRating
andleaderboardRating
properties on thePlayer
class to someget/set
table with string keys. Each rating type (referred to in the database as aleaderboard
) has a technical name used to identify it. The technical names for global and ladder areglobal
andladder_1v1
respectively as defined here FAForever/db#217. We may want to add aKnownRatingType
enum with these values as there are special cases for them all over the code.Todo list:
player_info
: https://github.com/FAForever/server/blob/5be249b4d2de29667aad9ae035567bda8e638087/server/players.py#L151rating_type
property of thegame_info
message for determining which rating to display.https://github.com/FAForever/server/blob/5be249b4d2de29667aad9ae035567bda8e638087/server/games/game.py#L865
Wanna have the bug fixed quickly?
Visit Issue hunt...
The text was updated successfully, but these errors were encountered: