CTR-Z undoes image edits in play mode

SFRPG ruleset (v2021-08-10) for Fantasy Grounds
Copyright 2004-2021 Smiteworks USA, LLC
Core RPG ruleset (v2021-07-06) for Fantasy Grounds
Copyright 2021 Smiteworks USA, LLC
FG [TEST] 4.1.5
No Extensions loaded

Added LOS and Lighting changes to image then switched to play mode. Did a CTR-Z and the last image edits were removed. I repeated CTR-Z in play mode and Image elements continued to be removed.

I would think CTR-Z should not undo image edits while in play mode. Is this functioning as intended?

This is functioning as intended. An image is a single monolithic control, and all undo/redo information is stored on a per control basis.

Regards,
JPG

Is it also intended that undo/redo works when the image record is locked? It seems really easy to inadvertently undo a change on a map (e.g. having wrong window selected when performing an undo operation), even if layers and the image are locked (undo unlocks layers).

Quote:

---

Originally Posted by Ecks

Is it also intended that undo/redo works when the image record is locked? It seems really easy to inadvertently undo a change on a map (e.g. having wrong window selected when performing an undo operation), even if layers and the image are locked (undo unlocks layers).

---

This was the point I was trying to make in my original post.

Yes, currently that is the way that it works. The image control field doesn't have a true "lock" state; because then if the image was locked, you couldn't add tokens, move tokens, add pointers, and so on.

We made everything that could be done within the image control undoable; and this was similar to the way it worked before (except that the new version covers more actions consistently).

Remember, you can always redo an action using CTRL+Y.

I'll see if it makes sense to somehow how multiple undo stacks per control somehow; but it wouldn't be something in this version coming up, and it could be complex due to how everything else is built.

Regards,
JPG

Got it, thanks for clarifying. Closing the image after creating/editing to clear the undo stack seems sufficient for avoiding inadvertent undo's later during gameplay, so the case I was thinking of doesn't seem as much of an issue.