[joe_star]

Yes, definitely support this

A) Optional
B) Time configurable
C) Store max 10 of the last autosave states, before erasing the oldest one once a new autosave is made (i.e keeping a rolling buffer of 10!autosaves , that way the HDD is not overloaded with files over time)

[roeter]

James Ross, on 04 January 2022 - 02:51 PM, said:

I just took a save immediately after loading a basic activity in Open Rails 1.4 and, although the save file itself is only ~50 KB, the full-sized screenshot is ~4 MB from my 2560x1440 monitor. Most of my existing saves are similar sizes, with the screenshot usually being the biggest.

For me, after playing 100 hours of Open Rails with 15-minute auto-save, I think I'll have ~1.6 GB of auto-save files (100 hours * 4 auto-saves per hour * 4 MB per save = 1600 MB).

I see two things from this:

• Do we need a full-size screenshot? I think it's only ever displayed in the resume dialog, so we should probably resize it to some fixed size.
  
• We should probably flag auto-saves as such, either in file name or file data (or both), in case we ever want to clean them up differently to manual saves in future.

The system I use to keep things in hand (a bit), is deleting all files relating to a specific timetable train once I have completed that particular run. Such a run can never be much longer than 24 hours as multi-day timetables or activities do not (yet) exist.
Admittedly, though, due to the work I did before retirement I do have a slightly different view of what I consider to be 'large amounts of data'.
Anything less than GByte was peanuts. Generating about 50 to 100 GByte in an afternoon's work was normal. Near the end of my career, a good days testing would result in a good number of TerraBytes of data - and that was unprocessed data (binary recordings), the size of which would 'explode' when it was processed for input to calculations etc. So it could well be that what I consider to be nothing more than just a handfull of data, is rather a fearfull amount of data to others.

Anyway, flagging files as autosaves, different from manual saves, should not be much of a problem. Tooling to somehow remove this, either manually (i.e. through explicit menu functions, not manually in the sense of removing files using windows explorer as that is of course always possible) or automatically at some point or other, will have to be considered and I will give this some thought.

Regards,
Rob Roeterdink

[ebnertra000]

I also am in favor of an aurosave option, with player-determined intervals. I do think that these should overwrite after a certain point, either hard-coded in or player-controlled, not just to keep filesize in check, but also to prevent cluttering of the save menu

[jonas]

The most modest version for me would be at least a self-overwriting auto-save every 5 minutes, i.e. not even several auto-saves and also no save interval setting by the user. For me, the most important thing would be the possibility of not having to start again from the activity beginning in the event of a programme crash or an undesired end of an activity due to incorrect operation.

A function I have always sorely missed since the earliest days of MSTS! Why Kuju went out without this in the first place back then, I never understood.

So Rob, in reference to your first post here, all I can say is: There is an interest in introducing this as a standard feature in OR from my side! Anything is better than having no auto-save at all.
Of course good with the proposed and already described options here in the thread of choosing the save interval times or several possible auto-saves. But the concrete options are less important to me, the main thing is that there would be an auto-save function at all in the future. So thanks for your suggestion.

Greetings
Jonas

[Weter]

Quote

'flooding' is a big word

I meant quantity of files primary, not their size. How to deal with that heap after two month? Who would remember and understand then, what is what?