make reserving states on branch frames optional#4773
Conversation
I don't think that's generally the case. Sure, when it's random unrelated branches it doesn't really make sense, but having a savestate on the (current) branch frame is useful, especially when the area before it isn't greenzoned. I also don't think we should be changing the default here which it seems like you've done. Thinking about it, this logic applying to all branches really doesn't make sense, maybe it should only ever reserve branch frame states when it's the current branch? |
Why? I don't see why the current branch is anything special here, nor why any branch frame having a state would ever be useful.
I very much disagree. Since they seem totally useless, they should not be enabled by default. |
|
If you think reserved states on branch frames is completely useless, why make an option for it instead of removing this logic outright? I feel like you explained it decently well yourself in the tooltip text; branch states guarantee that you can edit parts of the movie after a branch state (for example after loading that branch) without ever being forced to greenzone everything before the branch state, even if everything before was invalidated due to the branch load. Having such an anchor on the branch state makes a lot of sense in my opinion, I don't know why you would want to remove it. |
Some people in Discord, CPP I think was one, insisted before that they are somehow useful. I never got any explanation for how, though.
Apparently, I did not explain it well enough. This feature is not related to the savestate that is part of a branch. It is only for the "greenzone": savestates that are created automatically and can be invalidated by editing the movie. The state that is loaded when you load a branch is a different thing that I have not touched. |
|
If you don't understand what this feature does, then don't remove it, not even as a default. This is not related to the savestate stored in branches at all, this is simply to guarantee that after loading a branch you immediately get a greenzoned frame that is reserved and won't decay. If a branch load invalidates a lot of greenzone that ensures that you can navigate past the branch frame freely without having to re-greenzone everything before it. Apparently "reserved" states aren't actually reserved on the new state manager and can just disappear, but that's a separate issue. |
I understand that it is using up space in the greenzone buffer (which is significant with large states and large numbers of branches), that in all my TASing I have never once wanted it, and that the state manager is designed in a way that is not meant to rely on them.
You still get that, unless there is already a nearby state ("nearby" according to the state manager's settings), which means you can quickly seek there anyway. A state can be captured without being reserved.
Why does it need to not decay? If I go on editing after loading a branch, why would I be expected to want to return to the frame(s) after the branch frame in the distant future (I say distant future because that's when a non-reserved state would have decayed)? Even immediately after loading a branch, in my experience I am more likely to want to look at the branch frame itself and the frames preceding it. (For example I often make a branch when I get some trick to work, which naturally means the branch is after the trick and there are no meaningful input after that frame.) Also relevant: 8d066ff. You removed this feature entirely in the past, and @CasualPokePlayer reverted it in 48c545a (with no explanation, at least not in git or GitHub). The feature was added by adelikat with #2321, along with the original implementation of reserving marker states. The comment given for branches references a "reserved list" which does not exist anywhere, indicating that however things worked at the time it was implemented, is not how things work now. All the talk in the PR and linked issue regarding reserved states are for markers, nobody is talking about branch frames. It's possible some people want to use branches as markers, without having to manually keep a maker synced with the branch. But the current implementation is not fulfilling that purpose, since it does not reserve the state prior to the branch like markers do. If that was the intent, this feature should be "treat branches as markers" and the reserved frame should be changed to be the one before. And I still think it should be default off, since this is not the primary intent of branches. |
Sounds acceptable, tho that exact wording is not very clear about which aspects of branches would be mirroring which aspects of markers.
It only becomes a problem with big savestates or if someone mindlessly spams branches. Those sound like rarer scenarios than normal, therefore default should to to have it enabled. And no, jumping to branch frame is absolutely part of their everyday use. Maybe some of the benefits from it were obsoleted by popup screenshots, but still. If I repeatedly tweak some big portion of the input with branch saving involved, I will use jumping to branch frame just like I'd use a marker, to get back to some milestone frame to start new edits from there. |
Part of my point was that the current implementation does not support jumping to branch frame; only jumping to after the branch frame. Since people are using the jump to branch frame feature and the lack of a reserved savestate on the prior frame doesn't appear to be a significant issue, we apparently don't actually have much or any need for a reserved state there.
And because the savestate manager gets better at keeping states everywhere with small states, having a reserved state prior to the branch frame becomes less important with smaller states. I don't normally use cores other than melonDS (which has rather large states), so I cannot say from experience but I would expect that with small states there will usually be states around there anyway. And with large states it is harmful. If it's always either nearly useless or actually harmful, then I think it should be default off. (but I'm less concerned about the default value than my ability to stop wasting space for these states.) |
That's true, and it caused an immdiate discussion and revert, evidently because people want this feature to exist. I mainly touched this because there was no code for un-reserving states at the time, so it was possible for dozens or hundreds of old reserved states to remain when constantly updating a single branch. Jumping to the branch frame is not helped by this state reserving, but I don't think that can be implemented properly, unless you allow TAStudio to re-use the branch savestate. The main thing reserved states guarantee is that you have a state anchor on the branch frame, no matter what other greenzone exists or doesn't exist.
Right, in cases where you expect dense greenzone this matters less, but it also doesn't cause any harm when savestates are that small. In cases where you have very few or no states at all (3DS), having a reserved state is valuable imo. As I said above, I think limiting the reserve logic to only reserve a state for the currently active branch would make sense and resolve all concerns regarding workflows that use many branches. |
Again, why is it useful for this state to be reserved?
Without knowing why people want this feature to exist, I am not confident that this will keep said people happy. But if it does, I am in favor of it.
I hope to eventually allow special greenzone states (such as this one) to have screenshots. I do not know if I will do it any time soon. (I'd probably want to change TAStudio's |
It is useful for that state to exist, and marking it as reserved is a way to ensure it does. |
|
What I meant to ask is, why is it important for that particular state to exist? Or more precisely, why is it important that the amount of re-greenzoning required to seek to |
4 participants
Currently, TAStudio will keep a greenzone state on each branch frame. This is a waste of space in the greenzone buffer. This PR makes those states optional.
Check if completed: