SetStringParameters() was called during widget tree init in the constructor.
Calls within a constructor cannot call the derived classes methods. This would result in invalid data being passed to the string system, which could then crash.
When clicked, the button is still highlighted to show that it is active.
The bevel is controlled with widget_data by RWV_SHOW_BEVEL or RWV_HIDE_BEVEL values.
This simplifies processing nwidget parts as, unlike the remaining length, the pointer to the end of the list never changes. This is the same principle as we use(d) for tracking end instead of length for C-style strings.
And this removes 160~ instances of the lengthof() macro.
On first start-up, the game will ask if you want to participate
in our automated survey. You have to opt-in, and can easily opt-out
(via the Options) at any time.
When opt-in, whenever you exit a game, a JSON blob will be send
to the survey server hosted by OpenTTD. This JSON blob contains
information that gives a global picture of the game just played:
- What settings were used
- How many humans vs AIs
- How long the game has been played
- Basic information about the OS / CPU
All this information is kept very generic, so there is no
chance we send private information to our survey server.
Nothing in the JSON blob could identify you as a person; it
mostly tells about the game played. At any time you can see
what the JSON blob includes, by pressing the "Preview Survey
Results" button in-game.
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.
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.
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.
* 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.
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.
Previously the internal content list was invalidated and sorted for
every new item added. Now the sorting is delayed until the GUI is
drawn, which means we only sort once per GUI tick.
Since the amount of incoming items per GUI tick is not controlled by
the GUI but rather by network speed, we were previously doing a lot
of duplicate work per tick, causing the mouse cursor to lag while
the list was initialized.
frosch