Undo in the editor

[namida]

I suppose I should more clearly demonstrate what I'm saying.

Imagine the below arrangement. Assume this is three terrain pieces, no use of "No Overwrite".

The yellow and green spots, I would lean towards the dirt clump and the bones being selected respectively, but this is not a super strong preference. On the other hand, the cyan spot, I would 100% expect the bones to be selected, even though they have no solid pixel at that point.

[Simon]

That is a nice example.

Cyan: Yes, the bones are so prevalent there that it's usually a mishap when we click in their small hollow gap, expecting the bones to be selected, but the dirt would be preferred by pixel. Selecting the dirt here is annoying no matter what.

The best justification here is that Lix already highlights the hovered tile (that isn't yet selected) with a darker rectangle (hover is grey, selection is white), and you would see that the wrong tile is hovered before you click. You would instinctively move the mouse slightly to hover the bones, then click.

I am used to this visible hovering, can't tell how nasty it is without. I'd expect it to be much nastier without visible hovering. But I also can't tell either how often this mishap happens of clicking in the tiny hollow space. I'm personally weak with mouse pointing in general, I often misclick stuff even in non-Lemmings GUIs.

Green: My prevalence is weak, too, but merely because the dirt is so large; it feels as if the user should point more clearly to the dirt to select the dirt. Still, it sounds reasonable to program the green spot to select the dirt. I wouldn't be annoyed if it selected the bones.

Yellow: This is much more clearly a spot on the single bones. I might get annoyed if it picks the dirt, but at least the annoyance would be over quickly because I'd immediately re-click with priority invert. Priority invert in general is super useful in any editor here, and it's good that both editors have it.


Thanks, I see that both algorithms have their drawbacks and nothing does 100 % what the user thinks. It might even depend on what tiles are common in the games.

If we were to optimize this to the extreme, maybe tile designers should tell the game how they want each tile to be treated: Selectable by convex hull (bones) or by pixels (mesh).

-- Simon

[Simon]

Z-orderings of single tiles work. Hack/regression: If user selects multiple tiles, then gives command to z-order: Editor will z-order only one tile (ostensibly at random), and deselect (!) all others. Reason: By design, Undoables always suggest what tiles should be selected afterwards. The hack is that only one z-ordering works well, thus only one tile is selected afterwards.

I feel like I can't release with such a regression. I want to find a solution (will likely be elaborate and inelegant) that (1.) works with the existing undo design and (2.) z-orders many tiles at least somehow meaningfully.

Regression is not good. Simon seal of quality demands so such infuriating UI regressions.



Thus todo:
* Somehow allow multiple z-oredrings, or at least keep selection selected
* Clear undo stack on (change of map dimensions)

-- Simon

[namida]

How is Z ordering currently handled, and what makes it difficult to handle a group of them? In particular, why could it not be handled as a series of single-piece reorderings, with the before / after selection being part of the composite undoable rather than the individual steps?

[Simon]

Apologies for not answering this. The problems come from several designs, each highly useful in isolation to prevent bugs:

• I want the multiple z-orderings to go on the stack as a single compound undoable.
  
• I want the Undoable to be completely computed when they go on the undo stack. Reason for this is D's language design: There is no mutable keyword in D, unlike C++, to compute the result lazily in a const/immutable object; immutable also makes guarantees about thread safety that I don't need here, but that a C++-like mutable would subvert.
  
• All changes to the level shall happen by applying undoables to the stack. All other views into the level should be const.
  
• Avoid creating temporary copies of the level to compute the effect of an undoable action.

The problem with multiple z-ordering under these rules is:

The meaning of a tile-list iterator changes after earlier reorderings. I don't want the iterators to remember tiles; they must work solely by position: The reason is that they must continue to work even if the underlying tile is removed and an equal one, but not the very same one, is inserted in its place. Thus, by not tracking identities of tiles, it's hard to track/compute several z-orderings in advance.

Planned hack: Subvert the desire to operate on the level only via the stack. Z-order one-by-one physically in the level, compute single-tile Z-ordering undoables while doing that, revert the physical changes to the level (level is now as before the operation), compound the computed z-orderings, then apply the compound to the stack (thereby applying the same changes a second time, this time for good).

I will finish Undo during the holidays. It will be released during 2020!

-- Simon

[Simon]

Z-Ordering multiple tiles works. None will be deselected.

Todo:

• On changing map dimensions/wrapping, either clear the undo stack -- or make it undoable and wrap the tile coordinates in an undoable way.
• Minor cleanup.
• Release Lix with complete undo support this Christmas.

-- Simon

[Will]

Release Lix with complete undo support this Christmas

Great stuff, Simon, looking forward to this! I'll coincide its release with my long-promised video review of the Lix Editor early in the New Year, in order to help showcase the update.

[Simon]

Looking forward to it!

Several things from Giga's rant are still valid, the level view is disorienting. But I want to learn the bigger pain points in general.

-- Simon

[Simon]

Topology changes are now undoable.

This means: Changing width/height/wrap of a level is undoable. The tiles' coordinates will be fixed accordingly, i.e., they wrap according to the new wrappings, and they move if you added/removed space on the left or top of the level. These coordinate fixes are also undoable, and are grouped with the topology change that provokes them.

I'll have to bug-test this manually a couple more times this evening. It's a complicated feature because the coordinate-fixing needed a variant of the normal tile-moving Undoable. The normal tile-moving Undoable wraps, this was necessary because I wanted to easily group moving multiple tiles, only some of which are dragged past a torus seam. The coordinate-fixing must ignore the wrap; it will carry raw coordinates.

If I don't find nasty bugs, I'll release tomorrow. It's already possible to build branch editor-undo of the unstable repo and test yourself. Undo has been released! Undo is a massive feature:

$ git diff --stat master
[...]
55 files changed, 2673 insertions(+), 922 deletions(-)



Happy Simon.

-- Simon