TASEmulators
BizHawk no longer saves bk2 movies upon creation
I noticed this with the workflow File > Record Movie followed by Tools > TAStudio. I think it'd be preferable if they were initially saved at least once when they were created.
TAStudio does prompt:
Convert movie TAStudio will create a new project file from the current movie. The current movie has unsaved changes. Would you like to save before closing it?
but I would argue creation is not a change per se but just the base state upon which changes can be done.
This was not the behavior in 2.9.1, and this seems likely to be a recent change.
Host env.
- BizHawk dev build at ed676cda391d25bdb1728ada13b7df21c0a974df; Win11
I disagree. Unless the user saves manually or has autosave enabled, there should be no disk I/O.
Why? If we're talking about minimizing disk usage, we already save SaveRAM without asking and obviously save config. To be fair, there is some contention about SaveRAM is done: see https://github.com/TASEmulators/BizHawk/issues/2175#issuecomment-650659312 part 2 .
There are very few cases where I can imagine it's desirable to create a bk2 but not to save it. It might be convenient for certain kinds of testing, or if you're trying to use it for a pure minimal file creation launch into TAStudio. But overall, I'd mostly imagine if you created a movie you intended it to be saved, and if it wasn't intended it can be deleted.
This seems inconsistent with other parts of the current design, where for instance Stop Movie in reality functions as "stop and save movie" (With the separate option Stop Movie without Saving). Closing EmuHawk will similarly implicitly save the movie.
OOTB behaviour != behaviour with no user input. If the default is autosave (which I'm in favour of) then there should be an option to disable it, and only explicit saves should hit the disk when it's disabled.
To put it another way: Take any app which is used to edit documents, images, etc. and try Ctrl+N. I don't think any will write the blank/template file immediately. (Some will write backup copies for crash recovery, but that's analogous to our autosave.)
I don't think Record Movie... is analogous to Ctrl+N because for Record Movie... the user provides a filename and potentially a directory.
It's possible this was a conscious decision, but I'm not sure. What would be the use case for having a blank, empty bk2 movie file?
The main thing for me is that Record movie... UI implies to me that a file a will be created. The one benefit I can see is that the files will reflect when the movie was initially created (creation date timestamp). Probably some amount of status quo bias on my part, though.
It could potentially save you from having to keep writing out the metadata, but there's not much of that, and IMO improving how the user is made aware of unsaved changes to the movie would be better. A '*' in the window title is the usual way.
Just to clarify some things:
I noticed this with the workflow File > Record Movie followed by Tools > TAStudio. I think it'd be preferable if they were initially saved at least once when they were created.
This flow seems unusual to me, is this so you get a movie with specific filename in TAStudio? TAStudio does have a bit of a legacy problem with the default.tasproj name, perhaps something could be improved here to make initial name picking easier.
I would argue creation is not a change per se but just the base state upon which changes can be done.
The Changes flag basically just signals whether or not the movie differs from the state on disk, or including some special cases it signals whether or not the movie needs to be saved. So the dialog correctly prompts you because the currently loaded movie file has not yet been saved.
Two main benefits to this flow: 1) Choosing the basic metadata including file path and author when the movie is created (and occasionally "starts from" status -- I'm actually not sure if TAStudio can be used to create a "starts from" movie from just an EmuHawk window). 2) When the movie does get imported into TAStudio, it will get saved to File > Movie > Recent instead of only getting saved to TAStudio's recent list.
(Minor benefit that an extraneous default.tasproj is not created.)
the workflow File > Record Movie followed by Tools > TAStudio
This flow seems unusual to me
This is basically how I use TAStudio in the vast majority of cases. Basically, I want to test something, get the game into the state I need and then record a movie that is 1 frame long starting from the state I want. That movie I then open in TAStudio and start working. To my knowledge that is the only way to start a project that isn't starting from console boot.
Since OP seems to have a similar workflow, wouldn't this issue be resolved by allowing the user to start a TAStudio project from the current game state?
Allowing start from save[ram|state] in TAStudio without having to jump through hoops is a long-standing TODO. Perhaps the way to do this would be to neither reload the rom nor start a movie upon opening TAStudio, but only do that once some button is pressed (which could open some kind of dialog like what record movie does).
It could use the existing heuristics for "has the user actually done anything in the game" https://github.com/TASEmulators/BizHawk/blob/5cc4c1f92450f67a895d0b73cd956e7d27310813/src/BizHawk.Client.EmuHawk/MainForm.Events.cs#L1122-L1128 and offer new from savestate etc. in that dialog.
I think if we're talking about the TAStudio workflow, a Create as tasproj checkbox in Record movie... could work well.
This wasn't in the 2.10 milestone, but it's marked as a regression from the last release, so I've made that small UI improvement ^ and will leave the rest of this for next release.
I think if we're talking about the TAStudio workflow, a
Create as tasprojcheckbox inRecord movie...could work well.
You can now create tasproj's directly by adding .tasproj to the file name, however is that actually useful?
Another note: it adds the movie to the Recent list upon creation, but you can't copy the movie's path from that dialog until you save. This reaffirms my impression that saving upon creation is the most sensible behavior
Though, admittedly this is a rather minor papercut compared to some of BizHawk's other saving misbehavior.