bump
Replay search tools are not powerful enough
I looked into it yesterday. It's neither simple nor straightforward with the way our api works internally and the different ratings that could affect a single game.
He said, "I've been to the year 3000
Not much has changed, but they live underwater
And your great-great-great-granddaughter
Is playin' FAF, playin' FAF"
I've found the search tools to work pretty badly in general. Searching for a replay that includes more than one playername, for example, hasn't worked for me in ages. Search has also been very very slow for as long as I can remember.
SQL database are not build for flexible queries on 1:n data (1 game n players).
It's also not designed to run fuzzy text search (a map or mod name where i don't know exactly where whitespace and apostrophes are).
But: most software can't. Look at this forum: it's running on a document oriented db but it has the same search limitations.
Most of the smaller applications in the world behave like that.
He said, "I've been to the year 3000
Not much has changed, but they live underwater
And your great-great-great-granddaughter
Is playin' FAF, playin' FAF"
And you can search by game name, look for games with things in the title like "2k+" "2000+" "1.9k" etc.
Is the replay database schema published somewhere? The search function is pretty limited, but I can write my own SQL search filter. I have no idea what the available fields are. I'd need the table layouts.
Nvm, I found it!
https://faforever.github.io/db/relationships.html
Hopefully, this is up to date.
Not sure I can do a table join in the client. I need to figure out how to run an arbitrary query so I can play around with it.
For the OP's problem, searching for high-rated players is about the best you can really do.
There probably are not many 4v4 games where everyone is 2000+. There just aren't many players at that level.
@PViddy The problem can never be solved with a SQL join.
What happens in the API is this: perform the join, then filter.
So first you join a game and get a result like:
game | player | rating |
---|---|---|
1 | A | 1900 |
1 | B | 1900 |
1 | C | 1900 |
1 | D | 2100 |
2 | A | 1900 |
2 | B | 1900 |
2 | C | 1900 |
2 | D | 1800 |
3 | A | 2200 |
3 | B | 2100 |
3 | C | 2200 |
3 | D | 2000 |
And now you filter rating>=2000 on all records of that table. So the result would be this:
game | player | rating |
---|---|---|
1 | D | 2100 |
3 | A | 2200 |
3 | B | 2100 |
3 | C | 2200 |
3 | D | 2000 |
It's easy to find a game where on participant matches a criterium.
But there is no row-based filter in SQL that could require all players to be >=2k.
For that you need either SQL subselects (which is not supported by our API logic for technical reasons) or we calculate somehting like min/max/mean rating during fetching the game in the API.
The latter is generally possible, but not so simple with our API logic, because a game participant has potentially multiple leaderboards, so it need to return these KPIs per leaderboard (even though in practice each game right now has only one leaderboard).
He said, "I've been to the year 3000
Not much has changed, but they live underwater
And your great-great-great-granddaughter
Is playin' FAF, playin' FAF"