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.
