Version 2015-09-01 released (now: 2015-09-02)

[ccexplore]

Sorry to bump this topic but not sure where else to put this.  I realize one or more of what I listed below may have already been raised in the past, but anyway:

* I could be mistaken, but it seems that replays currently are always saved with a copy of the level embedded, and will play back using strictly the embedded level.  I'm wondering if it's possible to either:
  - expose in the game itself an option to either save a replay w/o the embedded level; or
  - allow a replay to be loaded ignoring the embedded level; or
  - to take an existing replay file and strip the embedded level

The primary use case is testing replays made for an older version of level against a newer version, as can be common when editing a level for backroute elimination.  Even if the full solution of the replay won't work against the newer version, beginning portions of it still might, and maybe they are the portions that I'd rather have the replay execute for me instead of manually myself (especially if the replay came from someone else).  I've currently resorted to editing the replay file in a text editor to achieve this.

* It seems a little odd that that while playing a level, you can save replays but can't load one, you'd have to quit all the way back to the main menu to get to the option to browse replays.  While the savestate feature helps minimize the need to load replays, the fact that there's just one savestate slot suggests to me that loading replays while playing a level may still be valuable.

If it were to be implemented, I imagine it would just bring up the same UI as the replay browser from the main menu, except perhaps filter the file list to only the replays that match the current level by filepath, game version and level version.  Potentially with an option checkbox to relax the filtering to show all replays.  Also, replays would be loaded ignoring any embedded level data, since in this context there is already a level loaded.

* While I understand all keys can be remapped, I think the default setup of hotkeys should strive to be newbie friendly.  That is, newbies probably won't figure out right away about remappable keys, but do likely come with preconceived expectations of how certain keys would behave based on near-universal behavior across other applications.   And currently I'm unsure about some of those defaults in Lix:
  - The move left/right/up/down for the editor is not mapped to the arrow keys?  Really?  Let's consider that a newbie would probably try the arrow keys as the first thing for moving selected level elements via keyboard (likely for the purpose of finer control over placement than mouse drag-drop).  If there are good reasons to avoid defaulting to arrow keys, then at least display what the currently mapped keys are for movement (ie. on the line where it displays the filename, position and size of the selected element).  It's still not too newbie friendly though, I think.

On that note, delete for editor mapping to delete key seems like the obvious default.  But I think that's less important since unlike the finer positioning with moving selected items via keyboard, using the keyboard instead of mouse for "delete" doesn't seem to offer any such significant advantages.

  - I feel a newbie is more likely to try "P" or "Pause/Break" than Spacebar key for pausing.  Granted, a true newbie will probably just stick to mouse-clicking the paws anyway, and by the time they started using the keyboard in earnest, hopefully they've already learned to remap the keys.

* This doesn't actually bother me at all due to my background, and it seems no one here ever got tripped up by this, but I just realize that the ".." notation in the level/replay browser is actually rather technical and perhaps not obvious to newbie users.  The saving grace is that since nothing else in the UI suggests the functionality of "up to parent directory", hopefully the user will just try the mystery ".." button sooner or later and quickly figure out what it does.  So it's probably not much of a problem, though perhaps showing "(up)" or "(back)" instead  of ".." is slightly better for newbies?

[ccexplore]

Slightly more on topic:  will the confetti animation for imploder be updated at some point?  If we plan to call it the imploder, it doesn't really make sense that the confetti is still moving radially outwards implying an explosion.  It would at least create better distinction with the flinging exploder to have different confetti movements.  I'm fine with no confetti at all or some alternate non-confetti animation if inwardly moving confetti ends up looking too strange or something.

[geoo]

* I could be mistaken, but it seems that replays currently are always saved with a copy of the level embedded, and will play back using strictly the embedded level.  I'm wondering if it's possible to either:
  - expose in the game itself an option to either save a replay w/o the embedded level; or
  - allow a replay to be loaded ignoring the embedded level; or
  - to take an existing replay file and strip the embedded level

I've ran into this precise issue myself. Simon wasn't sure if there was sufficient demand to warrant the additional UI clutter that comes with two buttons (one for included and one for pointed to replay). As I use this functionality myself, I compiled a private version that allows using the pointed to replay with a special key combination. Though maybe right-clicking the button could use the pointed-to level without any new buttons?
I think it is desirable not having to strip the level from the replay as in many cases you still want to be able to view the replay with the included level (in your specific use case, this is helpful if the pointed-to level solution breaks very early but the solution is involved and you can't remember it in full).
Note that you can verify if the solution still works in the pointed-to level using the replay verifier which always uses the pointed-to level, but you cannot view the solution.

* It seems a little odd that that while playing a level, you can save replays but can't load one, you'd have to quit all the way back to the main menu to get to the option to browse replays.  While the savestate feature helps minimize the need to load replays, the fact that there's just one savestate slot suggests to me that loading replays while playing a level may still be valuable.

I think this might be a feature request for the D port. Not sure if having a database with the level hashes is still on the table, but having the browser by default show precisely all the relevant replays of the level is probably a good idea.

[Editor hotkeys]

The rationale here is to shove the user with their nose into using an efficient key layout that doesn't require moving your hand around all the time. This is even moreso the case in playing mode as there it's essential for multiplayer.
It's worth testing with new users how they would react.
I think moving things around with arrow keys and deleting with Delete is an association that's a lot stronger than P for pause, and coupled with the lower need for an efficient layout in the editor it's probably sensible defaulting to the arrow keys.

  - I feel a newbie is more likely to try "P" or "Pause/Break" than Spacebar key for pausing.  Granted, a true newbie will probably just stick to mouse-clicking the paws anyway, and by the time they started using the keyboard in earnest, hopefully they've already learned to remap the keys.

Not sure about this one, how prevalent is P for pause in puzzle games? Would need some user testing too.
Though here I feel the case for having an efficient key layout is a lot stronger than in the editor, and the most important functionality on some random letter key rather than the biggest key on the keyboard is just inconvenient, even if you don't use hotkeys very much yet.

* This doesn't actually bother me at all due to my background, and it seems no one here ever got tripped up by this, but I just realize that the ".." notation in the level/replay browser is actually rather technical and perhaps not obvious to newbie users.  The saving grace is that since nothing else in the UI suggests the functionality of "up to parent directory", hopefully the user will just try the mystery ".." button sooner or later and quickly figure out what it does.  So it's probably not much of a problem, though perhaps showing "(up)" or "(back)" instead  of ".." is slightly better for newbies?

Seems sensible. Again worth testing with new users.

Slightly more on topic:  will the confetti animation for imploder be updated at some point?  If we plan to call it the imploder, it doesn't really make sense that the confetti is still moving radially outwards implying an explosion.  It would at least create better distinction with the flinging exploder to have different confetti movements.  I'm fine with no confetti at all or some alternate non-confetti animation if inwardly moving confetti ends up looking too strange or something.

This one slipped under the radar. This was meant to be done at some point. Also the imploder animation is a quick WIP that still needs to be cleaned up.

[ccexplore]

[Editor hotkeys]

The rationale here is to shove the user with their nose into using an efficient key layout that doesn't require moving your hand around all the time. This is even moreso the case in playing mode as there it's essential for multiplayer.
It's worth testing with new users how they would react.
I think moving things around with arrow keys and deleting with Delete is an association that's a lot stronger than P for pause, and coupled with the lower need for an efficient layout in the editor it's probably sensible defaulting to the arrow keys.

I think I'm less concerned with the hotkeys for level-playing.  With maybe a few exceptions, most will be so lix-specific that, other than historical precedence like Lemmings (which in past discussions we've agreed has its flaws anyway), there will likely be no obvious hotkeys a player might expect on the outset anyway.  And as I noted, the newbie will probably do fine sticking with mouse only for a while.  I agree that efficient layout is preferable in the long run for the level-playing hotkeys.

Many of the editor functions are also lix-specific, but a few aren't and the default hotkeys for those should probably try to be more consistent with other programs.  For most editor functions it is also possible to argue that the mouse will serve the newbie almost equally well, so the default hotkey mappings for them may not matter too much.  Using keyboard for moving selected items though seem to be the one case where there's good reason to use the keyboard over mouse in some cases.  An unobvious default key mapping could mislead a newbie into thinking keyboard support for moving selected items is missing altogether, while an obvious mapping could increase the chance of a newbie discovering them on their own well before they learn where to find and remap keys.

For context, the reason I brought this up is because I haven't used Lix in a long while, and was setting it up on a new computer w/o carrying over the config files from an existing older copy of Lix from an old computer.  Starting fresh like that, I quickly ran into a couple of cases where keys I'm very used to were in fact apparently my own remapping, though keep in mind I remapped them in the first place only when the defaults did not work for me, and generally I had been leaving most mappings at the defaults.  So yes, admittedly some of this may reflect my own preference more than anything else.  I think the overall idea is still worth considering though: that outside of the hotkeys for level-playing, having some of the defaults more consistent with "rest of world" will be more helpful to many users.

You're quite right to point out that most of us here (me included) have been using Lix far too long to qualify for "new user".  It would be better to observe a few actual new user at some point and see what happens.

[ccexplore]

Sorry for double-post, forgot to comment on these:

I think it is desirable not having to strip the level from the replay

Agreed, most of the time having the embedded level be used is preferable.  I'd just like the option from time to time of untying the replay from the embedded level.  It's something that can certainly wait for the D port.

* It seems a little odd that that while playing a level, you can save replays but can't load one, you'd have to quit all the way back to the main menu to get to the option to browse replays.  While the savestate feature helps minimize the need to load replays, the fact that there's just one savestate slot suggests to me that loading replays while playing a level may still be valuable.

I think this might be a feature request for the D port. Not sure if having a database with the level hashes is still on the table, but having the browser by default show precisely all the relevant replays of the level is probably a good idea.

I'm under the impression that since the replay already remembers the level filepath, level version, and game versions, that is probably good enough compared to full level hashes in most cases for filtering replays like I suggested, even if in theory you can end up listing a replay file that does not fully match the level being played.  And perhaps ultimately what I'm really asking for there is less about loading replays and more about additional slots for the quick savestate/loadstate feature.  Or is that something that already exists and I'm unable to discover on my own from the UI?