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/