Lix Editor Review

[WillLem]

Here's my video review of the Lix Editor

I first made a level in NeoLemmix, to get the ideas together in a familiar environment, then recreated the level in Lix.

Attached are the levels created in the video, for each platform.

[Simon]

Thanks!

Add-to-selection exists, it's bound to V by default, you remapped it to B and didn't use it. Looks like V is a terrible keybind and it should be Ctrl. The reason for V is that it's positioned really well next to ESDF, the standard tile-moving keys.



The grid is a mode, and has two effects: Align mouse-dragged tiles to the grid, and make keyboard-moved tiles jump in steps of the grid, whether aligned or not. Looks like the tooltip is terrible: "Round tile coordinates to multiples of 16" doesn't sound like it toggles a mode that affects future moves; it sounds like you must select tiles first, then hit this button once.

It's possible to separate these two effects of grid into two features, I don't know if that's any better. They seem like they belong together.



Tile copying (duplicating) should indeed be in place. Reason for the offset: This was the easiest visualization that something was copied. For duplicating-in-place, I'm envisioning some graphical effect of the fresh tile zipping into place from afar.

A possible alternative to always-paste-in-place is: The duplication feature shall remember your moving (of the second tile with respect to the first), and then, on hitting duplicate again, the feature pastes the third tile immediately at the same offset. I.e., the third tile will be inserted so that it immediately relates to the second tile as (the second relates to the first after you've finished moving the second).

As it stands in 0.9.35, with the dumb duplication, the best usage to create a homogenous row of tiles is to copy one, move, select both, copy, move, select all 4 tiles, copy, move, select all 8, ... with the copy hotkey A that is also directly next to ESDF for moving. Hotkey A is also terrible for newcomers, but its relation to ESDF is so good that I'm uneasy remapping the default. Up for debate.



The resizing menu needs a preview. It would be enough to have two colored rectangles overlapping, to roughly visualize the result.

The resizing menu should ideally be ditched altogether, and be replaced by the possibility of dragging borders within the main view of the editor.

-- Simon

[Dullstar]

In general, I find a lot of the default keybinds for the Lix editor to be rather unconventional, and I'd say that it's probably one of the hardest parts to get used to. They're easy to look up, at least - that's one thing Lix does significantly better than NL, especially in-game (I managed to learn enough of the skill hotkeys to start using them in just a few multiplayer sessions, but I still don't use the skill hotkeys in NL, because they take a lot of trial-and-error and/or looking them up in the settings menu) - but if I expect a certain button to do a certain thing, it's really hard to get used to something else, especially the more set in that is (I have a lot of trouble fast-forwarding and framestepping in Lix just because I'm so used to the NL hotkeys for it).

I notice references to keys being where they are due to ESDF, but to be honest, I didn't actually know you could use ESDF. I just use the arrow keys - which is totally fine, honestly - since I'm not typing words, I don't need to have both hands on home row, and since I'm moving pieces around with the keys, I'm not using the mouse much. Technically, I do end up having to move a hand to the mouse sometimes, but I don't really notice since it tends to be on slow stuff where most of the time taken to complete the action isn't because of the time taken to make the inputs (e.g. piece selection).

If there's one thing I'm curious about, it would be what the influences and decisions behind a lot of the default keybindings were. I imagine there probably is a reason for them, but they're certainly unusual from an outsider perspective.



NL doesn't really give any feedback about duplicating in place, but once you get used to it, it's fine and honestly probably preferable (you get feedback when it doesn't work, because you moved the original instead of the duplicate you were expecting, and since it's such a commonly used function, any feedback you do give must absolutely not disrupt workflow) - although a nice convenience feature might be automatically deleting the duplicate if it doesn't actually get moved before being unselected.



I like the idea of dragging borders, but I think this should be in addition to, rather than in place of, the resizing menu (although it is probably possible to improve the menu a bit). Dragging is fine for smaller tweaks, particularly if it snaps to the grid if enabled, but I don't think I'd want it to be the only way to set the current size. It's nice to be able to just type in the number if you happen to know the size you want, or to be able to, for example, precisely double the size.

[Proxima]

Dragging is fine for smaller tweaks, particularly if it snaps to the grid if enabled, but I don't think I'd want it to be the only way to set the current size. It's nice to be able to just type in the number if you happen to know the size you want, or to be able to, for example, precisely double the size.

Absolutely. I've said this before, but I don't want it to be forgotten because it's really important, especially with Lix's multiplayer focus. Setting the size to an exact multiple of the current size is extremely common, and needs to remain easy. Also, resizing by entering a number is just a lot more comfortable. It's an essential feature of an editor for me.

[WillLem]

Add-to-selection exists, it's bound to V by default, you remapped it to B and didn't use it.

Hmm, yeah, I'm not sure why I did this particular remap. It was maybe to offset setting "Save" to V. Good to know this is possible, though. I'll likely remap all of the hotkeys now that I know what they're for.

The grid is a mode, and has two effects: Align mouse-dragged tiles to the grid, and make keyboard-moved tiles jump in steps of the grid, whether aligned or not. Looks like the tooltip is terrible: "Round tile coordinates to multiples of 16" doesn't sound like it toggles a mode that affects future moves; it sounds like you must select tiles first, then hit this button once.

Tried this: it's a good one, for sure. Maybe each step (2, 8, 16) could have its own hotkey for easy switching? Also, I'd suggest making the tooltip something like "Set size of steps for tile movement".

Tile copying (duplicating) should indeed be in place... For duplicating-in-place, I'm envisioning some graphical effect of the fresh tile zipping into place from afar.

Nice idea, but is there any reason that paste-away and paste-in-place couldn't be 2 separate functions? Both can be useful for different things.

The resizing menu should ideally be ditched altogether, and be replaced by the possibility of dragging borders within the main view of the editor.

Along with comments from others, I agree that the best way to handle this would be too allow specifying of border size via typing into a simple "width" and "height" value field rather than the current system, which is a bit confusing.

Draggable borders would be great for fine adjustments, though, for sure!

[Simon]

Right, ditching the size dialog entirely isn't good. It's necessary to set the level size to precise numbers.

Problem with the 0.9.35 resizing dialog: It prompts you for the difference between existing size and desired result. The only benefit of this: You immediately specify the side where the space should be added. Often, it would be nicer to enter directly the final result. Then we must specify separately which border should change, and for that, the dialog should offer anchoring.

Anchoring

As suggested by Dullstar for NL Editor.

It's even conceivable to, optionally, specify the new size as a fraction, e.g., I want to resize the map 3/2 as wide to make a 3-player version from my existing 2-player map.

There is more to reply to, thanks! I'll come back to it.

-- Simon

[geoo]

I'm a bit late, but really great to see a first-time user trying the editor. It's always insightful to see what should be made more obvious.
I wonder if it's worthwhile making a brief video tutorial at some point to show off the features, in lieu of everything being immediately super intuitive?

I thought I'd chime in by showing a video where I'm trying to recreate WillLem's level in the editor, to show my workflow: https://youtu.be/vq1TKHLRWLc
This is at normal speed; I'm a bit clumsier with the mouse than usual because to record I had to run Lix on my other machine where the mouse acceleration is strange.
But once you're used to the interface and hotkeys (there are a few more I should get used to), it's very quick to design levels.

I've never used the NeoLemmix editor (I think), and I guess it has evolved a bit from old Lemmix. But the two things that bugged me back then in the Lemmix editor were that there was only a bar of terrain pieces to select, while Lix shows you a full screen full when you're inserting a new tile; and the second that the usefulness of the grid was quite limited, both due to the tile sets themselves and the editor. (I don't think there even was snap to grid when dragging with the mouse?)

The things bugging me in the Lix editor are the lack of paste in place, and that there's no great way of generating maps for different amounts of players from a template (I have to do math when resizing, so Simon's suggestions for the resize dialog sound pretty good; and then the hatch/exit assignments get shuffled around when changing the number of players).

If there's one thing I'm curious about, it would be what the influences and decisions behind a lot of the default keybindings were. I imagine there probably is a reason for them, but they're certainly unusual from an outsider perspective.

Because I use my mouse in the left hand, I remapped everything, but my layout basically mirrors the defaults. I find it very satisfying to do everything without moving either of my hands (one on the mouse, one on the home row of the keyboard). Once you get used to it, everything else that requires you to move you hands is frustrating. I use the same setup in other level, image and graph editors (Tiled, GIMP, ipe) and everything's so fast.

There's always the trade-off between being friendly to beginners and being friendly to power users. Power users can always remap their keys, but then I guess you want to encourage beginners to adopt efficient habits that pay off in the long run. I guess it's similar to text editors like vi/emacs: when you get thrown into the deep end you have no idea what's going on, but later people get carried away by how amazing their (respective) text editor is.

Nice idea, but is there any reason that paste-away and paste-in-place couldn't be 2 separate functions? Both can be useful for different things.

I don't see any value in having paste-away, really. The only instance where it's handy is if you want to build a staircase that goes diagonally down, and that's too specific to warrant a specific feature.

Maybe paste in-place could work with a brief flash around the object to indicate something is happening?

Maybe each step (2, 8, 16) could have its own hotkey for easy switching?

You'd also need one for no grid (=1) I guess. I like one button to cycle around the grid (4 keys would take up a lot of keyboard estate, and I don't want to move my hand), but I guess there's no reason in the settings to not allow setting a separate key for each, and if you set the same for each it replicates the current behavior (like when you overload a hotkey for two skills). I almost always have grid 16 enabled, as the Lix tile sets are designed with the grid in mind.

Either way, looking forward to your levels, maybe at the next multiplayer session?

[Simon]

Thanks for the exhaustive reply!

lack of paste in place

Next version will have a hidden option (not in GUI, instead hand-edit the options file) to specify the offset, default is 16. You can set it to 0 for duplicate-in-place. We'll get exactly what we need, and it's important to allow this, but there will be no visual feedback. I need something better long-term.

I will release 0.9.36 with this in 1-3 days; you can self-build from unstable repo to get it earlier.

influences and decisions behind a lot of the default keybindings

Sorry for not coming back to this earlier.

The left hand shall rest in its normal typing position, and then ESDF behave like arrow keys for moving tiles.

The more important an action is, the closer I've mapped it around ESDF. That's why copypaste is A, very important. Grid is C, relatively easy to reach, and add-to-selection is V, even easier to reach. Insert-terrin is spacebar, delete is G. All this is around ESDF, roughly matching the of importance with the difficulty to reach from a left hand resting on the home row.

I agree with geoo in that heavy hotkey usage should be supported wherever possible, and softly encouraged without getting annoying for pure mouse users.

-- Simon