TASEmulators
TAStudio autosave's default is to overwrite movies without asking
This probably isn't a new issue. Autosave is on by default and it will overwrite your tasproj without asking.
To me, it's clearly wrong to overwrite the current tasproj by default. All other applications that I'm aware of save to a secondary file that can be used as the restore point if you forget to save. It barely has to change the workflow. If the user manually saves, the secondary file can be deleted. If there's a secondary file upon load the program can prompt something like "An autosaved backup file for the current project was found. Would you like to restore it?"
Current behavior will mercilessly overwrite if you made changes you don't want to keep, accomplishing the opposite of the intended purpose.
(Personally, I have grown accustomed to just disabling Autosave upon first launch because autosave used to be a major interruption. It still can interrupt flow, and I prefer to choose when I have it saved.)
Host Env.
I had this occur just now in ed676cda391d25bdb1728ada13b7df21c0a974df
Also confirmed this behavior in 2.9.1
Current behavior will mercilessly overwrite if you made changes you don't want to keep, accomplishing the opposite of the intended purpose.
The intended purpose is mainly to prevent you from losing progress in case something bad happens, like bizhawk crashing (this used to be more common in the past), your PC crashing, power loss etc.
Saving as a (singular) backup file is probably more ideal to allow reverting unwanted changes though and gives more safety in the case that something crashes during the saving action.
The requested workflow already exists.
tastudio - config - autosave - enable autosave as backup file to make it create a new backup tasproj file in Movies\backup every time it autosaves. Backup files don't have greensone but have everything else, so it should be ideal, because not only it preserves steps of progress but the files are also tiny and saving them is very quick, unless you have like hundreds of branches with long input log.
tastudio - config - autosave - enable autosave as bk2 to make it autosave to a separate file but it will be just one bk2 alongside your tasproj. The latter will only get saved when you save explicitly through the menu.
I am aware of these options, but the requested workflow does not exist, and the current default is suboptimal.
The default should be: save to a single secondary .tasproj file and request affirmative consent from the user before overwriting their primary file (see original post).
Why exactly are the 2 existing options are not working for your situation?
The current default will overwrite your project, even if you made a mistake that you didn't want to be saved. And you may ask, "why not Ctrl-Z and manually save in that situation", but undo actions are not perfect (one example being not able to efficiently undo recording mode inputs #2143 ). The previously saved project would be a known clean state if autosave didn't save over it.
I don't think another option should be added; I think the default should be tweaked, as I explained in my original post. There's minimal downside and some upside to changing the default in this situation in my opinion.
You said "the requested workflow does not exist" which implies it's completely impossible to make tastudio do the thing you need (autosaving to a separate file), and the options I mentioned don't help with that. Did you mean to say "the requested workflow exists but it's not default"?
You mentioned two alternative workflows: autosave as bk2, which doesn't save as tasproj; autosave as backup file, which will save an arbitrary number of backup files, not merely one.
Also, I would say I'm pretty sure default autosave does save with greenzone, while as you mentioned, autosave as backup file doesn't.
Why do you need the temporary file to always save greenzone? It takes a long time and actively interferes with tasing, so people tend to not autosave at all to avoid the annoyance.
Also why exactly is autosaving as bk2 a problem? It doesn't have all the tasproj overhead, but does it needed it, given that you normally will save to the actual project at some point anyway?
If greenzone isn't important, why is it the greenzone the default?
To me, the primary backup is for a relatively robust back up, and my proposal here is a quality-of-life improvement to put BizHawk in line with modern application standards for auto-backup.
If greenzone isn't important, why is it the greenzone the default?
It's not important for backups. It has value in the main project.
Also tastudio used to allow gaps in saved greenzone to make it quick too, and then even smart gaps depending on a formula like taseditor has. Then waterbox was reworked and only written memory got into savestates, so it became unpredictable what size states will have, so zwinder was added, and it's much less flexible. It can't only save Nth state, so autosave to a file with no greenzone is a better option these days, but I stopped working on tastudio many years ago. Never thought about changing the default until you brought it up, and nobody else did so far.
To me, the primary backup is for a relatively robust back up
What makes the 2 options I suggested not robust?
my proposal here is a quality-of-life improvement to put BizHawk in line with modern application standards for auto-backup
I'm trying to get some answers on how exactly it makes the workflow much better than the 2 existing options. And we don't depend on how other applications do things, because other applications weren't designed to make TASing smooth and productive. We depend on what makes it smooth and productive, in practice.
To me, I've at least made a case that this has some merit, with some agreement from other devs, but I'll do my best to reply briefly.
To answer directly, bk2 is not robust for branches and markers. It would literally not function as a replacement for the current default, since the current default autosaves with the intention of the primary file and backup being interchangable. Similarly, autosave as backup file just creates more and more separate files over time, instead of one that's sort of binded to the current project.
Greenzone is... a tangent that's probably better discussed elsewhere.
My fundamental point is that the default settings for backup shouldn't be a footgun in the cases where the user has made a mistake and doesn't want to save. Additionally boosted by the low-cost of tweaking this (both code-wise and user workflow wise). I will consider submitting a PR in lieu of further discussion; feel free to reply with further feedback, though.