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

[Simon]

Hi folks,

Lix version 2015-09-01 is out, and 2015-09-02 fixes a little, but urgent multiplayer bug (flickering button). There are no physics changes. Replays and netplay are compatible with 2015-08-09.

Download Lix.
View the changelist.
Report a bug.

Main points from the changelist:

• Tileset: NaOH has released the forest tileset. It's an amazing piece of art. Thanks for pushing it it towards this release. Screenshot is below.
  
• Levels: Rubix has released new singleplayer levels, and has fixed some older singleplayer levels.
  
• Framestepping: You can go back and forth individual frames in singleplayer. Precise, convenient timing controls and instant error recovery are expected of a modern engine. NeoLemmix has offered framestepping for a long while already. Implementing it in Lix was overdue.
  
• Several bugfixes.
  

Hotkey collisions: With the introduction of framestepping, there are three new mappable hotkeys. If you have any hotkeys on numbers 1, 2, 3, 4, 5, 6, please check the ingame hotkeys in the options menu for possible collisions.

Screenshot of the forest tileset:



Framestepping buttons in the new version:



Fast-forward (>>) and turbo-fast-forward (>>>) remain both available. They have two different hotkeys, but only one on-screen button. Left clicks trigger fast-forward, right clicks trigger turbo-fast-forward.

Framestepping buttons, both forward and backward, skip by 1 frame upon left click, and by 1 second upon right click. Each has 2 hotkeys. You can hold the left mouse button, or hotkey, to invoke the function continuously after half a second.

Likewise, left-clicking the spawn interval modifies it by 1 point, right-clicking it sets it to the extreme. Double left-clicks modify it by 2 points, as it should. If you hold the left button, the spawn interval will change faster after half a second.

-- Simon

[RubiX]

Its great!

[NaOH]

Excellent update! This is my first time seeing the new animations too. They're amazing! I love the purple swirly black hole imploder and the pogo stick digger and everything. The lix carefully planting her shovel and then carefreely swooping the dirt away is really cute.

Some thoughts:

• I was surprised again by it defaulting to fullscreen. I feel Lix, being a free, 2d indie game not supported on steam, should be humble and default to windowed mode. People will be skeptical already downloading anything from asdfasdf.ethz.ch, and something that takes over the screen is quite scary.
• fullscreen resolution in options should default to 0,0 with preserved aspect ratio.
• the imploder animation doesn't work quite right in frameskip mode
• Knockback exploder should be the default ploder in the editor. More mp maps will use ploders than sp, I think, and of the sp maps that do, many may use exploders instead of imploders, whereas few mp maps will use imploders over exploders.

[RubiX]

We will have a real domain for it one day , when Lix runs A5 I would highly expect.
Or a quick WIX site would be decent.

[Simon]

Excellent update! This is my first time seeing the new animations too. They're amazing! I love the purple swirly black hole imploder and the pogo stick digger and everything. The lix carefully planting her shovel and then carefreely swooping the dirt away is really cute.

Happy happy happy, thanks!

I was surprised again by it defaulting to fullscreen. I feel Lix, being a free, 2d indie game not supported on steam, should be humble and default to windowed mode. People will be skeptical already downloading anything from asdfasdf.ethz.ch, and something that takes over the screen is quite scary.

I don't have a strong preference for fullscreen, and that's a reasonable argument to start windowed per default. The A4 version can toggle fullscreen during program run anyway.

fullscreen resolution in options should default to 0,0 with preserved aspect ratio.

Agree. It runs at less than 60 FPS for me with 0x0 and faster with 640x480, but most people won't experience such a slowdown.

the imploder animation doesn't work quite right in frameskip mode

Will examine.

Knockback exploder should be the default ploder in the editor. More mp maps will use ploders than sp, I think, and of the sp maps that do, many may use exploders instead of imploders, whereas few mp maps will use imploders over exploders.

I feel the same. This dialog needs some more attention anyway: The button for classical skills is much more prominent than the button for setting all skills; they should switch places.

We will have a real domain for it one day , when Lix runs A5 I would highly expect.

I've already rented a virtual private server. I want to install a webserver there in the next weeks, and eventually move the Lix site over. Registering a domain is around 10 dollars per year, that shouldn't be a problem.

-- Simon

[Proxima]

Initial startup gave me the same problems as previous versions. But after I set it to windowed mode, no more problems so I'm back in the game!

Right-clicking fast forward when already in normal FF ends FF, instead of starting turbo-FF.

Good to have separate mouse controls for adjusting SI and instant min/max. Now we just need a hotkey for instant min/max.

After reading all hints, "+/-" buttons are replaced by highlighted "?" but this displays penultimate hint again, rather than hiding hints as one would expect. To hide hints after reading them, one has to "-" back through them, which is hardly intuitive. Also, restarting a level should hide hints.

I can't find anywhere that names of skills are displayed any more. New players need to know the names to understand hints.

Hint for "Any Way You Want" may need changing in view of instant bombers?

[ccexplore]

I was surprised again by it defaulting to fullscreen. I feel Lix, being a free, 2d indie game not supported on steam, should be humble and default to windowed mode. People will be skeptical already downloading anything from asdfasdf.ethz.ch, and something that takes over the screen is quite scary.

Many games are fullscreen that aren't on Steam.  While I personally play Lix windowed most of the time, I feel the specific arguments presented here is rather a bit backhanded, when ultimately it comes down to personal preferences.  The scariest software from the Internet aren't the ones that look scary anyway, it's the ones that pretend to look like something legitimate but aren't.

That said, based on approaches I've seen in other games, one possibility you can consider is that for first-time startup of the game, start in windowed mode but very quickly (perhaps even the very first screen) ask user to select fullscreen or windowed mode.  Then transition to the selected mode and continue with the rest of first-time startup sequence.  I think that could be a reasonable compromise, though some testing may be warranted to ensure transitioning from windowed to fullscreen works properly across varying hardware configurations.

fullscreen resolution in options should default to 0,0 with preserved aspect ratio.

Agree. It runs at less than 60 FPS for me with 0x0 and faster with 640x480, but most people won't experience such a slowdown.

I think based on descriptions of current A4 implementation, it is likely always faster on 640x480, just a matter of whether it is noticeably so or not.  I think the more salient issue is that whenever the monitor's aspect ratio is not exactly 4:3 (eg. widescreen), then most display drivers will stretch the 640x480 to fill the display and therefore breaks aspect ratio.

That's a compelling reason to default to 0x0+preserved aspect ratio.  On the other hand, due to the way that is currently implemented, you either use integer-only scaling and the game's display might not fill up the screen as fully as it would with 640x480, or you use non-integer scaling and things don't look quite right.

I guess on balance, 0x0+preserved aspect ratio still seems like the safest choice for most, but there are definitely tradeoffs amongst all the choices.

[namida]

Sounds excellent! The lack of frame-step features was probably my biggest issue with SP Lix.

[Simon]

Right-clicking fast forward when already in normal FF ends FF, instead of starting turbo-FF.

I thought about both ways and chose this (back to normal speed), but I'm unsure about what's better.

The alternative (ffwd -> turbo) the problem that the user must remember what ffwd mode is active, and when cancelling ffwd is important, it should not matter. They should be able to hit any ffwd button to cancel.

The counter-argument is that the user would cancel ffwd with pause in this case anyway.

With 1 button/key for each non-normal speed, there is no stateless implementation, except for going over pause (hit pause, then ffwd, and you will end up in ffwd mode guaranteed, no matter where you came from) or requiring 2 presses in general for a particular function.

Good to have separate mouse controls for adjusting SI and instant min/max. Now we just need a hotkey for instant min/max.

I can make keys if the need is there; I'm merely getting worried about the ton of different keys.

After reading all hints, "+/-" buttons are replaced by highlighted "?" but this displays penultimate hint again, rather than hiding hints as one would expect. To hide hints after reading them, one has to "-" back through them, which is hardly intuitive. Also, restarting a level should hide hints.

Agree on restarting. Hiding hints makes this button a universal reset button, something everybody likes.

Browsing after the last hint: The current hint interface is bad in the first place, and should be redone thoroughly. It stems from lack of panel space.

[14:17] <SimonN> Ramond: no zoom button: this is an older design issue in Lix; the panel space is so crowded that I resorted on having either zoom or hints in the panel. When the zoom button is hidden, its hotkey doesn't do anything either

This design issue needs some more attention. Hints are getting more love these days than months ago.

I can't find anywhere that names of skills are displayed any more. New players need to know the names to understand hints.

They appear when hovering over a working lix. Enough or too little?

Hint for "Any Way You Want" may need changing in view of instant bombers?

Agree. It's an issue for the pack, not for the game. Reword the hint and post the updated file in the pack thread, or wait until geoo resolves/delegates this.


geoo and Proxima have suggested frameskip-ahead-by-right-click should skip 10 seconds, not 1 second. Reasonings:

• There was no good reason for 1 second other than symmetry with the value on framestep-back-rightclick.
• User can wait 1 second easily by normal speed anyway.
• Skipping large amounts of time is easier and faster with repeated 10-second-skips than with ffwd/turbo. Also more precise if you know the exact time at which interesting stuff will happen.
• Lemmix/NeoLemmix have this. The main reason there is chaining builders, which you don't have to do in Lix, where you can queue instead. Nonetheless, 10 seconds seem useful for more than only chaining builders. You can judge how much it is.

I'm slightly reluctant to make the value user-settable, unless people demand it. Lix doesn't have about:config. >_>

-- Simon

[Simon]

Version 2015-09-02 has been released. It's a minor update, no physics.

Download Lix

Compared with 2015-09-01, there are some bugfixes, and a new hatch by geoo -- see the changelist. There was a flickering framestepping button in multiplayer, which should not have been there; this is fixed now.

-- Simon

[NaOH]

Right-clicking fast forward when already in normal FF ends FF, instead of starting turbo-FF.

I thought about both ways and chose this (back to normal speed), but I'm unsure about what's better.

The alternative (ffwd -> turbo) the problem that the user must remember what ffwd mode is active, and when cancelling ffwd is important, it should not matter. They should be able to hit any ffwd button to cancel.

The counter-argument is that the user would cancel ffwd with pause in this case anyway.

With 1 button/key for each non-normal speed, there is no stateless implementation, except for going over pause (hit pause, then ffwd, and you will end up in ffwd mode guaranteed, no matter where you came from) or requiring 2 presses in general for a particular function.

I don't have a particularly strong opinion, but here's my concern about changing the behaviour: if the turbo button is down, it should be as easy as possible to stop turbo mode. In particular, looking at the turbo button down, it would make sense that clicking on it should deactivate it. If clicking on the depressed turbo button enabled ffwd mode, instead of deactivating turbo mode as intended, this could easily cause the player to panic.

My normal way of using turbo mode is: leave it on until I'm anywhere near the state I want, then resume normal speed (or pause) until I can get my bearings. The button is so sensitive, I doubt I'd ever want to switch turbo->ffwd directly; it would be more convenient to pause first, then ffwd (turbo->pause->ffwd).

TL;DR: in turbo mode, both right and left click on the button should resume normal speed.

On the other hand, it might make sense to want to speed up ffwd->turbo with a single click, if one tentatively enables ffwd mode and then becomes impatient.

So (and this is clearly confusing behaviour), maybe the best would be this set of interactions:

normal speed, left  click   ->   ffwd
normal speed, right click   ->   turbo
ffwd  mode  , left  click   ->   normal speed
ffwd  mode  , right click   ->   turbo
turbo mode  , left  click   ->   normal speed
turbo mode  , right click   ->   normal speed

I can't find anywhere that names of skills are displayed any more. New players need to know the names to understand hints.

They appear when hovering over a working lix. Enough or too little?

Maybe they should appear when hovering over the panel icon? Some skills, like ploders, will never be seen when hovering over a lix, and the imploder/exploder name distinction is very important.

[Proxima]

TL;DR: in turbo mode, both right and left click on the button should resume normal speed.

On the other hand, it might make sense to want to speed up ffwd->turbo with a single click, if one tentatively enables ffwd mode and then becomes impatient.

So (and this is clearly confusing behaviour), maybe the best would be this set of interactions:

I would support this, in spite of the asymmetry. I have never felt a need for the ability to move from turbo to FF -- the only reason to come out of turbo is to assign skills with greater precision than turbo allows, and for this you want normal or framestep. But FF->turbo is frequent.

Maybe they [skill names] should appear when hovering over the panel icon? Some skills, like ploders, will never be seen when hovering over a lix, and the imploder/exploder name distinction is very important.

Yes, I think that's a good idea (of course, only if the user has the "show tooltips" option on).

Talking of skill names, am I correct that "bomber" is now deprecated as a name for the imploder and should be replaced in all hints? I won't change the hint for Any Way You Want myself as it's not my level, but I'm going to rewrite the hints for my own levels as soon as I have time.

[Simon]

Assymetric behavior for ffwd button: This seems good, let's do it. I've noticed how I sometimes hit the hotkey for turbo while ffwd is active, wanting turbo explicitly. NaOH's and Proxima's reasoning is good for the proposal.

Show skills in panel: When hovering over a skill button with the mouse, let's show the name of the skill where we'd also display what lixes the cursor is hovering over. That's reasonable and consistent. I will disable this when tooltips are disabled, even though it doesn't obscure any data, simply because it's a tooltip.

The alternative is to write full tooltips for each skill, à la "Climber: Will climb each encountered wall. Hotkey: [...]", these obscure data in the panel, and also disable these with disabled tooltips. But I'd lean towards the first solution.

-- Simon

[ccexplore]

Maybe it's just me, but looking at the screenshot of NaOH's forest tileset, everything looks excellent but the textures on the gray rocks I don't feel as great about.  Feels like they could use either more finely gradient shades of gray and/or more dithering to better match the texture styles seen in other graphics of the tileset like the tree trucks.  Then again maybe it's a style thing that I'm unfamiliar with, maybe rocks are usually painted just like that in oil paintings (which I mention as some of the graphics like the tree leaves strongly evokes that for me, in a good way).

[NaOH]

Maybe it's just me, but looking at the screenshot of NaOH's forest tileset, everything looks excellent but the textures on the gray rocks I don't feel as great about.  Feels like they could use either more finely gradient shades of gray and/or more dithering to better match the texture styles seen in other graphics of the tileset like the tree trucks.  Then again maybe it's a style thing that I'm unfamiliar with, maybe rocks are usually painted just like that in oil paintings (which I mention as some of the graphics like the tree leaves strongly evokes that for me, in a good way).

Yeah, I do see what you mean, I remember you commented about that a long time ago. I feel like the problem is that the shading is delineated too neatly into islands of dark and islands of bright.

Also Simon, please host the screenshot in etc/

[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?