Author Topic: Undo in the editor  (Read 340 times)

0 Members and 1 Guest are viewing this topic.

Offline Simon

  • Administrator
  • Posts: 2828
    • View Profile
    • Lix
Undo in the editor
« on: May 04, 2020, 11:55:43 am »
Undo in the Lix editor will happen.

This is long overdue. It's hard to implement on top of an editor that doesn't already support it, but it doesn't matter, it must happen. It's fine if it takes several weeks, as long as I focus on it whenever I develop.

Reason: Yesterday, I trashed 20 minutes of unsaved work and raged.



There are more severe usability issues in the editor. Giga's rant is still 80 % accurate after two years, mainly about how disorienting the editor is, and how bad/long the feedback loops are.

It's glaring when one hasn't build levels with the Lix editor for a year, and then comes back to it.

-- Simon

Online namida

  • Administrator
  • Posts: 10338
    • View Profile
    • NeoLemmix Website
Re: Undo in the editor
« Reply #1 on: May 04, 2020, 07:54:25 pm »
In cases where I've had to retroactively implement Undo - and even in some cases where it isn't retroactive - I've achieved this simply by having a List<MemoryStream>, and each time a change occurs to the level, the level is saved (exactly the same way it might be saved to a file) to a MemoryStream which is then added to this List<>. When the user hits Undo, load the previous stream. Have an int variable keeping track of the current position in the Undo list; if the user is not at the end of the list and makes a change, nuke all MemoryStreams that are newer than the current position. (Not nuking them until this allows for a Redo function to exist.) You may need to skip certain aspects of loading (for example, you probably don't want to re-center the screen just in response to Undo) when loading from the undo list.

Probably a bit memory-hungry compared to a delta-based implementation, but also likely to be less bug-prone (especially in terms of bugs that cause data loss rather than just annoy the user) and far easier to implement when the system wasn't designed from the ground up with Undo support. I'd also guess that IRS levels are generally not complex enough for this kind of Undo to become a problem memory-wise on modern PCs.

Offline Ramon

  • Posts: 98
    • View Profile
    • JRK Studios
Re: Undo in the editor
« Reply #2 on: May 04, 2020, 11:17:35 pm »
Very nice! An undo function will definitely improve workflow during level design sessions. It is not rare to do some unwanted button- or keypress that, while not terribly wiping all the work put in, is sometimes annoying to manually revert.

(On second read that sentence sounds really weird.)

Offline Simon

  • Administrator
  • Posts: 2828
    • View Profile
    • Lix
Re: Undo in the editor
« Reply #3 on: May 06, 2020, 08:35:38 pm »
Thanks. Yes, if I can't get anything else to work properly, I will savestate the entire level.

First, I will attempt a delta-based solution, with the OO pattern of doable/undoable command objects. The undoable actions will be really low level: For a rotation of 7 selected tiles around their averaged center, the undoable action is a 14-fold composite action of 7 individual undoable rotations and 7 individual undoable moves.

I had a similar idea 3 years ago, but wanted really high-level undoables. It was hard though to revert the 7-tile rotation exactly: There are rounding errors when computing the centers and the 7 tiles' new integer positions, with hackish special-case code to kill the rounding errors. This is a nightmare to revert high-level, but will be much easier low-level.

Ramond: Yes, the mistake is usually annoying to revert, but it was rarely annoying enough to push undo. The way I want everything, it will be a large-scale refactor of the editor, and I had been too scared to attempt it seriously for years. >_>

There will be many undoables, you can change the level in so many different ways. Maybe I'll only implement undoable deletion first, and clear the undo stack whenever a not-yet-undaoable command comes. Mis-deletions and mis-moves are the most annoying mistakes. :lix-grin:

-- Simon

Offline ccexplore

  • Administrator
  • Posts: 5289
    • View Profile
Re: Undo in the editor
« Reply #4 on: May 07, 2020, 08:55:55 am »
It was hard though to revert the 7-tile rotation exactly: There are rounding errors when computing the centers and the 7 tiles' new integer positions, with hackish special-case code to kill the rounding errors. This is a nightmare to revert high-level, but will be much easier low-level.

Interesting.  Does that mean it would've been difficult for a user to manually revert too?  It sounds like the user couldn't just rotate it back the other direction by the same amount and always expect to get back exactly to the original setup.

It's probably easier to implement undo of movement of a single tile by simply remembering the old position/orientation, and just restore them directly upon request to undo, instead of trying to honor it via an "opposite" movement.

Offline Simon

  • Administrator
  • Posts: 2828
    • View Profile
    • Lix
Re: Undo in the editor
« Reply #5 on: May 07, 2020, 09:51:30 pm »
rounding errors when computing the centers and the 7 tiles' new integer positions, with hackish special-case code to kill the rounding errors. This is a nightmare to revert high-level, but will be much easier low-level.
Does that mean it would've been difficult for a user to manually revert too?

Yes, exactly, this is a problem.

The special cases fix only the most common case when all these apply:
  • You have one or more terrain tiles selected,
  • you have no gadgets selected, and
  • the encompassing rectangle of your selection has no sides that exceed wrapping dimensions of the map.
In this good case, if you rotate your selection 4 times, it should be back where it started.

Selected gadgets don't rotate when we tell them to rotate, this is the OO fruit basket problem with the fat-interface solution. Thus, gadgets in the selection break the assumption of the anti-rounding-error code that the (encompassing rectangle of the pieces that rotated in unison) is, per dimension, at most 1 pixel off the (theoretical rotation of the original encompassing rectangle).

Torus dimensions mod the tile coordinates after every rotation, this can squish the selection together too early, e.g., when you press rotate-quarter-turn twice to rotate half a turn.

Quote
remembering the old position/orientation, and just restore them directly upon request to undo, instead of trying to honor it via an "opposite" movement.

This is smart. My hunch would have been to separate UndoableMove : Undoable and UndoableRotation : Undoable. But your approach sounds even more robust and reasonable.

-- Simon
« Last Edit: May 07, 2020, 10:21:59 pm by Simon »

Offline Forestidia86

  • Posts: 575
  • inactive
    • View Profile
Re: Undo in the editor
« Reply #6 on: May 09, 2020, 11:32:52 pm »
Do you plan undo and redo then for grouping of tiles? There is an issue (#280) that ungrouped tiles go into their original position instead of the one that they were in when they were grouped (Edit: remembered that wrongly, the issue only occurs when rotating/mirroring the tile group, the tiles go then in the original grouping position). How does that interact/relate then? Does undo put them then in the grouping position instead of the original?
« Last Edit: May 09, 2020, 11:55:58 pm by Forestidia86 »

Offline Simon

  • Administrator
  • Posts: 2828
    • View Profile
    • Lix
Re: Undo in the editor
« Reply #7 on: May 09, 2020, 11:42:26 pm »
Undo a grouping: Yes, this should be undoable. Whenever the most recent action has been a grouping, undoing that grouping can't run into issue #280 because the group is in its original orientation.

Issue #280 is interesting and needs more work. I feel like issue #280 is rarely a problem, but when it hits, it feels so odd, indeed. I haven't invested enough time to think about a nice solution to #280, maybe it's easier than I think.

-- Simon

Offline Forestidia86

  • Posts: 575
  • inactive
    • View Profile
Re: Undo in the editor
« Reply #8 on: May 09, 2020, 11:45:58 pm »
Ah, I understand, I had the issue wrongly remembered.