Practically the length of the handlers not being equal to the number of
features is the problem as it means something was forgotten when adding
a new feature, so static assert to that and let the existing check on
the feature number take care of invalid data from the NewGRFs.
Functions like localtime, gmtime and asctime are not thread safe as they (might) reuse the same buffer. So use the safer _s/_r variant for localtime and gmtime, and use strftime in favour of asctime.
This ensures that default vehicles can transport any NewGRF defined cargos, albeit with weird graphics and vehicle names.
This also changes the refittability of default vehicles with default industries.
Default vehicles now behave as if they had a cargo translation table. This fixes default vehicles carrying seemingly random cargos, if NewGRF industry sets are present.
This behavior is disabled, when a NewGRF touches any of the cargo-type or refitting properties. In that case it's up to the NewGRF to define its own cargo translation table.
* 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.
Susz is masculine, not neuter, so it should result in "Susz Mazowiecki",
"Susz Morski", and not "Susz Mazowieckie" or "Susz Morskie". However,
because order of the names whould not be changed, it was replaced with
Leszno, which is neuter.
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.
This as during construction the sub class has not been initialized yet, and
during destruction the sub class has already been destroyed, so the overriding
virtual function would be accessing uninitialized data.
This also changes ScriptEventVehicleAutoReplaced when replacing wagons:
The event is now only spawned, if the head engine changes, so only if the VehicleID of the consist changes.
Previously replacing wagons spawned an event with OldVehicleID==NewVehicleID.
This means that random tree generation density is higher on small maps and lower on large maps. This difference is enough to make the Lumber Mill impractical to use on large maps.
This change skips ticks on maps smaller than 256x256 and increases iterations or shortens the interval on maps larger than 256x256.
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
The function fluid_player_join in the library is broken beyond compare for the
usecases it was used for (see their #872). It does not wait until it is safe
to delete the player, so it is up to the end user to ensure that.
For OpenTTD we acquire a lock before fluid_synth_write_s16 and we acquire the
same lock in the stop function. So, only one of the functions can be doing its
thing, meaning we do not need to wait for the player to be stopped as it
cannot be doing anything as we prevent that by the lock.
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
In FluidSynth 2.2.0 an extra state was added to denote stopping. To transition
from this state to a stopped state the rendering needs to be running. Since
04ce1f07 locking was added that skipped the rendering when something else held
a lock, so the state would never get to stopped and join would never return.
This avoids the need to custom memory management and additional members.
This also resolves use-after-free if modifying copied layouts, so presumably nobody has ever done that.
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.
If a viewport sign straddles the top of a viewport, a crash will occur if the viewport height is zero. This is resolved by simply not attempting to draw the viewport in this situation, consistent with other widgets.
Previously noted by a comment, this does not need to be guarded against as non-powers of 2 will not cause issues beyond the choice of results being reduced.
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.
Scaling is not expensive, but it does not change either, and this avoids the need for a virtual method call. This cascades back to all GetCharacterHeight(FS_xxx) and FONT_HEIGHT_xxx calls.
Replaces constant pixel values with values scaled based on font size.
This allows the industry chain to maintain a consistent look across
different sizes. Previously all except cargo line height were fixed.
YAPF was constantly measuring its performance, but only at
certain debug-levels this information was shown.
Now after years, I sincerely wonder if anyone still knows about this
feature and who still use it. Especially with the new framerate window,
this detailed performance is not as meaningful anymore as it once
was.
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.
In case a character was encoded in multiple bytes, but required fewer bytes to be encoded, the first byte would be copied to the output leaving an invalid Utf8 encoded string. Later uses of the validated string would use the same decode logic, which would yield a question mark and just read a single byte, so nothing dangerous happened.
Furthermore, because the next byte would not be a first byte of an encoded Utf8 character, the last few valid characters could be removed by the validation as well.
* Fix: 'Cache' top and bottom lines of textfile viewer to avoid overdraw.
The text file viewer calculated the number of lines required to set the scrollbar, but did not retain this information, so this was recalculated on every draw operation. This includes overdrawing text outside the bounds of the current scroll position.
With this change the top and bottom lines for each line of text are remembered, and reflowing is avoided where possible. Text outside the current scroll bounds is not drawn.
Additionally the scroll interval is now based on text lines instead of pixel lines, which increases the text capacity depending on the font size.
* Fix: Limit text viewer to showing 64k lines.
Text files with more than 64k wrapped lines would exceed the scrollbar capacity and cause an assert. This is harder to reach now that the scrollbar counts lines instead of pixels.
This happens if the bounding dimensions are changed so that each item is the same size, as happens on the railtype/roadtype dropdown lists, as the vertical offset was calculated before this dimension is changed.
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.
spanish (mexican): 40 changes by absay
english (us): 1 change by 2TallTyler
korean: 3 changes by telk5093
german: 1 change by danidoedel
finnish: 1 change by hpiirai
catalan: 1 change by J0anJosep
portuguese: 45 changes by azulcosta
portuguese (brazilian): 44 changes by Vimerum
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.
They are likely not working as expected on Windows, so prevent their usage.
Winsock does not set errno and strerror does not return anything useful for Winsock error numbers.
english (us): 39 changes by 2TallTyler
korean: 44 changes by telk5093
german: 43 changes by danidoedel
russian: 7 changes by Ln-Wolf
finnish: 39 changes by hpiirai
