Remove "map_name" and "language" from network protocol / GUI #9070
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The idea back in the days was nice, but it never resulted in anything useful. Most servers either read "(loaded game)" or "Random Map", neither being useful. It was meant for heightmaps, so you could find a server that was using a specific one .. but there are many things wrong with that idea. Mostly, servers tend to save and load savegames from time to time, after which the original heightmap used was lost. All in all, removing map_name all together is just better.
The original idea was that people could find a server they could talk in their native language on. This isn't really used in that way. There are several reasons for removing this: - the client also sends his "language" to the server, but nothing is doing anything with this. - flags are a bad way to represent languages, and over the years we had several (rightfully) complaints about this. - most servers have their language set to "All", and prefix the servername with the language it is about. This is a much more efficient way to do the same. All in all, this feature should go back to the drawing board. Maybe it could work in another form, but this form is not it.
LordAro
approved these changes
Apr 20, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation / Problem
Back in 2007 or so we added two fields to the server info:
map_nameandlanguage. Both have their own story, and this PR removes them both.Description
map_namewas intended so people could find a server with a certain scenario/heightmap they liked. But, looking at the current serverpool, most are(loaded game)orRandom Map. It never really worked, as the implementation is flawed anyway. The original scenario/heightmap a game started with is not stored, so if you save/load, that information is already gone.If we want to do this feature, we should approach the problem differently. As such, I removed it now (well, replaced it with an empty string). This allows someone else to start fresh again if this functionality is still wanted. But given that nobody ever mentioned it either way, I doubt that being the case.
languageis a bit more political. After introduction we got quickly told that using flags for language is a stupid idea. And I agree. Especially in 2021, that is just no longer socially acceptable (it wasn't back in 2007, but we got away with it :P). So I was wondering if we should replace it with something else. But a quick look to current servers, I noticed most just put it to All, and prefix their server name with the language. Which is a lot more effective way of doing this.Additionally, in this day and age, many multiplayer games are more adhoc; especially if the STUN integration lands, people are just quick to join their friends game. And language is completely irrelevant.
Lastly, clients also send their language to the server, to be completely ignored once it arrived there. I doubt anyone knew about this feature.
After some internal debating, I came to the conclusion it was just better to remove language support. If this really is a feature people like, we need to think about the problem again and find a better way to implement it. A way that people will use and doesn't involve flags.
Limitations
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.