addendum: move to back buttons

[mobius]

had to start new topic cause the thread was locked; feel free to delete this after my question is answered;

http://www.lemmingsforums.net/index.php?topic=2628.new;topicseen#new

I didn't see anyone mention a button for moving the selected terrain piece back or forward just 1 step (in front of the next thing in front of it, so on and so forth, like Lix has) Idk if this is covered in the rules suggested but it's a very handy feature.

[namida]

No such function currently (if it's a single piece, you can simply increase or decrease the Index property by one).

I could implement one, but the question arises of how to handle situations where multiple pieces are selected. I can see two possible answers here:

1. Reorder the pieces so that all selected pieces (of the same type) have consecutive indexes, while still being in the same order relative to each other (but not nessecerially relative to other pieces). Then move them all back (or forwards) one as a group from this position.
2. Simply increase or decrease every selected piece's index by 1.

#1 kind of feels like a case of the software trying to be smarter than the user, but I don't know if that might be expected in this case.

EDIT: Or a third - simply don't allow this function when more than one piece is selected.

[namida]

Are you still interested in this feature (or is anyone else interested in it)? If so, which of the behaviours from the above post would you expect (or something else)?

[Proxima]

Disclaimer: I haven't seriously used the NL editor since making "Brute Fours" back in the very first forum contest. Still, I'm interested in making a pack at some point in the future, and I have enough experience of Lix editing to have some ideas about what features are desirable.

Rather than increasing or decreasing the index by 1, I would expect "move forward / back" buttons, with a single piece selected, to jump the index over all overlapping pieces. For instance, suppose you have five terrain pieces and piece 1 overlaps pieces 3 and 5, with pieces 2 and 4 elsewhere, one click would jump it behind piece 3 (new order is 2-3-1-4-5) and another click would jump it behind piece 5. The reason is that you may have hundreds of terrain pieces in a level, and you may work on part of the level and then come back and add a new piece to an earlier part, and then want to reorder it among the pieces it overlaps. You never want to reorder it relative to pieces it doesn't overlap (since this doesn't have the slightest effect on the level's appearance), and you almost never want to reorder it before you've decided where it goes, since that just sets you up for having to do more work once you've made a decision.

If multiple pieces are selected, then, they should retain their relative order, while jumping over one overlapping piece at a time. For instance, suppose you have seven terrain pieces, and pieces 1, 3, 5, 7 mutually overlap. The user selects pieces 1 and 5 and clicks "move back". I would expect the new order to be 2-3-1-4-5-6-7: piece 1 jumps behind piece 3, piece 5 is already behind 3 and so doesn't move. Another click of "move back" would create the order 2-3-4-6-7-1-5.

[Simon]

Yes, Proxima's example is good, provided that none of 2, 4, 6, 8 overlap any of 1, 3, 5, 7.

To move back a selection: Among all non-selected tiles that overlap the selection, that are not entirely behind the selection, consider the hindmost. Move this considered tile in front of the entire selection. (If you can't consider such a tile because there are none such, then do nothing.)

The D Lix code is more elaborate, I forgot if the code is needlessly convoluted or covers extra cases. It has a loop still, it's not 100 % map-filter-takeOne. >_>;

-- Simon