This variable is saved as a setting which requires the variable type to be known, but std::chrono::minutes may vary depending on system type.
Instead, keep as uint32_t and convert to std::chrono::minutes only when setting the timer.
When changing a Game Option and pressing Exit Game, the changes
were not actually stored. This because the post-mainloop code
was never executed for Emscripten.
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.
There are two fundamental issues with autosave:
- When fast-forwarding, it saves way too often
- When paused, it never saves
Both makes no sense. Autosaves are meant to prevent you from
accidentally losing your work. The emphasis on "your" work.
To solve both issues, the autosave now works on real time. You
can select every 10 / 30 / 60 / 120 minutes, which are similar to
what the setting was in game-months.
When you pause, autosaving will stop. Unless you make any change
to the game; then it will continue to make autosaves, even so
the game is paused. Unpausing / pausing resets this mechanism.
The per-AI "start_date" is a lot of custom code, and was rarely
used in the way it was meant.
While at it, also ported this part over to the new timer system.
IntervalTimer and TimeoutTimer use RAII, and can be used to replace
all the time-based timeouts, lag-detection, "execute every N" we
have.
As it uses RAII, you can safely use it as static variable, class
member, temporary variable, etc. As soon as it goes out-of-scope,
it will be safely removed.
This allows for much easier to read code when it comes to intervals.
* If loading fails, it usually returns SL_REINIT which doesn't trigger check
* If savegame has NewGRFs, it complains NewGRFs are not allowed in intro game
This is extreme useful for automated testing. Without this, OpenTTD
will always look in your personal-dir (like ~/.local/share/openttd
or %USER%\Documents\OpenTTD). For most users this is exactly what
we want, that there is a shared place for all their files.
However, for automated testing this is rather annoying, as your
local development files influence the automated test. As such,
'-X' counters this, and only gives the local folders. This is
especially useful in combination with '-x' and '-c'.
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
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.
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.
The idea back in the days was nice, but it never resulted in
anything useful. Most servers either read "(loaded game)" or
"Random Map", neither being useful. It was meant for heightmaps,
so you could find a server that was using a specific one .. but
there are many things wrong with that idea. Mostly, servers tend
to save and load savegames from time to time, after which the
original heightmap used was lost.
All in all, removing map_name all together is just better.
An invalid starting year causes all sorts of weird behaviour and crashes in map generation.
Now just set the appropriate setting via IConsoleSetSetting so the validation
and, if needed, clamping is performed on the starting year value.
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.
Otherwise both the draw-thread and game-thread can do it both
at the same time, which gives rather unwanted side-effects.
Calling it from the draw-thread alone is sufficient, as we just
want to create some unpredictable randomness for the player. The
draw-thread is a lot more active (normally) than the game-thread,
so it is the best place of the two to do this.
Additionally, InteractiveRandom() mostly has to do with visuals
that are client-side-only, so more related to drawing than to
game.
During fast-forward, the game was drawing as fast as it could. This
means that the fast-forward was limited also by how fast we could
draw, something that people in general don't expect.
To give an extreme case, if you are fully zoomed out on a busy
map, fast-forward would be mostly limited because of the time it
takes to draw the screen.
By decoupling the draw-tick and game-tick, we can keep the pace
of the draw-tick the same while speeding up the game-tick. To use
the extreme case as example again, if you are fully zoomed out
now, the screen only redraws 33.33 times per second, fast-forwarding
or not. This means fast-forward is much more likely to go at the
same speed, no matter what you are looking at.
The current "restart" command is now called "reload", as that is
what it does.
The old "restart" command is now called "restart", as that is what
it did.
As this has not been in any official release yet, this shouldn't
harm any kitten.
Peter Nelson
rubidium42
Tyler Trahan
frosch
glx22
Patric Stout
Henry Wilson
Loïc Guilloux
Jonathan G Rennison
Charles Pigott
krysclarke
Niels Martin Hansen
Michael Lutz
Stephan
William Davis
rubidium42