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.
This is using a non-intrusive type-traits like templated system, which
allows compile-time validation that the command table and the command
enum match up.
This is a much better location for this button, as you send
money from one company to another company, not from player
to player.
This is based on work done by JGRPP in:
f820543391
and surrounding commits, which took the work from estys:
https://www.tt-forums.net/viewtopic.php?p=1183311#p1183311
We did modify it to fix several bugs and clean up the code while
here anyway.
The callback was removed, as it meant a modified client could
prevent anyone from seeing money was transfered. The message
is now generated in the command itself, making that impossible.
Check if the job is still running two date fract ticks before it is due
to join, and if so pause the game until its done.
When loading a game, check if the game would block immediately due to
a job which is scheduled to be joined within two date fract ticks,
and if so pause the game until its done.
This avoids the main thread being blocked on a thread join, which appears
to the user as if the game is unresponsive, as the UI does not repaint
and cannot be interacted with.
Show if pause is due to link graph job in status bar, update network
messages.
This does not apply for network clients.
This switch has been a pain for years. Often disabling broke
compilation, as no developer compiles OpenTTD without, neither do
any of our official binaries.
Additionaly, it has grown so hugely in our codebase, that it
clearly shows that the current solution was a poor one. 350+
instances of "#ifdef ENABLE_NETWORK" were in the code, of which
only ~30 in the networking code itself. The rest were all around
the code to do the right thing, from GUI to NewGRF.
A more proper solution would be to stub all the functions, and
make sure the rest of the code can simply assume network is
available. This was also partially done, and most variables were
correct if networking was disabled. Despite that, often the #ifdefs
were still used.
With the recent removal of DOS, there is also no platform anymore
which we support where networking isn't working out-of-the-box.
All in all, it is time to remove the ENABLE_NETWORK switch. No
replacement is planned, but if you feel we really need this option,
we welcome any Pull Request which implements this in a way that
doesn't crawl through the code like this diff shows we used to.
Rubidium