Reworking of how map names are handled

[Cepheid-UK]

This is a good standalone project for anyone interested.

Right now, map file names are fed to the website-backend from the matchmaking-service, the website-backend does this before it sends to the frontend:

https://github.com/w3champions/website-backend/blob/237cd0821094d6b0fc289262324fd7cbbd5ab103/W3ChampionsStatisticService/Matches/MapName.cs#L9

Then on the frontend, we apply translations to these strings:

website/src/locales/en.ts

Line 60 in 3a0df7c

twistedmeadows: "Twisted Meadows",

This can lead to some nasty gore on the frontend before we add the translations, and it also means that updating a map (even very minorly) means duplicate names.

The matchmaking-service has access to the metadata of maps, one field is the actual name of the map in text, e.g. "Twisted Meadows", and we can serve this to website-backend, and then pass on after validation checks to the frontend.

This will require a senior dev to make the relevant change to matchmaking service, but the rest can be handled on the open source repos.

[osagemo]

This seems to be partially resolved in the following commits:

w3champions/website-backend@fb82177
2863272

So the matchmaking-service has been updated and we get the name & id from the metadata. This has been added to ongoing and finished matches in the backend and the "MatchesGrid" has been updated to use the new map name in the frontend.

I was able to find and update other components reading the mapname from matches in the frontend.

There are remaining statistics components (If I'm not mistaken) reading the map names "the old way", due to map name not being added to the statistics related models:

(VueComponent - Backend Model)

• MapSelect - MapsPerSeason
• MapsPerSeasonChart - MapsPerSeason
• RacetoMapStat - OverallRaceAndWinStats
• WinratesTab - OverallRaceAndWinStats

Is the intention to update these models the same way (using map name from metadata)? Any considerations with regards to past data? I would need some direction and discussion to tackle this

[zygissss]

done

[cmavelis]

I'm looking to get back into working on the website and noticed the map name gore on a stats page today. What's the status of this issue? Still some backend work needed for the models?

[osagemo]

No news from my side.

[Cepheid-UK]

I did the investigation on how to fix this once and for all:

Right here is where the name of the map is picked up in website-backend:

In the MatchFinishedEvent this looks something like this:

The MapName class now does this absolutely disgusting string mutilation:

Meanwhile, the MatchFinishedEvent already has the data right here in a much nicer form:

Therefore we should do something like:

However, a few hiccups.

Firstly, and very easily, the website-backend data model needs to understand and parse this from the response (this line doesnt currently exist):

and secondly, and much more of a problem, this mapInfo field looks to be using whatever the game client sends MatchmakingService:

As you can see, this is not english:

Therefore, we need the Matchmaking service to populate that field with it's saved "rational" name in the database for that map, by referencing it against the mapfile path, and ideally sending the map ID as part of that object.

Here is how the data is saved in the Matchmaking database for a map:

[Cepheid-UK]

Actually, I just noticed something that could make life a little easier.

1. The MatchFinishedEvent does actually have the mapId in the object:
   

2. We have an website-backend endpoint that has all the map info for the current season maps: https://website-backend.w3champions.com/api/maps/currentseason
   

Proposed solution:
Have website-backend cache the response from that endpoint, and cross reference the mapId to the name.

Then we add the mapId to the database entries, and get the counts by the ID, and not the Map:

[cmavelis]

These ids look to be by season, but we'd want them to be global, no?