It now follows very simple rules:
0 - Fatal, user should know about this
1 - Error, but we are recovering
2 - Warning, wrong but okay if you don't know
3 - Info, information you might care about
4 -
5 - Debug #1 - High level debug messages
6 - Debug #2 - Low level debug messages
7 - Trace information
The code mixed up "client has quit but we already told everyone"
with "client lost connection, handle this".
Split up those two signals:
- CLIENT_QUIT means we told everyone and the connection is now dead
- CONNECTION_LIST means we should tell everyone we lost a client
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.
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.
Under normal circumstances the server's ID is 32 characters excluding '\0', however this can be changed at the server. This ID is sent to the server for company name hashing. The client reads it into a statically allocated buffer of 33 bytes, but fills only the bytes it received from the server. However, the hash assumes all 33 bytes are set, thus potentially reading uninitialized data, or a part of the server ID of a previous game in the hashing routine.
It is still reading from memory assigned to the server ID, so nothing bad happens, except that company passwords might not work correctly.
(cherry picked from commit 56aa6d0edd)
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.
Under normal circumstances the server's ID is 32 characters excluding '\0', however this can be changed at the server. This ID is sent to the server for company name hashing. The client reads it into a statically allocated buffer of 33 bytes, but fills only the bytes it received from the server. However, the hash assumes all 33 bytes are set, thus potentially reading uninitialized data, or a part of the server ID of a previous game in the hashing routine.
It is still reading from memory assigned to the server ID, so nothing bad happens, except that company passwords might not work correctly.
One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list.
Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
This means that pressing Refresh button and adding servers manually
now uses TCP.
The master-server and initial scan are still UDP as they will be
replaced by Game Coordinator; no need to change this now.
If we query a server that is too old, show a proper warning to the
user informing him the server is too old.
The lobby of a server requested some parts via UDP and some via
TCP. This is strictly seen fine, but for future extensions it
is a lot easier if just one protocol is used.
The GUI now more clearly shows some basic information about the
server you joined, your client name (and the ability to change it),
and what players are in which company.
It also contains useful buttons to press to join companies, chat
with other people, and for admins to kick/ban people.
Additionally, renamed "advertised" to "visibility"; this has to
do with future additions, but also because it is more clear in
wording.
This is a much better location for this button, as you send
money from one company to another company, not from player
to player.
This is based on work done by JGRPP in:
f820543391
and surrounding commits, which took the work from estys:
https://www.tt-forums.net/viewtopic.php?p=1183311#p1183311
We did modify it to fix several bugs and clean up the code while
here anyway.
The callback was removed, as it meant a modified client could
prevent anyone from seeing money was transfered. The message
is now generated in the command itself, making that impossible.
Check if the job is still running two date fract ticks before it is due
to join, and if so pause the game until its done.
When loading a game, check if the game would block immediately due to
a job which is scheduled to be joined within two date fract ticks,
and if so pause the game until its done.
This avoids the main thread being blocked on a thread join, which appears
to the user as if the game is unresponsive, as the UI does not repaint
and cannot be interacted with.
Show if pause is due to link graph job in status bar, update network
messages.
This does not apply for network clients.
