[SUGGESTION] [EDITOR] Undo Button needed

[Wafflem]

The editor needs an undo button!

If one person makes a mistake in the editor such as moving a terrain piece or object by accident, they have no way of moving it back to where it exactly belongs. What if they move that terrain/object, and later they don't know where to put it back?

Also, if I were editing a Lemmings Plus Recycle Bin level but I don't want to move any of the terrain pieces or objects by accident (i.e. ruin the work of the original creator), this would be very beneficial. This is also beneficial for collaboration levels and tag-team contests.

If Microsoft Word can have it, Microsoft Paint can have it, and if you can backwards frameskip to fix a mistake in a level, I don't see why it would be any different for the NeoLemmix Editor.

A redo button wouldn't hurt either. Also, it would be beneficial if one can undo/redo as many times as they would like.

[namida]

I'll see what I can do about this.

[Simon]

An excellent suggestion. I'm looking forward to see exactly what an undoable unit of work should be.

-- Simon

[607]

Yeah, that'd definitely be useful.
I think having the ability to undo all your actions since starting the program would be good, too (certainly more than MSPaint's 3 times), but if it'd get bigger than 1 MB, it would be nice to be able to have it start deleting the first actions. Some people might have more than enough space, but I wouldn't want my hard drive to fill up with NeoLemmix undos. This is probably not a problem, though, as I think these logs would cost hardly any space.

[Apjjm]

One option would to lest us specify the undo stack size in a config file - I have a decent pc and don't mind giving a large amount of ram to the editor to save a large undo history in. As far as saving the undo state, one idea might be to store a full copy of the latest "checkpoint" then the history before that as a stack of binary deltas. Undoing is then setting the current state to the checkpoint (I.e. loading the checkpoint level), popping the delta off the stack and applying the delta to the checkpoint's level version - You should be able to store a pretty large amount of history this way even with a relatively small undo stack size.

But yeah, undo & redo would be really handy to have, it's one of the only reasons i do my initial pass on some of my levels where i am expecting to do a lot of fiddly layering still in JLevelBuilder before transferring it over to the NL editor to make smaller tweaks.

[ccexplore]

(certainly more than MSPaint's 3 times)

Actually, that limit had been removed since Windows 7 when they finally revamped MSPaint since god knows how long ago.

but if it'd get bigger than 1 MB, it would be nice to be able to have it start deleting the first actions. Some people might have more than enough space, but I wouldn't want my hard drive to fill up with NeoLemmix undos. This is probably not a problem, though, as I think these logs would cost hardly any space.

Undo logs don't typically need to live in disk storage, especially since they are not usually saved with the file.  Loading a web page nowadays likely take way more than 1 MB.  I don't really think there's a need to enforce any sort of limit on the undo stack, at least not until someone can prove running into an adverse low memory/low disk condition in actual usage.  As you said, each undo entry is not likely to take much data to represent anyhow--certainly a tiny fraction of the amount of memory needed to represent the graphics pixels of a piece of terrain or object.

[607]

Yeah, okay, you're right. It's very unlikely to pose a problem.
Sometimes I forget that such things aren't really a problem anymore with todays computers

[namida]

I didn't include anything like this in the new update, but I haven't forgotten about it. I just haven't decided on the best way to implement it yet.

[ccexplore]

I believe it's basically down to two implementation choices.  You can save the entire level in-memory or on disk after every undoable action (so undo is just a matter of reloading from one of these in-memory saves, similar to how rewind is implemented using savestates), or update the program in various places such that every action generates an undo record that can be used to reverse that single action.  Given that the program wasn't originally written on the outset with undo in mind in the coding, the first option will likely be less work and less error-prone to implement even if somewhat less efficient on resource usage (but unlikely to a degree that would matter).

[namida]

Working on this feature for the next update.

The good news is that when it saves the history correctly, Undo (and Redo!) themself are working perfectly fine.

The bad news is, the key phrase in the above sentence is "when it saves the history correctly". More often than not, it fails to save it when changes are made. I still need to look more into why, and how I can make it properly do so. (Pretty much the only case in which it currently does save it reliably is when a piece is dragged and dropped to a new position.)

[namida]

I think I have this working now, but it's very likely there's bugs in it somewhere. As such, I feel that an experimental release is nessecary for testing this:

https://www.dropbox.com/s/2df2n1kjuf0oobl/NeoLemmixEditor_V1.43n-B_1603282247.exe
(EDIT: Note, newer experimental verison on next page!)

For those who haven't used an experimental editor version before; you need to get the stable release (for the data files) then replace the EXE with this one to use it.

[Wafflem]

Found two bugs:
1. If I move the first piece of a level, then attempt to Undo, the piece won't undo at all.
2. If I move the second piece of that same level, then attempt to Undo, the piece will undo, but something else will happen: in the title bar, you can see, the directory of your level (e.g. C:\...\DynaLemmings\[lvl file]). That location disappears when I have the second piece undo-ed.

[namida]

Re: 1, what kind of piece? (ie: object, terrain or steel) Or any, as long as the index number is 0? I didn't encounter any problems when the level only had one piece myself; so more details would be helpful here.

Re: 2, I'll take a closer look at that one.

[Wafflem]

For 1, this happens when you open and edit an existing level, not a newly-made level.

If I edit one of the pieces (moving, flipping, rotating, etc.) right after opening that level, no matter what type that piece is and no matter what its index number is, that piece I just edited won't undo.

[namida]

Ah, gotcha. I have an idea why this might be happening, but I'll look closer at it soon.