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.
OTTD_COORDINATOR_CS for the game coordinator defaults to coordinator.openttd.org:3976
OTTD_CONTENT_SERVER_CS for the content server defaults to content.openttd.org:3978
OTTD_CONTENT_MIRROR_CS for the content mirror server defaults to binaries.openttd.org:80
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
* Codechange: [Network] split CloseSocket and CloseConnection more clearly
- CloseSocket now closes the actual OS socket.
- CloseConnection frees up the resources to just before CloseSocket.
- dtors call CloseSocket / CloseConnection where needed.
In the destructors of many of the network related classes Close() is called, just like the
top class in that hierarchy. However, due to virtual functions getting resolved statically
in the destructor it would always call the empty Close() of the top class.
Document the other cases where a virtual call is resolved statically.
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.
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 idea is that if you query an older server that does not support
this packet yet, the client receives an error. The assumption was
that on every "illegal packet" the connection would be closed. This
turns out to be false.
Now CLIENT_GAME_INFO aligns with the old PACKET_CLIENT_NEWGRFS_CHECKED,
which does a pre-check (which fails), and an error is sent back
and the connection is closed.
This is not a nice solution, but it is the best we got.
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.
Currently we use default OS timeout for TCP connections, which
is around 30s. 99% of the users will never notice this, but there
are a few cases where this is an issue:
- If you have a broken IPv6 connection, using Content Service is
first tried over IPv6. Only after 30s it times out and tries
IPv4. Nobody is waiting for that 30s.
- Upcoming STUN support has several methods of establishing a
connection between client and server. This requires feedback
from connect() to know if any method worked (they have to be
tried one by one). With 30s, this would take a very long time.
What is good to mention, is that there is no good value here. Any
value will have edge-cases where the experience is suboptimal. But
with 3s we support most of the stable connections, and if it fails,
the user can just retry. On the other side of the spectrum, with 30s,
it means the user has no possibility to use the service. So worst case
we annoy a few users with them having the retry vs annoying a few
users which have no means of resolving the situation.
Especially if there are many players online, trying to chat with
the right one can be a visual challenge. This can be solved by
highlighting the row you are on. This visual cue is often enough
for humans to find the right row.
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 so names from other clients are known valid in the client as well, instead allowing some compromised/bad server to potentially crash clients upon certain expectations.
Strictly seen the comment is true, as it says 'e.g.', but it is
misleading. The server name is just that: the name of the server
as configured. No need to mention advertising.
When ever you saw this debug lines (which you never should), they
showed an empty address. It is also not very useful to have, as it
always points to a known server anyway.
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.
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 server information panel was scaled by GUI scale, which could result in a panel that is longer than the server list. This height difference is then maintained when the window is resized to fill the screen.
Instead, specify the minimum size by number of text lines and (summed total) padding.
Use status >= STATUS_AUTHORIZED as the state criteria for all cases
where updates about other clients are sent.
This avoids the case where a client is informed that another client
has joined but not informed when it later quits, resulting in
stale entries in the client list window.
Basically, modal windows had their own thread-locking for what
drawing was possible. This is a bit nonsense now we have a
game-thread. And it makes much more sense to do things like
NewGRFScan and GenerateWorld in the game-thread, and not in a
thread next to the game-thread.
This commit changes that: it removes the threads for NewGRFScan
and GenerateWorld, and just runs the code in the game-thread.
On regular intervals it allows the draw-thread to do a tick,
which gives a much smoother look and feel.
It does slow down NewGRFScan and GenerateWorld ever so slightly
as it spends more time on drawing. But the slowdown is not
measureable on my machines (with 700+ NewGRFs / 4kx4k map and
a Debug build).
Running without a game-thread means NewGRFScan and GenerateWorld
are now blocking.
In other words, it should only (!) return true if A comes for B.
This promise was broken for the situation where two values are
identical. It would return true in these cases too. This is of
course not possible: if two values are identical, neither come
before the other. As such, the sorter was not imposing strict
weak ordering relations.
libstdc++ handled this scenario just fine, but libc++ crashes
badly on this, as it allowed comparing of [begin, end] instead
of [begin, end).
libc++ considered this not a bug (and by specs, they are correct;
just this way of crashing is of course a bit harsh):
https://bugs.llvm.org/show_bug.cgi?id=47903
Strictly seen, there are "N" people -waiting- in front of you
in the queue, but it is nicer to show "N + 1" for the person that
is currently downloading the map. Avoids it showing:
"0 clients in front of you". That just feels a bit off.
SendError() notifies all clients of the disconnect. This calls
CloseConnection() at the end, which also notified the clients
of the disconnect. Really no need to do it twice.
The status NETWORK_RECV_STATUS_SERVER_ERROR is only set by
SendError(), so in case that is the status, don't let
ClientConnection() send another notification.
If a server is compatible, it falls back to sorting by clients.
This used to be in reverse, so full servers are on top. With
the codechange commit, this was removed by accident, and as
such empty servers were on top. This is silly.
Rubidium
Patric Stout
Stephan
TELK
SamuXarick
glx22
milek7
William Davis
rubidium42
Peter Nelson
Loïc Guilloux
Milek7
Charles Pigott
Niels Martin Hansen
Jonathan G Rennison
dP
frosch