Motivation / Problem

Currently sending the NetworkGameInfo data to a client entails copying the data from all kinds of locations into a just allocated structure and then throwing it away after that. The problem is that except for 4 things, the rest is pretty must static data. So effort is placed into copying the data, instead of just having it ready and only updating those 4 things.

Description

First move more from NetworkGameInfo to NetworkServerGameInfo. NetworkServerGameInfo already contained "clients_on" and updated that via a global variable of it. After that return and pass that global variable into the serialization functions after updating it. That saves already the copy of that "clients_on" variable from one structure to another.

Next split the "static" and "dynamic" things; clients/companies/spectators on as well as the date are considered dynamic. The rest, such as revision, map size, start date, server name, maximum number of clients and so on are considered "static". These static ones will be updated in a callback of the appropriate settings (most already had one), and upon starting the game.

Bonus: renamed map_set to landscape, as that's more in line with how it's called in other places.

Limitations

None.

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')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker