| Age | Commit message (Collapse) | Author |
|---|
|
|
|
lobby window (#9467)
Nobody really paid attention to the lobby window, and it completely
missed its purpose. Most people don't even wait for companies to
show up, but just hit "New Company".
This in turn means people create a lot of unneeded companies, while
they "just want to watch the game" or join another company.
Instead, "Join Game" now just joins the game as spectators.
|
|
|
|
if needed
|
|
Every outgoing connection, either TCP or UDP, triggered
NetworkInitialize(), which triggered NetworkUDPInitialize() which
first closes all connections.
Now the problem was that "Search LAN games" found a server, added
it to the list, after which (over TCP) it queries the server. This
closes all UDP sockets (as that makes sense, I guess?), while the
UDP was still reading from it.
Solve this by simply stop initializing UDP every time we make an
outgoing TCP connection; instead only do it on start-up.
|
|
In this mode you do register to the Game Coordinator, but your
server will not show up in the public server listing. You can give
your friends the invite code of the server with which they can
join.
|
|
This removes the need to know a server IP to join it. Invite codes
are small (~7 characters) indentifiers for servers, which can be
exchanged with other players to join the servers.
|
|
Normally TCPConnecter will do a DNS resolving of the connection_string
and connect to it. But for SERVER_ADDRESS_INVITE_CODE this is different:
the Game Coordinator does the "resolving".
This means we need to allow TCPConnecter to not setup a connection
and allow it to be told when a connection has been setup by an external
(to TCPConnecter) part of the code. We do this by telling the (active)
socket for the connection.
This means the rest of the code doesn't need to know the TCPConnecter
is not doing a simple resolve+connect. The rest of the code only
cares the connection is established; not how it was established.
|
|
This allows future extensions to have different ways of referencing
a server, instead of forcing to use IP:port.
|
|
As we now use the Game Coordinator for announcements, there is no
longer a need to use the Master Server for this.
|
|
|
|
|
|
Rename the zero-parameter NetworkValidateClientName to NetworkValidateOurClientName to make it clearer it is performed on our client name, and to make it a non-overloaded function to aid with the variant being added a few commits later
|
|
them more uniform) and convert to fmt
|
|
|
|
CommandPacket()" (#9334)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
passwords
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
name
Also warn when the client or server name has not been set and provide pointers on how to set them
|
|
Additionally, only rebuild it when we added a new manual server,
as otherwise it is a noop anyway.
|
|
broadcasted (#9238)
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
|
|
|
|
But always mark it as manually, no matter if it was there or not.
|
|
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.
|
|
simplify some code
|
|
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.
|
|
password
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.
|
|
|
|
within a network game
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.
|
|
|
