i recommend disabling auto-save and getting in the habit of saving after any changes that you don't want to repeat.
in addition, you should be saving with new names each time so if a save is corrupted, you can return to the previous save.
eg, for a project named project1, i change the publish settings to publish project1 production files and save the fla as project1_000, project1_001, project1_002 etc
i wrote a jsfl script that automates the save names and assigned a keyboard shortcut to enhance productivity.
here's adobe's wishform if you want to suggest something else, Feature Request/Bug Report Form
You do have different choices of how you work. It used to be that Flash Pro would auto recovery save every FLA that was open and had not had a save since the last changes. If you were working on several large files that could end up locking your machine up for a minute.
A few versions ago there was a change where the recovery file was not updated if the FLA it related to had not changed since the previous recovery save. With that improvement you only risk a slight delay while the FLA you're working on gets saved.
If that still is too much of a disruption you could set the recovery save time to be longer, I have mine set to 15 minutes.
As for manually saving with a new file name, that can lead to versioning issues, my animator colleagues work that way and I will do an update, and find out that there was a version 23 I should have used, and I only knew about version 22. Also you need to change the publishing settings, or at least check that it's publishing with the right name. If you don't you'll find that app descriptor files are regenerated, or maybe HTML is no longer pointing to the right file name.
But, the concept of having a different named file as a fallback is a good idea. I achieve that in a different way. If I am starting to work on something which is a departure from the current stable FLA, I will select the FLA and duplicate it, giving it a name that explains what was significantly different. For example, "mygame_mouse_version.fla", if say I'm now attempting to use touch events. If that doesn't work out, I can scrap the idea and rename my backup file, and in this example, carry on using mouse events.
So, the general case with me is that the file with the right name, mygame.fla, is always the current file, and has its publishing settings unaltered, and the files with a wrong name, mygame_10_10_16.fla for example, are purely for backup reasons.
BTW, I also use Time Machine in macOS, so quite often I won't do the backup copy. I have a copy from each hour for the previous day, and each day for the previous month. That's a good amount of peace of mind.
1 person found this helpful
Yeah, I don't like having multiple FLA files for every minor update; it can overcomplicate things.
At my old job, we used SVN, and at my current job, GitHub for version control. I highly prefer working this way, so I only have one FLA to manage and it's super easy to revert to a previous version if needed. It also makes sharing files and tracking changes with team members really easy.
Oh! The JSFL script sounds like a great idea!
Though, I'm thinking if someone could design a custom panel with ActionScript that would initiate it by a timer, that could solve the problem...
However, unless it can be done in the background, I think the action of saving will still lock out the interface.
1 person found this helpful
A very easy fix to the issue of previewing being interrupted by a recovery save would be to do a regular Save before any important tests. The recovery save only happens if there have been changes.
Aha! I didn't realize that!
Though, I still cannot understand why auto-save doesn't happen in the background.