Skip to content

Conversation

@SuuperW
Copy link
Contributor

@SuuperW SuuperW commented Dec 18, 2025

title

Also makes TAStudio save custom auto fire patterns in movies' client settings. (Previously these were not saved at all.)

There are multiple bugs regarding some of these settings, this PR does not attempt to fix them.

TAStudioSettings.SingleClickAxisEdit was removed due to not having any UI for users to change it.
TAStudioSettings.OldControlSchemeForBranches still exists but no longer has a UI for users to change it. It did two things: (a) if not in recording mode, does not load a branch when the user says to load a branch, instead just seeking to the frame. We already have separate functionality for this. (b) If in recording mode, truncate the movie after loading a branch. This is basically redundant, since the truncated inputs would be overwritten via recording new inputs anyway.

@vadosnaprimer
Copy link
Contributor

OldControlSchemeForBranches was added for people coming from lsnes where loading branches behaves exactly like loading states during regular movie session. libTAS works similarly, and restoring entire movie state while in playback mode was only added on my request.

I don't know if anyone uses it, but I don't see any reason to remove it. Since people stopped asking for it maybe they're using it now?

@SuuperW
Copy link
Contributor Author

SuuperW commented Dec 18, 2025

loading branches behaves exactly like loading states during regular movie session

That isn't what it does. The normal branch behavior is much closer.
OldControlSchemeForBranches does NOT LOAD THE STATE if recording mode is disabled. It only seeks to the frame where the state was created.
I tried to check how regular states behave in terms of truncating, but found that they are actually absolute trash: They refuse to load if the states' input log doesn't match the current one, which is an absolutely absurd restriction which makes them almost useless. So making it behave like regular states would be totally pointless. EDIT: I was able to load the state if I switched back to recording mode. So, loading a state in recording mode DOES truncate the movie. (but this causes the unexpected behavior of (a) load state on frame 1 in recording mode (b) switch to read-only mode (c) attempt to load state on frame 2, but it fails)

But still, as I've indicated earlier, I see no value in doing this:

This is basically redundant, since the truncated inputs would be overwritten via recording new inputs anyway.

@YoshiRulz
Copy link
Member

I think a UI redesign should be separated from these small changes to behaviour.

@SuuperW
Copy link
Contributor Author

SuuperW commented Dec 19, 2025

I think a UI redesign should be separated from these small changes to behaviour.

Maybe, I just thought this one was so obviously useless.

@vadosnaprimer
Copy link
Contributor

loading branches behaves exactly like loading states during regular movie session

That isn't what it does. The normal branch behavior is much closer. OldControlSchemeForBranches does NOT LOAD THE STATE if recording mode is disabled. It only seeks to the frame where the state was created.

Changing the current movie to whatever is contained in the branch is not closer to loading a state in read-only mode. If the current movie has diverging input from what is in that state, it will fail to load. TAStudio just seeking to that frame is my approximation of that behavior because actually loading inputs from that branch is not allowed, only jumping to that frame, and greenzone making it potentially not instant is a consequence of having greenzone in the first place. Maybe refusing to load it altogether is better, but I think seeking is still better.

but this causes the unexpected behavior of (a) load state on frame 1 in recording mode (b) switch to read-only mode (c) attempt to load state on frame 2, but it fails

Maybe it doesn't get enough use to have caught this.

But still, as I've indicated earlier, I see no value in doing this:

This is basically redundant, since the truncated inputs would be overwritten via recording new inputs anyway.

Which is not how it works with traditional rerecording, so I let people have an option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants