It does not work for dedicated servers because upon starting the process to
resolve the address to redirect to gets killed. Also with all the async going
on in the network code, the debug redirection will start very late in the
process.
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