Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove "map_name" and "language" from network protocol / GUI #9070

Merged
merged 2 commits into from Apr 20, 2021

Conversation

@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Apr 20, 2021

Motivation / Problem

Back in 2007 or so we added two fields to the server info: map_name and language. Both have their own story, and this PR removes them both.

Description

map_name was intended so people could find a server with a certain scenario/heightmap they liked. But, looking at the current serverpool, most are (loaded game) or Random 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.

language is 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.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')
TrueBrain added 2 commits Apr 20, 2021
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.
Copy link
Member

@LordAro LordAro left a comment

Fine by me, with good motivation/justification

@TrueBrain TrueBrain merged commit 05612d6 into OpenTTD:master Apr 20, 2021
11 checks passed
@TrueBrain TrueBrain deleted the network-remove-unused-fields branch Apr 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants