- Crashed matches now always appear at the top of your replays
- The limit of 100 replays has been removed. All games your algo has played will now appear.
My Algo S5_Test6 has right now played 1125 matches.
That’s a lot and therefore the call: https://terminal.c1games.com/api/game/algo/102049/matches takes almost 26 seconds.
According to the image below
the ploblem is not the time the download takes but instead probably a very slow operation on the serverside.
Is there maybe a way to make this faster? (Without reducing the amount of matches that get returned)
and a kitchen sink if possible?
Hmmmm thats unfortunate, it seems that the O() is non-linear. I’ll see what I can do today.
Was your solution to drop the User from the result set?
Haven’t made any changes to this yet, could you describe in more detail whats on your mind n-sanders?
In related news: I am seeing a bug in the match history where my own algo is not listed as either the winner or the losing algo! (although it is my match). When I click on a match like this, I can see that the user interface had listed the wrong opponent for me. It seems to do this in way that algo names repeat inappropriately. So one match against Spinach50 is correct and the very next match is said to also be against Spinach50 but is actually against someone else. It also only seems to do this with matches I lose, such that the very next match is affected.
For example, see:
https://terminal.c1games.com/api/game/algo/117203/matches
At some point the JSON data changed from:
"matches": [
{
"id": 847240,
"turns": 7,
"round": null,
"winning_algo": {
"id": 34621,
"name": "Morphling",
"compilationStatus": "Completed",
"lastGameAt": "2018-11-07T03:29:17.325Z",
"elo": 1531,
"language": null,
"createdAt": "2018-11-07T02:25:07.776Z",
"crashCount": 0,
"user": "n-sanders"
},
"winning_user": {
"userID": 3053,
"name": "Nate"
},
"losing_algo": {
"id": 19631,
"name": "William",
"compilationStatus": "Completed",
"lastGameAt": "2018-11-07T04:08:11.627Z",
"elo": 1482,
"language": null,
"createdAt": "2018-10-16T07:32:37.845Z",
"crashCount": 0,
"user": "Stefan"
},
"losing_user": {
"userID": 9065,
"name": "Stefan"
},
"date": "2018-11-07T02:25:28.317Z"
}
Now I see:
"matches": [
{
"id": 6281714,
"turns": 12,
"round": null,
"bracket": null,
"winning_algo": {
"id": 117194,
"name": "🐇_7_0_4",
"compilationStatus": "Completed",
"lastMatchmakingAttempt": "2020-04-08T11:42:43.717Z",
"rating": 2475,
"language": "rust",
"createdAt": "2020-04-07T22:00:03.131Z",
"crashCount": 0,
"team": null
},
"losing_algo": {
"id": 109417,
"name": "potato4",
"compilationStatus": "Completed",
"lastMatchmakingAttempt": "2020-04-08T11:42:42.682Z",
"rating": 2077,
"language": "python",
"createdAt": "2020-02-22T01:30:43.260Z",
"crashCount": 0,
"team": null
},
"crashed": false,
"crash_logs": false,
"date": "2020-04-08T11:14:16.937Z"
},
I don’t know when this change happened (the old snippet is from a while ago) but the winning_algo > user
/ losing_algo > user
and winning_user
/ losing_user
are all gone.
Ok this should be pretty simple to add back in.
We had multiple serializers for algos that we consolidated at some point, but they had some small differences between them so this info may have gotten removed if it was not being used by our frontend.
This endpoint should be significantly faster when a patch releases sometime in the next week or so. @Felix this will resolve your issue.
Just confirming part of the update was that feature being removed. The original implementation hit the database for info about the user per-match, slowing it down significantly. Because this information is not used by our frontend, I am not adding it back to the main endpoint.
However, for anyone who wants to see this old information, I added two query params to the endpoint, limit (integer) and user info, (bool). Appending ?user_info=true will use the old, slower implementation which will provide the original functionality.
Example:
.com/api/game/algo/<algo_id>/matches?user_info=true&limit=3
Will return the first 3 most recent matches and will include the user info n-sanders talked about above.
@RegularRyan I realize my earlier post in this thread about a bug/regression with this new feature might have gone unnoticed! Just above I talked about how some of my matches list the wrong algos playing for my matches.
If you are having any trouble finding one, match 6348269 shows:
“yellow_22” vs. “swsws-worcs-saucer”
When it really is:
“yellow_22” vs “Mazer_emp_test_15”