s2protocol
s2protocol copied to clipboard
Blizzard
--metadata MMR static for unranked games, and missing for teams
Figured I would lump the two things I have noticed into one ticket. If you would prefer I can break them apart.
But I have implemented the metadata processing into my version of s2protocol and have been processing replays for about a week now with it. Looking at someones account that I know are unranked replays, his mmr is always 4190, win or lose. This might be expected, but I actually expected the mmr value to still change for an unranked game (just not displayed on the UI).
Example unranked replays. http://sc2replaystats.com/download/4483632 http://sc2replaystats.com/download/4483619
For teams, it seems like 99% of the time an mmr value is not returned. Have been unable to see the pattern for why they return. But here is an example of a replay where i'm ranked as random teams (m3 I believe, dont know my mmr off hand)
http://sc2replaystats.com/download/4445995
In this example claptrap has an mmr value but breath and other do not (claptrap and breath queued together)
Ok, so this looks like an oversight on the code writing the metadata file. It's writing individual race MMR if that exists else none. It is not writing the team MMR.
We are reviewing the issue log when I get back to the US next week. We'll have to get this fixed on the next client update.
Any news on this, does not seem that a fix made it into the next client update (unless it waited for a major patch).
Would be awesome if this gets fixed in 3.13.0
I haven't had time to work on this till yesterday. I'm hoping to get a fix for 3.15 but there seems to be a deeper fix that's required in the code to handle dumping all the metadata. Investigating.
Question related to the mmr, I noticed that the replay file has the mmr at the time the game starts, does the calculation happen at a point where we could get both the starting mmr and the mmr change after the game in the replay file ? Would be super useful to know both.
I made a change in 3.15 that will include the scaled rating (MMR) in the init data. This is the rating that was used by the matchmaker to form the game. I tested it with multiple game modes. Hopefully this addresses the issue.
There are multiple issues with the replay metadata file so we are talking about deprecating it in future releases. Let's follow up on this when you have a chance to look at some 3.15 replays.
Thanks for your patience!
I use two things out of the metadata file, the mmr and apm. I could go back to calculating the apm my self, but I have no solid way to get the mmr without it being in the replay file so if this is deprecated I would want it somewhere else. Its a huge feature for me. Thankfully it works in 1v1 ranked games which is what I mostly see.
Yes, there will be a new value of m_scaledRating available on all initial user info structures in every replay. It will only be set in game modes that are using it.
The APM value is interesting but it might be more valuable to calculate yourself. Average is loses a lot of interesting data. Average, min and max for the whole match as well as how it changes seem really interesting and lost by a single average statistic.
Not sure if this is a typo " scaled rating (MMR) in the init data. This is the rating that was used by the matchmaker to form the game" currently in 3.14 the mmr value that is being returned is the mmr at the time the game started aka when the game was formed by matchmaking.
Example being the last game I played http://sc2replaystats.com/download/4965419 the replay has my mmr at 4660 (I lost) and now my mmr is 4640. The 4640 is the new value I would like in the replay file along with the previous value. Or another option would be to show the change amount of mmr since that's really i'm after. On this replay of course the change amount for me was -20mmr
RE: MMR change
You're correct, the game replay only has the MMR at the time the match started.
I did look at reporting the updated MMR as well as I agree it would be very nice. However, the end of game statistics update is delivered out of the game (this is the update that includes the change in MMR, league promotion and other data). I would have to change the end of game message flow to include this information to the clients so it could be written to the replay. This scope of change didn't fit in with all the other things we're currently working on :(
One option I considered is to figure out what the projected delta is at the beginning of the game so based on the win/loss result you could calculate the end-of-game MMR. There are cases where this is not strictly accurate however, for example when we are doing the initial bootstrapping of player MMR. We over-correct the MMR based on a hidden value for new players to help them get into what we believe will be a statistically more accurate place based on our historical data.
I figured the MMR was changed after the game, seems like changing that scope might have some bad side effects since you have introduced 'Rewind'. You stay in the game but instantly jump into the replay at which time the replay is saved, but I don't believe your MMR values have been recalculated at that point.
For my use case the MMR delta would do the trick, and I could deal with the small % that its off on. Initial players MMR flux I believe is 25 games which for most players is a very small subset of games they play. Granted I know if they go multiple seasons without playing they will hit that initial setup again.
Another option with the delta route is you could include a % of how likely it is accurate based on if they happen to fall into an edge case, though its possible you don't have that information up front.
The m_scaledRating seems to be working, I have noticed that a bunch of replays have a scaledRating of -36400 not sure exactly why. This season I have seen 3731 1v1 ladder games where it has happened (so super small % like 2% or so)