NeoLemmix Editor - How should the grid work?

[Nepster]

There seem to be several different opinions floating around about how the grid should work. I have no preference in any way, because I am not using it, but I prefer not always having someone complaining whenever I make a change.

So my questions are:
- How should the grid work when you drag pieces around?
- How should the grid work when moving pieces with the keys?
- How should the grid work when duplicating a piece?
- How should the grid work when inserting a piece previously copied to the clipboard?

[Ryemanni]

How should the grid work when you drag pieces around?

The pieces should snap to the grid if it's enabled.

How should the grid work when moving pieces with the keys?

They should move to the next cell.

How should the grid work when duplicating a piece?

The dublicate should appear on top of the previous piece and then you can move.

How should the grid work when inserting a piece previously copied to the clipboard?

The piece should snap to the grid.

[Proxima]

Yes, I'm sorry if I haven't been clear in some of my responses. It's a good idea to set these out clearly.

- How should the grid work when you drag pieces around?
Push the piece to the nearest multiple of 8 (or whatever the grid size).

- How should the grid work when moving pieces with the keys?
Arrow keys (with no modifier) should move the piece by 8, rather than to a multiple of 8. This allows rapid tiling with a single piece (duplicate, move by 8, duplicate, move by 8 etc) even when the tiling does not start on a multiple of 8 (sometimes necessary to fit in with irregular terrain).

I love Dullstar's recent suggestion that, when the grid is on, ctrl-arrow should move the piece by 1. This allows slight movement without the hassle of turning the grid off for a single move and then turning it back on.

- How should the grid work when duplicating a piece?
Either the current method (duplicate at same location) or Lix's method (duplicate at (x+8,y+8)) are fine. I have no preference between these, so maybe stick with the current method as it's what NL users are used to? (The Lix method has a slight disadvantage that sometimes you lose pieces off the bottom of the level.)

- How should the grid work when inserting a piece previously copied to the clipboard?
At the moment it pastes at the same location as the copied piece, and I don't see any reason to change that.

[Nepster]

Thanks. I forgot to specify one more thing: For the second and third question, please tell me as well, what should happen if the existing piece is not (yet) aligned wrt. the grid.

- How should the grid work when inserting a piece previously copied to the clipboard?
At the moment it pastes at the same location as the copied piece, and I don't see any reason to change that.

This changed in the latest version. Now it pastes the piece at the cursor location, which makes a lot more sense e.g. in case the original location is no longer displayed on the screen.

[Proxima]

I see. Then I propose that pasting a piece (with grid on) should paste at the nearest multiple of 8 to the cursor. This isn't very important to me as I don't think I would ever use (move cursor to desired location, paste) as a method of adding terrain, but only (paste, move to desired location).

[Dullstar]

- How should the grid work when you drag pieces around?
Always snap pieces to the grid in this situation.

- How should the grid work when moving pieces with the keys?
Move the piece by the size of the grid. When control is held down, move the piece by one pixel.
If the piece is not aligned with the grid, do not snap it to the grid.

- How should the grid work when duplicating a piece?
The new pieces should be inserted in the same position as the original pieces, and should not be influenced by the grid in any manner.

- How should the grid work when inserting a piece previously copied to the clipboard?
When inserting a piece, either from the clipboard or from the terrain selection, snap to the grid for the initial position.

Other:
Include a button that, when pressed, causes a piece to be snapped to the grid.
When multiple pieces are selected, snapping should be based on the top-left corner of the selection, and the relative position of all selected pieces should be maintained. This behavior could be revisited if/when grouping is implemented.

[Simon]

- How should the grid work when you drag pieces around?
Push the piece to the nearest multiple of 8 (or whatever the grid size).
Always snap pieces to the grid in this situation.

The selection may contain multiple pieces. Snap the dragged piece to the grid, and move the selected nondragged pieces along with the dragged piece, preserving their relative position to the dragged piece.

-- Simon

[Dullstar]

The selection may contain multiple pieces. Snap the dragged piece to the grid, and move the selected nondragged pieces along with the dragged piece, preserving their relative position to the dragged piece.

I agree that the piece's relative positions should be maintained in all cases of snapping. Simon's proposal to use the dragged piece as the basis for snapping a selection may be more flexible and therefore potentially more useful than my suggestion of the top-left corner - though this does not adequately address the case when pasting, so I would consider: "When pasting a selection of multiple pieces, which piece should be the basis of the grid snapping?"

[IchoTolot]

I tested the current implementation of the grid and I think it works just as I expected and I really like having this option:

Pieces snap onto the selected grid size and a press on the arrow key moves to the corresponding neighbour grid space.

The size of the grid spaces is entirely customisable.

The things I would propose could be added/changed:

- Adding a hotkey to turn on/off the grid.
- Renaming the "Help" section to something like "Options" as I don't expect "Settings" under the "Help" section --> finding this feature isn't easy.
- Adding a new setting for the grid to turn on/off grid lines. Line color would best be the 255 0 255 pink to always be recognisable. This isn't 100% nessesary but I can see people would like to have this option.

Otherwise I love the addition of this feature, after I discovered it for me in the Lix editor and was told NL has it too now!