Since pixel dimensions in SetPadding() are scaled by GUI size, padding for inset viewports was excessive.
Instead, automatically apply padding for WWT_INSET at widget level. This applies to all widgets inside a WWT_INSET, which in all instances is a NWID_VIEWPORT.
This meant that on opening the Multiplayer window, if you had more
than one server configured, it would one by one cancel all pending
queries and send a new. Result: only the last server was updated.
The most common case never needs access to it anymore. Make the
one exception to this explicit. This means the fact that we
store it is now an implementation detail.
If the highscore/news window panel size, which is now scaled by GUI zoom, is larger than the screen size, a loop will be entered where the window is repeatedly resized.
This is resolved by removing the minimal size from the panel, as the window is always resized to cover the screen anyway. This means the screen size can never be too small.
Hostnames like "content.openttd.org" resolve into multiple IPv4 and IPv6.
It is possible that either of the IPs is not working, either due to
a poorly configured OS (having IPv6 but no valid route), broken network
paths, or a service that is temporary unavailable.
Instead of trying the IPs one by one, waiting for a 3s timeout between
each, be a bit more like browsers, and stack attempts on top of each
other with slight delays. This is called Happy Eyebells.
Initially, try the first IPv6 address. If within 250ms there is no
connection yet, try the first IPv4 address. 250ms later, try the
second IPv6 address, etc, till all addresses are tried.
If any connection is created, abort all the other (pending) connections
and use the one that is created. If all fail 3s after the last connect(),
trigger a timeout for all.
We now resolve the connection_string to a NetworkAddress in a much
later state. This means there are fewer places constructing a NetworkAddress.
The main benefit of this is in later PRs that introduce different types
of NetworkAddresses. Storing this in things like NetworkGameList is
rather complex, especially as NetworkAddress has to be mutable at all
times.
Additionally, the NetworkAddress is a complex object to store simple
information: how to connect to this server.
Split the updating in a "static" version that only needs to be called when a new map is loaded or some settings are changed, and a "dynamic" version that updates everything that changes regularly such as the current game date or the number of spectators.
english (us): 1 change by 2TallTyler
estonian: 49 changes by siimsoni
korean: 1 change by telk5093
hungarian: 45 changes by baliball
finnish: 12 changes by hpiirai
spanish: 1 change by JohnBoyFan
Loïc Guilloux