wolph42 wrote:Full Bleed wrote:When an AutoSave is written have it record the Date Modified. When it attempts to create another AutoSave have it looks at the Date Modified. If it matches the date it recorded last time it can AutoSave. Otherwise it skips the AutoSave knowing that something else created the save. This can be noted int he Status bar.
The first AutoSave won't have a Date Modified field to look at. But if there is already an AutoSave it knows it didn't create it. So it skips the AutoSave.
I think that there are some pitfall in that method
Not sure what they are.
but apart from that: it would mean only one instance of MT will be 'autosaved' the other not, again not the most preferable outcome.
Yes, it means that there would be only 1 autosave (like we have now). But that's what it seemed like we were getting because all methods to create multiple autosaves was taken off the table.
I think the date modified method should work to create 1 autosave tagged to the first instance of MT running.
*If* we used campaign file names in the autosave file, the main issues would be the corner cases of:
A) Changing the file name during play or development.
Solution: A static backup/recovery/autosave name per campaign file that doesn't change with a changing file name.
B) Running two instances of the same file name.
Solution: I'd suggest a user create a separate data directory to manage their separate instances of the SAME file. Using the Date-Modified method, the user would be notified (via the Status Bar) that their second instance wasn't autosaving and could take steps to create a second data directory to rectify the issue.