TASEmulators
Clicking the left column in TAStudio should pause when it reaches the target frame
When you seek in TAStudio, it's supposed to pause when it reaches the goal frame. For some reason, that doesn't happen when emulation is unpaused before seeking.
~~This is annoying and I'm pretty sure this is not the intended behavior, but maybe it is? I vaguely get the impression previous versions didn't do this, but I need to do more testing.~~ Nope, this is an ever-present "feature".
I would classify this behavior as "runaway seek". I've noticed this before but I wasn't able to pin it down. Maybe it only occurs under more specific circumstances than simply being unpaused? I deleted my config before testing, so hopefully it's straightforward to reproduce.
This is probably the code for pausing after seeking:
https://github.com/TASEmulators/BizHawk/blob/956b71060e5dbbc9d045cc7d20973a5e3bf24c59/src/BizHawk.Client.EmuHawk/MainForm.cs#L3005-L3013
But it doesn't pause when seeking while unpaused; maybe it did previously. In fact, IsSeeking, which is defined as PauseOnFrame.HasValue isn't true because PauseOnFrame is apparently never set when using the left cursor column to seek when emulation is unpaused, though it is set when clicking/drawing inputs. I'll test previous versions soon to find out where this regressed (if this is a regression).
Okay, I've tested several BizHawk versions (2.4, 2.2, and 2.0), and FCEUX 2.2.3, and this doesn't appear to be a regression I guess?
The reason why I don't think the current behavior is "correct" is because I interpret clicking the left column to be seeking to a specific frame. If emulation doesn't pause after reaching the frame, then it's not really seeking the frame, it's a form of resuming playback from that frame. Boiled down, the current behavior makes clicking the left column inconsistent in its purpose.
I am willing to consider the possibility that using cursor targeting to resume playback from a specific frame is desirable behavior and may be preferred by some. However, I would argue that unpausing after the frame is reached is straightforward and quick, while re-seeking the frame again requires scrolling back up to the frame to click on it again. Therefore, making it pause when the frame is reached is probably fine because unpausing after the frame has been reached is not that inconvenient.
Also, this reminds me that adelikat and I were discussing this in #bizhawk IRC a few weeks ago:
Aug 10 16:04:36 <RetroEdit_> Is seeking to a frame supposed to pause the emulator after the goal frame is reached?
Aug 10 16:04:45 <RetroEdit_> (seeking in TAStudio)
Aug 10 16:06:30 <adelikat> RetroEdit_, yes
Aug 10 16:06:48 <adelikat> there may be edge cases where it isn't supposed to? like if you were already unpaused
Aug 10 16:06:51 <RetroEdit_> Okay, there's definitely some edge case in 2.4.2 where it doesn't.
Aug 10 16:07:04 <RetroEdit_> And I'm pretty sure I saw the same thing in a recent dev build.
Aug 10 16:07:05 <adelikat> 2.4.2 is dead to me
Aug 10 16:07:32 <adelikat> well, 2.4.2 is only relevant in proof I broke something and therefore have more shit to do for 2.5
Aug 10 16:07:38 <RetroEdit_> I wonder if it's a regression or just some obscure edge case that's permeated the code base forever.
Aug 10 16:07:58 <adelikat> I've been working on release notes, the amount of changes to tastudio, are crazy, more than I even remember doing
Aug 10 16:08:29 <adelikat> well, it's tastudio, so it is either a regression, or a bug that's been here forever, or an undocumented "Feature" to be more like taseditor, or any combination thereof
Aug 10 16:09:40 <RetroEdit_> I've been TASing (really, I've been lazy) the last week, but I think after I do a bit more testing for my TAS, I'll do some BizHawk work.
Aug 10 16:09:45 <adelikat> "run away seek" is a term I have memories of being a problem over the years
If you click that column while it's paused, then it should pause once it reaches that frame. If it was unpaused, then it shouldn't pause.
I'm having a very similar thing happen to me on version 2.8, and it's happening way too often with N64 TASes. I hope this can be addressed in a future update to bizhawk.
I haven't been using BizHawk recently in an active workflow, so it's hard for me to know for sure.
In a brief test of 2.10 just now it seemed like there might have been some questionable behavior with auto-restore on when you seek to a frame and paint an input before the cursor position while the seek was in process. But I couldn't quite reproduce in latest dev and to be honest I don't put much stock in ad-hoc testing to find the weird edge cases where an issue like this happens.
Recording a video of TAStudio might be useful, so I'll try to do that next time I work on a TAS.
But in the meantime, I have no objection to this issue being closed, since it doesn't have concrete repro steps.