Bug: Control-Z (Undo) Completely Unusable

[dorpond]

https://rptools.slack.com/files/U18GPQKDH/F77PZPZGA/drawing_tool_wtf.mp4

Control-Z (Undo) is a complete mess (drawings and spell templates). I tried to show you in the video above, but once you are stuck in it's mess, it is hard to get out of it - even the Draw Explorer doesn't help.

I all my testing, I found that Undo (both drawing and spell templates) worked perfectly in 1.3B85 and then it was broken in 1.3B86. It has been broken ever since, even in 1.4.1.8 as well as Jamz fork 1.4.4.0.

I did some searching in the forums and tried finding a change log to help narrow things down. These might help:

Official Release Post: http://forums.rptools.net/viewtopic.php?f=1&t=18537
Testers Forum: http://forums.rptools.net/viewforum.php?f=60&start=50
Possible Change Log? http://forums.rptools.net/viewtopic.php?f=60&t=19624

Notes:
Azhrei and I were talking about this bug in Slack and he stated this:
"Looks like b85 was 5735, so the problem should be between 5735 and 5751.  However, I just used the SVN browser at sf.net and none of the comments lead to any obvious undo changes, so I looked at the commit info for anything that I thought had a possible change to the undo manager.  I didn’t find anything.  I’ll need to generate the diff for the entire range and not each commit, then look for the problem, but that’s a job for my laptop, not my tablet...
I still think it’s cool that you were able to narrow it down to starting in b86.  Good job!"

[JamzTheMan]

Found issue in SVN commit 5743, ZoneRenderer.java

Remove isEmpty() checks seems to fix issue...

e.g.

// if (!drawables.isEmpty())
timer.start("drawableTokens");
renderDrawableOverlay(g2d, tokenDrawableRenderer, view, drawables);
timer.stop("drawableTokens");
// }

[rkathey]

In my opinion, the undo should function based on the tool in use.
Pointer should under drop token, move tokens, drag-resize, etc.
Drawing, Templates, Fog, and VBL should undo the actions taken while those tools are selected.
I often hit ctl-Z by accident because I'm so used to using it in other programs to undo the last thing I did. It's a cursing moment when my last drawing disappears.

[Azhrei]

And IMO, we should just turn off Undo for templates since it's broken.

[Phergus]

So was this fixed? Partially fixed?

[JamzTheMan]

I don't know, it was over A year ago.

But I would guess if I found the fix I'd be surprised if I didn't fix it in my fork?

It seems familiar...

[Phergus]

I think your comment was for a different bug. That change has nothing to do with undo.

[JamzTheMan]

Hmm, ya looks like it lol. Still seems familiar. Pretty sure I worked with Dorpond on a fix in my fork...

Does it not work in 1.5.x?

[Phergus]

Got me. I never use it because it has always been unreliable. With Drawing Explorer available to manage/manipulate drawings, I rarely need undo.

[dorpond]

I’m almost positive Jamz and I fixed undo in his fork... test it out and see.

[Phergus]

For all intents and purposes, 1.5 is his fork.

[Phergus]

Testing with 1.5.3 using drawings and spell templates intermingled suggests that a fix was made. Unable to produce a problem.

Closing.

[Azhrei]

Testing needs to be done with a server running and a client connected. Then adding drawings and templates should be done on both systems with each one doing Undo operations out of order. For example, server adds two templates, then client adds one, then server adds one more. What happens when the server uses Undo twice?

The initial problems with this were based on the Undo stack containing both remote and local changes, with no tracking of who made the change, meaning an Undo could undo what someone else added. It got really strange. But I agree with your earlier statement — it's always been buggy so I don't use it either.

[Phergus]

Testing with Server and two connected Player Clients. MT 1.5.3

• Undo buffers are specific to each client. Player clients cannot undo drawings made by other players or the GM.
• Interspersing the making of drawings between the different clients had no impact on undo/redo for any client.
• A drawing made after one or more undos or following a redo becomes the top of the LIFO stack.

Unable to produce a problem.

[Azhrei]

Cool! Sounds like Jamz squashed this one then... 🙂