#135 1.11.81 Wildly screwed up undo system

[Xfing]

This is probably a recurring bug, as I remember this happening in some previous versions, then being fixed in later ones. The undo function works very haphazardly, tending to erase several dozen actions in a single use and then failing to revert them by pressing "Redo". Also creates some undesirable cube connections if any cube at the time happens to be Marked. This really slows work down to a grind.

[Sirius]

There have been fixes to certain instances of this, but most likely you've found another one that hasn't been fixed. Ultimately this is a software architecture problem - I don't think DMB2 was designed to support undo/redo, and that makes it very hard to get an implementation of undo/redo working reliably in DLE.

I'll take a look at this specific issue and see if I can figure out what's going on though. It'll be a band-aid, but the real fix is too large a project to complete in the near future.

[Sirius]

Having trouble reproducing the issue with side joining malfunctioning when cubes/sides are marked - do you have an example that reliably causes this problem?

[karx11erx]

This problem is extremely hard to reproduce and fix and very dependent on what sequence of editing actions is involved.

For each potential undo step, DLE has a separate undo buffer "instance" (so if you allow DLE to backtrack 100 editing actions, you will have 100 undo buffer instances).

Depending on what level element type was changed, the undo system always copies complete parts of a level (like all segments, all triggers, etc.) to the undo buffer's current buffer instance. If a sequence changes affect different types of level elements, DLE will try to add the element backups to the same undo buffer instance (so if you first change a segment, it will save all segments to the undo buffer's segment backup area before applying the change, if you then change a trigger, it will save all triggers to the same undo buffer's trigger backup area. That way DLE tries to couple connected actions (because e.g. deleting a segment may also affect the walls and triggers). It also tries to keep track of nested as well as of repeated actions on the same level element type.

Somewhere in some function there must a be fluke in the code, like not properly detecting nesting or so. I have made several thorough attempts to find all such areas, but apparently there are still some left.

[Sirius]

Ticket moved from /p/d2x-xl/bugs/2724/