Age | Commit message (Collapse) | Author |
|
simplify some code
|
|
|
|
dutch: 2 changes by Afoklala
|
|
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.
|
|
|
|
|
|
|
|
portuguese: 1 change by azulcosta
|
|
|
|
|
|
|
|
|
|
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.
|
|
during deserialisation
|
|
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.
|
|
side and serialize that for the clients
|
|
english (us): 1 change by 2TallTyler
russian: 1 change by Ln-Wolf
finnish: 4 changes by hpiirai
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
norwegian (bokmal): 1 change by Anolitt
spanish (mexican): 1 change by absay
korean: 1 change by telk5093
russian: 48 changes by Ln-Wolf
catalan: 1 change by J0anJosep
portuguese: 1 change by azulcosta
portuguese (brazilian): 1 change by Vimerum
|
|
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.
|
|
Query window was not marked dirty after being moved on init. It was then marked dirty once the white border flash completed.
|
|
|
|
|
|
norwegian (bokmal): 24 changes by Anolitt
russian: 8 changes by Ln-Wolf
dutch: 46 changes by Afoklala
spanish: 43 changes by MontyMontana
french: 44 changes by arikover
|
|
erratic fast forward behaviour (#9140)
|
|
values only.
|
|
|
|
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.
|
|
access the video buffer from the game thread.
|
|
command queue.
|
|
squared-euclidian distance to 16 bit, when they should not.
|
|
used the north tile.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|