Client v1.4.0 Upcoming Features

3

This topic is meant to introduce the new features and updates that are being added to the client for version v1.4.0. As the new PRs are merged they will be added here. The Release is now available https://github.com/FAForever/downlords-faf-client/releases/tag/v1.4.0

0

Client is now released

0

Can you elaborate on this new leaderboard API not allowing replays to be filtered by rating? Is this just not going to be possible at all in the future or will this feature return at some point? And why is it possible to filter them by rating in the older java client version and the python client if it was removed?

0

The old leaderboard access point in the api https://api.faforever.com/leaderboards is being depreciated and will be removed at some point the future since it is all hardcoded. To enable its removal the client cannot access these old endpoints.

The new leaderboard api where we query for the historical ratings for each game at https://api.faforever.com/data/leaderboardRatingJournal currently only stores the mean and deviation not the actual rating itself. This makes searching by rating an underspecified problem. The old format stored the global and ladder ratings as hard coded values however this is not being extended and as mentioned will be removed.

I have inquired if we can include the rating in addition to the mean and deviation and intend to bring back searching by rating in the replays as soon as that happens.

0

Is it not possible to make queries with the API where the value is calculated? In SQL it's actually good practice to not add columns to a table when it could just be calculated instead. Would surprise me if such a seemingly basic thing wasn't supported.

0

Yes, it is possible to add these calculated columns to the MySQL as a calculated column. You could do it in the API but doing such a thing inside the database is like factor 100x faster.
The problem is the efficient usage of indices.
We do not write the queries manually therefore we can't optimize it to maximum efficiency. We'd loose the whole query flexibility that we have right now and also nobody can manage the amount of queries we use in the client today.

This problem goes way beyond SQL best practices. It's a more complex problem. But also it seemed to be hit by a bit of miscoordination. I wasn't aware it was removed, otherwise I would have made workaround suggestions.

I'm in discussion with Sheikah now.