Redo not always working

[David_Fine]

Undo and Redo is obviously an important working tool. Make a change, don't like it, hit Undo. Change your mind, hit Redo. "BEEP". Redo does nothing. What the...?? I already posted in tech support and Paul F gave me some good ideas for workarounds, but really, Redo should work, so this is a request to fix it.

Here is an example of the work path:

- Start with version 1 of a drawing.
- Erase something.
- Redraw it. Now it's version 2.
- Play it. Want to compare it to how it looked in the first place (version 1), so...
- Hit UNDO to get back to original version 1.
- Play it again. Actually prefer the fix (version 2), so...
- Hit REDO in order to go back to the redrawn version 2.
- REDO beeps and does not work.

Same issue editing on the timeline:

- Deleted an instance.
- Made an adjustment to timing of another instance.
- Hit UNDO to get it back as it was.
- Prefer the change, so want to REDO the above action to delete instance and adjust timing, but hitting REDO beeps and does nothing.

Surely Redo should actually redo, so I wonder why it does not. Is this a bug?

[Mads Juul]

I guess I never redo so this is why I haven't noticed before but
It also looks like a misbehavior to me. or something that could be improved.

It seems like when we change currrent image the history "over the current state" is deleted.
With "over the current state" I mean how the History States is organised in the History Panel.
if I draw 5 separate strokes , and undo 2 times I have 2 strokes "over the current state"
I have 2 strokes "under the current state". And the third stroke is the current state.
If i now change current image the 2 strokes Over the current state is deleted.

So it is no longer possible to go back to this states.
This mans if you want to redo something.
Don't change current image.

Could this be improved? So we can change frame and start sdrawing again with óut loosing the Undone history?

What about if we had undone something and start drawing again. TVPaint automatacally copies the current state to the top of the list and moves the current state to here?
Does this makes sense?


-Mads

[Paul Fierlinger]

I've always taken this as something of a necessary evil because the history could quickly become unwieldy in it's size thus a memory hog. If I'm correct (or close to it) perhaps there could be a place in preferences where we could set our own limits. Limitations on temp caches can greatly vary from computer to computer.

[David_Fine]

Certainly, it could be a preference choice, but in simple terms, if I undo something, don't want it that way and then immediately want to redo it back to how it was, I should be able to do that. Any other program works that way.

[ZigOtto]

...
Same issue editing on the timeline:

- Deleted an instance.
- Made an adjustment to timing of another instance.
- Hit UNDO to get it back as it was.
- Prefer the change, so want to REDO the above action to delete instance and adjust timing, but hitting REDO beeps and does nothing.

Surely Redo should actually redo, so I wonder why it does not. Is this a bug?

Redo does it job here,
here's my actions sequence, the replica of your last example :

- Delete an instance,
- go to another instance (the previous one),
- adjust its timing (add 3 exposures),
preview the result of this change (play flipbook),
- hit 3 times to Undo [adjust timing + change of frame + Delete an instance],
so I'm now on my previous state, the version 1, preview again (play flipbook),
finally, the version 2 seemed to work better, so I want to get it back :
- hit 3 times Shift to Redo [Delete an instance + change of frame + adjust timing],
Version 2 is restaured, I preview it (play flipbook), ...hmmm ...
not quite sure of my choice, and decide to have a look on my the version 1 one more time :
- hit 3 times to Undo [adjust timing + change of frame + Delete an instance],
version 1 is back ...
- - hit 3 times Shift to return to version 2 ...
etc...


edit :
sorry, I didn't read Mad's post, and my test was made on a tvpa v9.5,
so yes, there's something wrong in the Undo History management since V10.x,
imo it should be fixed (or "improved" if you don't call that a bug).

[Paul Fierlinger]

Funny that I tried the same last night just before going to bed with the same results as Zig O. and thought I'd post about it but left it for AM. I think that the issue might be that the undo-redo might loose its repetitions capacity as the history gets filled up a lot. If you test this on a freshly opened project it seems to work back and forth every time. But having said that, I have run into David's situation myself and it just might be connected to the the History panel. I will test this again after several hours of work.

[Mads Juul]

I can't figure out why it's not working in the same way with you (?)

You are not doing the same as David. The bug in redo has something todo with drawing/erasing not creating/deleting exposures and changing timing.
I just tested and in your case redo is working. Bacuse of this I will conclude there IS a bug in redo
try this

1) draw 1 stokes on current image
2) undo 1 time (the strokes disappear)
3) change current frame
4) Now You cant Redo the stroke .

his must be a bug. How cant it be another thing?

[ZigOtto]

You are not doing the same as David. The bug in redo has something todo with drawing/erasing, not creating/deleting exposures and changing timing.

but it was exactly david's second example of his Undo misbehaviour, which I've replicated point to point .

try this

1) draw 1 stokes on current image
2) undo 1 time (the strokes disappear)
3) change current frame
4) Now You cant Redo the stroke .

his must be a bug. How cant it be another thing?

yep, (see my edit above)
but it used to work fine (at least on my older v9.5 version),
so it seems to be a bug introduced with the recent Undo History feature management.

[Mads Juul]

so it seems to be a bug introduced with the recent Undo History feature management.

I agree

[Paul Fierlinger]

This is what I meant when I said at the beginning that it must be a built-in limitation of the History manager, perhaps not exactly a bug. I wonder if it wouldn't be a good idea to add a reset button to the History Panel. With that in place, maybe the history management could be permitted to grow in an unlimited fashion up to a certain point, at which it would give us a warning to reset (but I can now see the complications associated with that too and I might be completely off with my guess work here, so... )

[Svengali]

Paul,
the "reset history button" you propose, is actually what happens (undo-stack-wise) when you explicitly move to another frame and then move back to the original frame. (starting and stopping play doesn't count as a reset history operation, but to move explicitly to the next or previous frame, does.)

This reset shows up in the HISTORY list as "change current image" which essentially establishes a fresh, new starting point for the undo stack. notice that all of the previous strokes are collapsed under the Stroke triangle (but remain reversible (undo-able) step by step...).

But as with any "garden of forking paths" once you return to a forking point and choose another path, the original path is forgotten.

Sven

[Paul Fierlinger]

Sven, are you saying that this is something unavoidable because it is the nature of the beast? Can you explain why the history management must work this way, and Is it because the entire retracing of the history path would become a nightmare to manage? I must admit that I've never had a need to redo entire animation sequences other than by jumping back directly inside the History Panel; otherwise I use redo usually on a single drawing within a frame. I'm just curious so I can better understand how the history management system works.

[Svengali]

Basically, yes I think. The nature of complex software dictates that the programmers have to make choices about how things are going to work and with TVPaint there are a huge number of things being managed behind the scenes so to speak. While something like the undo and redo commands appear to be single operations, potentially (depending on what actions are being undone) there are a vast number of states, layers and image differences that have to be read and stored during each undo so they can be reconstituted during a matching redo operation. TVPaint uses changing to another frame as a way point from which to build new stroke and other operations.

Elsewhere there is a thoughtful thread discussing all of the complexities of Undo/Redo that is worth reading through.

Sven

[Paul Fierlinger]

That's what I had guessed but didn't know how to to construct. This sounds like a similar task to deconstruct:

Elsewhere there is a thoughtful thread discussing all of the complexities of Undo/Redo that is worth reading through.

Sven

[Mads Juul]

but it used to work fine (at least on my older v9.5 version),

I just tested on 9.5.18 And This does NOT work.
This gives the same result

1) draw 1 stokes on current image
2) undo 1 time (the strokes disappear)
3) change current frame
4) Now You cant Redo the stroke .

So I guess it is not a bug, this is the way the undo always have worked.
I just made a search and found out it has been brought up before here
http://forum.tvpaint.com/viewtopic.php? ... edo#p63219

Here is an interesting quote from the thread

I'm using multi rede. But it doesn't work well (tvpaint 10, mac).
Try this: draw something > undo > move one frame right> redo : nothing happens....

But that's because you've started another action by moving to the next frame. Same happens when you draw something > undo then draw something else > redo; nothing happens. Unless I am misunderstanding you.

And I think Sewie has nailed it with the last sentense

But that's because you've started another action by moving to the next frame. Same happens when you draw something > undo then draw something else > redo; nothing happens.

But I agree with Joost in this

Yes, I understand that, but in my opinion moving to the next frame (or: moving trough your timeline) shouldn't be another action (when it comes to the 'redo' function). So that's why this is a feature request...

Makes sense.

So a +1 from me to a feature request that moving to another frame should not start another action. Or some other way to make redo work after a preview or frame change and first get reset when starting to draw on another frame. But I guess it is difficult to implement as Svengali mentions