Change: base autosaves intervals on real time (instead of game time) #10655

TrueBrain · 2023-04-14T20:10:51Z

Motivation / Problem

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.

Description

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.

Limitations

In theory we could make autosave a free field, like all other settings, where you can fill in any time you want. Sadly, this component is not available in the Options menu (only in the Settings menu). The scope of this PR would explode, and as such, is considered out of scope for this PR. But, if you think we should have that, please, give it a go!

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

The bug fix is important enough to be backported? (label: 'backport requested')
This PR touches english.txt or translations? Check the guidelines
This PR affects the save game format? (label 'savegame upgrade')
This PR affects the GS/AI API? (label 'needs review: Script API')
- ai_changelog.hpp, gs_changelog.hpp need updating.
- The compatibility wrappers (compat_*.nut) need updating.
This PR affects the NewGRF API? (label 'needs review: NewGRF')
- newgrf_debug_data.h may need updating.
- PR must be added to API tracker

src/openttd.cpp

glx22 · 2023-04-14T23:26:01Z

As I understand it, when a command happens during pause PM_COMMAND_DURING_PAUSE flag is set to allow saving.
But shouldn't it be unset once the save is done, to not overwrite all autosaves with the same stuff if no other command happen during the pause.

TrueBrain · 2023-04-15T09:08:08Z

As I understand it, when a command happens during pause PM_COMMAND_DURING_PAUSE flag is set to allow saving. But shouldn't it be unset once the save is done, to not overwrite all autosaves with the same stuff if no other command happen during the pause.

That is a choice we can make. Do we want to reset the flag every time we save .. I dunno. For now I was under the assumption: if you once start to build, that is it, you didn't actually want to pause to take a break, but you wanted to pause because you wanted to build.
But an argument can be made to reset it after every autosave. Downside is, that is makes the timer even more autosave specific. But I don't have an issue with that.

Edit: added that on autosave the flag resets.

2TallTyler · 2023-04-23T18:51:24Z

I have no comments on the command flags, but you can probably delete TimerGameCalendar::Priority::AUTOSAVE, as it should be unused now. 🙂

TrueBrain · 2023-04-24T08:45:10Z

I have no comments on the command flags, but you can probably delete TimerGameCalendar::Priority::AUTOSAVE, as it should be unused now. 🙂

Fixed!

PeterN · 2023-04-24T10:37:38Z

Why does this needs its own Timer class specific to autosaves?

TrueBrain · 2023-04-24T10:41:41Z

Why does this needs its own Timer class specific to autosaves?

To quote the header-file:

 * Timer that represents, in real time, the time played.
 * 
 * "Time played" is defined here as the time elapsed since the game started.
 * If the game is paused, the timer stops unless a Command is executed. Than
 * the timer will continue to run.
 *

There is no other timer yet delivering this functionality. If you have better ideas, I am all ears :)

src/openttd.cpp

src/timer/timer_game_realtime.h

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.

…ripts The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works, from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. This change addresses this by adding the GSController::TriggerSave function to the GameScript API that allows game scripts to trigger a save, and with a specific file name. Because game script have access to the in-game date through GSDate.GetCurrentDate, and can sleep arbitrary amounts of ticks, it means they can approximate the pre OpenTTD 13 behaviour of saving every X amount of game time. The name of the function is not Save to avoid conflict and confusion between the existing Save function that game scripts can implement to add custom data to savegame files.

…ripts The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. This change addresses this by adding the GSController::TriggerSave function to the GameScript API that allows game scripts to trigger a save, and with a specific file name. Because game script have access to the in-game date through GSDate.GetCurrentDate, and can sleep arbitrary amounts of ticks, it means they can approximate the pre OpenTTD 13 behaviour of saving every X amount of game time. It also means that via game scripts, games can be saved immediately after game start, which wasn't possible with the previous autosave behaviour. The name of the function is not Save to avoid conflict and confusion between the existing Save function that game scripts can implement to add custom data to savegame files.

…ripts The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. This change addresses this by adding the GSController::TriggerSave function to the GameScript API that allows game scripts to trigger a save, and with a specific file name. Because game script have access to the in-game date through GSDate.GetCurrentDate, and can sleep arbitrary amounts of ticks, it means they can approximate the pre OpenTTD 14 behaviour of saving every X amount of game time. It also means that via game scripts, games can be saved immediately after game start, which wasn't possible with the previous autosave behaviour. The name of the function is not Save to avoid conflict and confusion between the existing Save function that game scripts can implement to add custom data to savegame files.

The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. A general "schedule" console command makes it possible for a console script to be scheduled for the future, and that script can contain a "save" command to save the game. That script can also then reschedule itself or another script, and thus making it possible to re-create the pre-OpenTTD 14 behaviour of saving the game every X amount of game time. (Possibly with a whole "suite" of game scripts that call each other in a chain, each of them hard coded with a different filename to allow all the savegames to be saved with different names, but that's a doable detail) The current change only allows scheduling "on-next-month", since that is my specific use case, but the syntax is hopefully friendly to this being extended in the future. There was some discussion on what this should be called at https://discord.com/channels/142724111502802944/1008473233844097104/1247278039927361546 (as well as some issues with an alternatively proposed solution using game scripts at OpenTTD#12750). Instead of "schedule", "trigger" was suggested for something to only be called once, but after writing code and output to the user, it didn't make it immediately clear that "trigger" means "once at some point in the future", and seemed too close to "exec". Also I think "schedule" can be used _both_ for both one-off or repeated events in the future (in English it's common to say to "schedule an appointment", even if it's just the one). Or code-wise: schedule my.scr on-next-month (the only current behaviour) schedule my.script every-month (possible future behaviour?) schedule my.script * 1 * * (possible future cron-like behaviour?) Possible future extensions could include some mechanism for cancelling something that has been scheduled, and I have no reason to think that mechanism would be different for something scheduled to repeat or just as a one-off, so I think also it makes sense to that we would have the one command for both.

The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. This changes adds a general "schedule" console command that makes it possible for a console script to be scheduled for the future, where that script can, for example, contain a "save" command to save the game. That script can also then reschedule itself or another script, and thus making it possible to re-create the pre-OpenTTD 14 behaviour of saving the game every X amount of game time. (Possibly with a whole "suite" of game scripts that call each other in a chain, each of them hard coded with a different filename to allow all the savegames to be saved with different names, but that's a doable detail) The current change only allows scheduling "on-next-month", since that is my specific use case, but the syntax is hopefully friendly to this being extended in the future. And by scheduling any console script, it is much more general and so hopefully useful than just for saving games. There was some discussion on what this should be called at https://discord.com/channels/142724111502802944/1008473233844097104/1247278039927361546 (as well as some issues with an alternatively proposed solution using game scripts at OpenTTD#12750). Instead of "schedule", "trigger" was suggested for something to only be called once, but after writing code and output to the user, it didn't make it immediately clear that "trigger" means "once at some point in the future", and seemed too close to "exec". Also I think "schedule" can be used _both_ for both one-off or repeated events in the future (in English it's common to say to "schedule an appointment", even if it's just the one). Or code-wise: schedule my.scr on-next-month (the only current behaviour) schedule my.script every-month (possible future behaviour?) schedule my.script * 1 * * (possible future cron-like behaviour?) Possible future extensions could include some mechanism for cancelling something that has been scheduled, and I have no reason to think that mechanism would be different for something scheduled to repeat or just as a one-off, so I think also it makes sense to that we would have the one command for both. This does only allow a single script to be scheduled - any (correct) usage of the "schedule" command will overwrite the previous, but hopefully the console messages make this clear. And there is no way to un-schedule.

The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. This changes adds a general "schedule" console command that makes it possible for a console script to be scheduled for the future, where that script can, for example, contain a "save" command to save the game. That script can also then reschedule itself or another script, and thus making it possible to re-create the pre-OpenTTD 14 behaviour of saving the game every X amount of game time. (Possibly with a whole "suite" of game scripts that call each other in a chain, each of them hard coded with a different filename to allow all the savegames to be saved with different names, but that's a doable detail) The current change only allows scheduling "on-next-month", since that is my specific use case, but the syntax is hopefully friendly to this being extended in the future. And by scheduling any console script, it is much more general and so hopefully useful than just for saving games. There was some discussion on what this should be called at https://discord.com/channels/142724111502802944/1008473233844097104/1247278039927361546 (as well as some issues with an alternatively proposed solution using game scripts at OpenTTD#12750). Instead of "schedule", "trigger" was suggested for something to only be called once, but after writing code and output to the user, it didn't make it immediately clear that "trigger" means "once at some point in the future", and seemed too close to "exec". Also I think "schedule" can be used _both_ for both one-off or repeated events in the future (in English it's common to say to "schedule an appointment", even if it's just the one). Or code-wise: schedule my.scr on-next-month (the only current behaviour) schedule my.script every-month (possible future behaviour?) schedule my.script * 1 * * (possible future cron-like behaviour?) Possible future extensions could include some mechanism for cancelling something that has been scheduled, and I have no reason to think that mechanism would be different for something scheduled to repeat or just as a one-off, so I think also it makes sense to that we would have the one command for both. The new "schedule" command: - Only allows a single script to be scheduled - any (correct) usage of the "schedule" command will overwrite the previous, but hopefully the console messages make this clear - Only allows a script to be scheduled once at the start of next month (but this could be extended if useful). - Does not offer a way to unschedule, but hopefully since the script can only be scheduled to run once in the future, and relatively close in the future (at the start of next month), this isn't shouldn't be too much of an annoying missing feature.

The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. This changes adds a general "schedule" console command that makes it possible for a console script to be scheduled for the future, where that script can, for example, contain a "save" command to save the game. That script can also then reschedule itself or another script, and thus making it possible to re-create the pre-OpenTTD 14 behaviour of saving the game every X amount of game time. (Possibly with a whole "suite" of game scripts that call each other in a chain, each of them hard coded with a different filename to allow all the savegames to be saved with different names, but that's a doable detail) The current change only allows scheduling "on-next-month", since that is my specific use case, but the syntax is hopefully friendly to this being extended in the future. And by scheduling any console script, it is much more general and so hopefully useful than just for saving games. There was some discussion on what this should be called at https://discord.com/channels/142724111502802944/1008473233844097104/1247278039927361546 (as well as some issues with an alternatively proposed solution using game scripts at OpenTTD#12750). Instead of "schedule", "trigger" was suggested for something to only be called once, but after writing code and output to the user, it didn't make it immediately clear that "trigger" means "once at some point in the future", and seemed too close to "exec". Also I think "schedule" can be used _both_ for both one-off or repeated events in the future (in English it's common to say to "schedule an appointment", even if it's just the one). Or code-wise: schedule my.scr on-next-month (the only current behaviour) schedule my.script every-month (possible future behaviour?) schedule my.script * 1 * * (possible future cron-like behaviour?) Possible future extensions could include some mechanism for cancelling something that has been scheduled, and I have no reason to think that mechanism would be different for something scheduled to repeat or just as a one-off, so I think also it makes sense to that we would have the one command for both. The new "schedule" command: - Only allows a single script to be scheduled - any (correct) usage of the "schedule" command will overwrite the previous, but hopefully the console messages make this clear - Only allows a script to be scheduled once at the start of next month (but this could be extended if useful). - Does not offer a way to unschedule, but hopefully since the script can only be scheduled to run once in the future, and relatively close in the future (at the start of next month), this shouldn't be too much of an annoying missing feature.

The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. This change adds a general "schedule" console command that makes it possible for a console script to be scheduled for the future, where that script can, for example, contain a "save" command to save the game. That script can also then reschedule itself or another script, and thus making it possible to re-create the pre-OpenTTD 14 behaviour of saving the game every X amount of game time. (Possibly with a whole "suite" of game scripts that call each other in a chain, each of them hard coded with a different filename to allow all the savegames to be saved with different names, but that's a doable detail) The current change only allows scheduling "on-next-month", since that is my specific use case, but the syntax is hopefully friendly to this being extended in the future. And by scheduling any console script, it is much more general and so hopefully useful than just for saving games. There was some discussion on what this should be called at https://discord.com/channels/142724111502802944/1008473233844097104/1247278039927361546 (as well as some issues with an alternatively proposed solution using game scripts at OpenTTD#12750). Instead of "schedule", "trigger" was suggested for something to only be called once, but after writing code and output to the user, it didn't make it immediately clear that "trigger" means "once at some point in the future", and seemed too close to "exec". Also I think "schedule" can be used _both_ for both one-off or repeated events in the future (in English it's common to say to "schedule an appointment", even if it's just the one). Or code-wise: schedule my.scr on-next-month (the only current behaviour) schedule my.script every-month (possible future behaviour?) schedule my.script * 1 * * (possible future cron-like behaviour?) Possible future extensions could include some mechanism for cancelling something that has been scheduled, and I have no reason to think that mechanism would be different for something scheduled to repeat or just as a one-off, so I think also it makes sense to that we would have the one command for both. The new "schedule" command: - Only allows a single script to be scheduled - any (correct) usage of the "schedule" command will overwrite the previous, but hopefully the console messages make this clear - Only allows a script to be scheduled once at the start of next month (but this could be extended if useful). - Does not offer a way to unschedule, but hopefully since the script can only be scheduled to run once in the future, and relatively close in the future (at the start of next month), this shouldn't be too much of an annoying missing feature.

The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. This change adds a general "schedule" console command that makes it possible for a console script to be scheduled for the future, where that script can, for example, contain a "save" command to save the game. That script can also then reschedule itself or another script, and thus making it possible to re-create the pre-OpenTTD 14 behaviour of saving the game every X amount of game time. (Possibly with a whole "suite" of game scripts that call each other in a chain, each of them hard coded with a different filename to allow all the savegames to be saved with different names, but that's a doable detail) The current change only allows scheduling "on-next-month", since that is my specific use case, but the syntax is hopefully friendly to this being extended in the future. And by scheduling any console script, it is much more general and so hopefully useful than just for saving games. There was some discussion on what this should be called at https://discord.com/channels/142724111502802944/1008473233844097104/1247278039927361546 (as well as some issues with an alternatively proposed solution using game scripts at OpenTTD#12750). Instead of "schedule", "trigger" was suggested for something to only be called once, but after writing code and output to the user, it didn't make it immediately clear that "trigger" means "once at some point in the future", and seemed too close to "exec". Also I think "schedule" can be used _both_ for one-off or repeated events in the future (in English it's common to say to "schedule an appointment", even if it's just the one). Or code-wise: schedule my.scr on-next-month (the only current behaviour) schedule my.script every-month (possible future behaviour?) schedule my.script * 1 * * (possible future cron-like behaviour?) Possible future extensions could include some mechanism for cancelling something that has been scheduled, and I have no reason to think that mechanism would be different for something scheduled to repeat or just as a one-off, so I think also it makes sense to that we would have the one command for both. The new "schedule" command: - Only allows a single script to be scheduled - any (correct) usage of the "schedule" command will overwrite the previous, but hopefully the console messages make this clear - Only allows a script to be scheduled once at the start of next month (but this could be extended if useful). - Does not offer a way to unschedule, but hopefully since the script can only be scheduled to run once in the future, and relatively close in the future (at the start of next month), this shouldn't be too much of an annoying missing feature.

The change in OpenTTD#10655, released as part of OpenTTD 14, changed how auto saving works from every X amount of game time, to every X amount of real time. This is an improvement for normal play, but there are cases where saving every X amount of game time is useful. For example when developing and comparing AIs, or using OpenTTD to conduct experiments such as via https://github.com/michalc/OpenTTDLab which extracts data from savegame files. This change adds a general "schedule" console command that makes it possible for a console script to be scheduled for the future, where that script can, for example, contain a "save" command to save the game. That script can also then reschedule itself or another script, and thus making it possible to re-create the pre-OpenTTD 14 behaviour of saving the game every X amount of game time. (Possibly with a whole "suite" of game scripts that call each other in a chain, each of them hard coded with a different filename to allow all the savegames to be saved with different names, but that's a doable detail) The current change only allows scheduling "on-next-calendar-month", since that is my specific use case, but the syntax is hopefully friendly to this being extended in the future. And by scheduling any console script, it is much more general and so hopefully useful than just for saving games. There was some discussion on what this should be called at https://discord.com/channels/142724111502802944/1008473233844097104/1247278039927361546 (as well as some issues with an alternatively proposed solution using game scripts at OpenTTD#12750). Instead of "schedule", "trigger" was suggested for something to only be called once, but after writing code and output to the user, it didn't make it immediately clear that "trigger" means "once at some point in the future", and seemed too close to "exec". Also I think "schedule" can be used _both_ for one-off or repeated events in the future (in English it's common to say to "schedule an appointment", even if it's just the one). Or code-wise: schedule my.scr on-next-calendar-month (the only current behaviour) schedule my.script every-calendar-month (possible future behaviour?) schedule my.script * 1 * * (possible future cron-like behaviour?) Possible future extensions could include some mechanism for cancelling something that has been scheduled, and I have no reason to think that mechanism would be different for something scheduled to repeat or just as a one-off, so I think also it makes sense to that we would have the one command for both. The new "schedule" command: - Only allows a single script to be scheduled - any (correct) usage of the "schedule" command will overwrite the previous, but hopefully the console messages make this clear - Only allows a script to be scheduled once at the start of next month (but this could be extended if useful). - Does not offer a way to unschedule, but hopefully since the script can only be scheduled to run once in the future, and relatively close in the future (at the start of next month), this shouldn't be too much of an annoying missing feature.

TrueBrain changed the title ~~Change: base autosaves on real time, instead of game time~~ Change: base autosaves intervals on real time (instead of game time) Apr 14, 2023

LordAro reviewed Apr 14, 2023

View reviewed changes

src/openttd.cpp Show resolved Hide resolved

TrueBrain force-pushed the autosave-on-real-time branch from ebe12b5 to 76295ae Compare April 15, 2023 11:59

2TallTyler mentioned this pull request Apr 23, 2023

Codechange: Split dates and timers into Economy and Calendar time #10700

Merged

TrueBrain force-pushed the autosave-on-real-time branch from 76295ae to ab4c697 Compare April 24, 2023 08:44

glx22 reviewed Apr 24, 2023

View reviewed changes

src/openttd.cpp Show resolved Hide resolved

TrueBrain force-pushed the autosave-on-real-time branch 2 times, most recently from 2176440 to ea0b69b Compare April 24, 2023 11:22

PeterN reviewed Apr 25, 2023

View reviewed changes

src/timer/timer_game_realtime.h Show resolved Hide resolved

TrueBrain force-pushed the autosave-on-real-time branch from ea0b69b to fbb5aab Compare April 27, 2023 14:35

PeterN approved these changes Apr 27, 2023

View reviewed changes

TrueBrain enabled auto-merge (squash) April 27, 2023 14:54

TrueBrain merged commit f5fad88 into OpenTTD:master Apr 27, 2023
19 checks passed

TrueBrain deleted the autosave-on-real-time branch April 27, 2023 18:15

2TallTyler mentioned this pull request Jul 16, 2023

Feature: Setting to automatically restart server based on hours played #11142

Merged

michalc mentioned this pull request Jun 3, 2024

Add: [Script] GSController::TriggerSave to trigger saves from game scripts #12750

Closed

michalc mentioned this pull request Jun 6, 2024

Add: [Console] schedule command to execute a script file later #12761

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Change: base autosaves intervals on real time (instead of game time) #10655

Change: base autosaves intervals on real time (instead of game time) #10655

TrueBrain commented Apr 14, 2023 •

edited

glx22 commented Apr 14, 2023

TrueBrain commented Apr 15, 2023 •

edited

2TallTyler commented Apr 23, 2023

TrueBrain commented Apr 24, 2023

PeterN commented Apr 24, 2023

TrueBrain commented Apr 24, 2023

Change: base autosaves intervals on real time (instead of game time) #10655

Change: base autosaves intervals on real time (instead of game time) #10655

Conversation

TrueBrain commented Apr 14, 2023 • edited

Motivation / Problem

Description

Limitations

Checklist for review

glx22 commented Apr 14, 2023

TrueBrain commented Apr 15, 2023 • edited

2TallTyler commented Apr 23, 2023

TrueBrain commented Apr 24, 2023

PeterN commented Apr 24, 2023

TrueBrain commented Apr 24, 2023

TrueBrain commented Apr 14, 2023 •

edited

TrueBrain commented Apr 15, 2023 •

edited