This function returns an iterator, either to the selected item or the
container's end.
This makes handling the result more robust as indices are not used.
This to prevent compilation issues between runs with and without precompiled
headers. Also remove the headers from the rest of the code base as they are
not needed there anymore, although they do relatively little harm.
Otherwise this chain of events can happen:
- You already have a (partial) file downloaded
- You start the download, and HTTP fails
- This resets the download progress to the current size of the file
- The TCP download starts at a very large value (UINT32_MAX - filesize)
It now resets to 0% done when any negative value is being given.
As added bonus, we no longer have to query how much was already
downloaded.
With a thread, we can just run curl_easy_perform() and let CURL
and threads handle the blocking part.
With async solution there are too many things to keep track of,
and it makes "when to update the GUI" tricky. By using a thread
that all gets a lot simpler, as the game-thread and download-thread
run side-by-side.
This is similar to how the WinHttp backend already works.
This requires the use of WinHTTP (for Windows) or libcurl (for all
others except Emscripten). Emscripten does not support http(s)
calls currently.
On Linux it requires ca-certificates to be installed, so the HTTPS
certificate can be validated. It is really likely this is installed
on any modern machine, as most connections these days are HTTPS.
(On MacOS and Windows the certificate store is filled by default)
Reminder: in case the http(s):// connection cannot be established,
OpenTTD falls back to a custom TCP-based connection to fetch the
content from the content-service. Emscripten will always do this.
Though where similar calls are checked for nullptr as in those instances of
the use of that function it can actually return nullptr. In other words, write
down the assumption that the function never returns nullptr in an assert.
Most are very unlikely to ever be triggered in our codebase; two
stand out: linkgraph and money cheat. Those, potentially, could
wrap earlier than expected.
Progress bars are drawn differently depending on when it was added, with
different layouts and sizes.
This change adds a standard padding size to use, and makes all progress
bars visually similar, with scaled padding.
Hover highlight was visible even if the mouse pointer was in a different
window, and the window refreshed itself every frame if the mouse pointer
was not over its matrix widget.
Resolved by using OnMouseOver() instead of OnMouseLoop(), and only
redrawing if the hover position has changed.
docs/admin_network.md promised that information in an admin packet
is never removed. It does allow the possibility of using a new packet type
for changed data in combination with a bump of the admin port version.
As the recent command handling changes modified the contents of
ADMIN_PACKET_SERVER_CMD_LOGGING, do exactly that.
If the arguments of the callback proc don't match with the command parameters,
we can't do the proper command execution anyway. As such, don't even generate
an unpack function in the first place, saving a bit of unnecessary code bloat.
Validate on receive that the cmd/callback combination is supported, rejecting
clients that try to send invalid values.
The data will be transmitted as the length followed by the serialized data. This allows the command
data to be different for every command type in the future.
A race condition happens when an IPv6 connection takes more than
250ms to report an error, but does return before the IPv4 connection
is established.
In result, an invalid socket might be used for that connection.
This gives user visual feedback that the refresh is still pending, and
prevents people from clicking again and again thinking nothing is
happening. This is especially true for connections that fall back to
TURN, as that takes a few seconds to kick in.
Additionally, prevent clicking on the button again while a refresh
is pending. This is only delaying a successful result.
The function clears all stun-handlers. This causes all of those
objects to be destroyed.
A handler can have a pending connecter, which was only killed in
case CloseConnection() was called. This is never the case when
the object is destroyed. In result, the connecter could finish
and cause a use-after-free by calling into the (now deleted)
handler.
When you are query several servers at once, it is rather unclear
for which server you got a popup. Instead, show any errors on the
server itself.
This is only true for the query-part. Joining a server still gives
an error popup to tell you about any issue.
You can now still query a full server, as long as the maximum
amount of allowed connections isn't reached. This means that as
long as there are not 255 clients connected to a server, you can
always connect to query.