I think since Lix 0.9.22 a 64bit version is provided for Win Lix and is recommended over the 32bit version. This was a meassure to prevent the game from crashing on huge maps, which was mainly a problem in Multiplayer.
The 32bit version is nevertheless still provided for people who can't use 64bit binaries, that have very old systems.


Is there still someone who uses or has to use the 32bit (Win) version of the game?

I just now realized that the option exists to not have the hotkey names shown on the buttons. I'm now too used to it to turn it off. But I'm curious if other people play with pure buttons without hotkey names on the right lower side of the button.

Recently I came across two games that are Lemmings-like:

• Rabbit Escape by Andy Balaam (generally free and open source, GPL v2)
  
• Snails by Jorge Lima, Alexandre Fontoura, published by 2Brains Games (commercial)

Rabbit Escape is a cute simple game in pencil drawing style. It's block based and at least the PC version is Java. You place the skills to be picked up in the world instead of direct assigning. The skills circles have physics as well. The UI looks very basic and there seems to be no frame stepping. There seems to be a good amount of levels as well, which are in an unlock system. I haven't played much though. It looks as if it can get fiddly/dexterity based.

I haven't played Snails, yet, but only seen footage. You seem to mainly place items which interact with the snails. The snails generally stick to the blocks like a magnobooter. There seem to be different game modes, one of which even includes killing the snails instead of saving. At the moment there seem to be 84 levels available.

There seems to be an issue with a macOS build. From the descriptions of macOS users:

It starts and opens a window, but which has only a black screen. The music plays and at least with ldc it segfaults.

Issue 381 on github

From the #lix log of 4th of Jan, 2019 (concerning Lix 0.9.24):

[11:24:47]    <tarzeau> i've got an up to date 10.14 mojave mac now... i shall retry?
[11:24:55]    <tarzeau> remember what i need to install with brew?
[11:25:55]    <SimonN> brew install ldc dub allegro enet
[...]
[11:30:09]    <tarzeau> uncaught exception when i run ./bin/lix but that's surely the releaseXDG
[11:30:27]    <tarzeau> rebuilding...
[11:31:19]    <tarzeau> now i get a window called Lix, which shows black, nothing else
[11:31:59]    <tarzeau> adding --build=release as in windows
[11:32:04]    <SimonN> what is your exact build command?
[11:32:20]    <tarzeau> now it's: HOME=. dub build --build=release -f --compiler=ldc2
[11:33:07]    <tarzeau> oh wow now ./bin/lix goes fullscreen
[11:33:10]    <tarzeau> staying black
[11:33:21]    <tarzeau> pressing esc: segmentation fault
[11:33:23]    <SimonN> yeah, release defaults to fullscreen
[11:34:03]    <SimonN> go into the segfault with a debugger
[...]
[11:52:11]    <SimonN> tarzeau: When you build Lix, dub outputs versions of other dub packages. What version is "allegro" in that output?
[11:54:08]    <tarzeau> allegro 4.0.4+5.2.0: building config "no-libs"
[11:54:15]    <tarzeau> maybe i should not have copied that dub packages from linux?
[11:54:47]    <SimonN> hmm, 4.0.4+5.2.0 is correct version.
[11:55:34]    * tarzeau drops HOME=. and rebuilds, removed all the *-n/ dirs too
[11:55:40]    <SimonN> Copying stuff from Linux: dub stores built binaries in .dub dir, thus the copying could cause problems. Delete ~/.dub/ and (lix)/.dub and then build.
[11:56:14]    <tarzeau> i've not taken any binaries, just the sources
[11:56:21]    <tarzeau> but will try as well...
[11:56:28]    <SimonN> ah, hm, then should work. But try anyway.
[11:57:17]    <tarzeau> all black... maybe it doesn't find data files?
[11:58:02]    <tarzeau> oh user/log.txt says
[11:58:06]    <SimonN> in dub.json, in "libs": [ ... ], between these square brackets, add this line including quotes and comma: "allegro_color",
[...]
[11:59:17]    <tarzeau> added and rebuilding...
[12:12:51]    <tarzeau> i can't find ~/.dub on macOS but i removed .dub
[12:13:06]    <SimonN> okay, hmm, I'm sure it'll be fine
[12:13:15]    <SimonN> did the rebuild do any good?
[12:15:33]    <tarzeau> but the icon appears when starting it
[12:15:36]    <tarzeau> in the dock
[12:15:43]    <tarzeau> black screen as always
[12:16:35]    <SimonN> okay. Remove `"allegro_color",` again, then `brew install dmd`, then build Lix with `--compiler=dmd`
[12:21:45]    <tarzeau> building...
[12:22:42]    <tarzeau> it also builds fine, however same black window
[12:22:54]    <tarzeau> i run ./bin/lix from the source unpacked tree
[12:23:13]    <tarzeau> however esc just exits, no segfaults
[...]
[12:56:37]    <SimonN> tarzeau: download the music: http://www.lixgame.com/dow/lix-music.zip -- extract in Lix's directory, then run the game again. Does music play during the black screen?
[13:02:25]    <tarzeau> back, i already have the music there
[13:02:31]    <tarzeau> let me make louder
[13:02:49]    <tarzeau> yep music plays
[13:06:41]    <SimonN> okay, hmmm, this is tricky then. Lix runs but doesn't display anything.
[13:08:02]    <tarzeau> ack
[13:08:06]    <tarzeau> do you use opengl?
[13:08:45]    <SimonN> Not directly. Via Allegro 5.
[13:09:43]    <SimonN> Okay, I have one abstruse idea.
[13:10:12]    <SimonN> Downgrade DAllegro5 bindings and add allegro_color back. I will instruct you how to do this.
[13:10:35]    <tarzeau> k
[13:11:51]    <SimonN> dub.json, line 13: Replace with: "allegro": "==4.0.3",
[13:12:28]    <SimonN> in line 21 or so, add new line: "allegro_color",
[13:12:40]    <SimonN> (all these times, the trailing commas are important)
[13:13:03]    <tarzeau> done
[13:13:14]    <SimonN> in dub.selection.json, replace line 4 with: "allegro": "4.0.3+5.2.0",
[13:13:34]    <tarzeau> done
[13:13:34]    <SimonN> then run: dub build --force --compiler=dmd
[13:13:47]    <tarzeau> running
[13:14:20]    <tarzeau> built, runs the same
[13:14:33]    <tarzeau> and it's the same windowed or fullscreen
[13:14:37]    <SimonN> i.e., black screen, music plays, and no image? hmm.
[13:14:42]    <tarzeau> yes
[13:14:46]    <SimonN> Okay, then I'm out of ideas
[13:15:22]    <tarzeau> https://www.google.ch/search?q=allegro5+macos+black+screen&oq=allegro5+macos+black+screen&aqs=chrome..69i57.5323j0j7&client=ubuntu&sourceid=chrome&ie=UTF-8
[13:15:23]    <SimonN> I didn't believe this would have helped anyway, but I would have slapped myself had it been the solution and had I not tried it.
[...]
[13:16:34]    <tarzeau> https://wiki.allegro.cc/index.php?title=Allegro_5_Tutorial/Displays ?
[13:16:49]    <tarzeau> al_flip_display(); needed?
[13:17:06]    <SimonN> yes, should be needed.
[13:17:07]    <tarzeau> i remember macOS (well cocoa) has different coordinate system
[13:17:25]    <SimonN> Allegro is an abstaction over any OS-specific stuff.
[13:17:48]    <SimonN> maybe run that example code and see if you get window
[13:17:51]    <tarzeau> https://github.com/liballeg/allegro5/issues/546
[13:18:00]    <tarzeau> single buffer?
[13:18:11]    <tarzeau> i don't know either. if you want me to retry, tell me
[13:18:47]    <tarzeau> this gh issue produces black display, works windows + linux
[13:20:10]    <SimonN> okay, no time. I think I double-buffer. My code is in src/hardware/display.d, public interface to that module is ALLEGRO_DISPLAY* display to get backbuffer to draw there, then void flip_display()

When testing freshly build levels you have to save, go out of the editor and play the build level, which is rather tedious.
Furthermore with normal play all your solutions during testing get auto saved by default what e.g. Ramond finds annoying since it can clutter your replay folder.

Therefore a test play mode from inside the editor seems to be a reasonable feature.

(Corresponding discussion from IRC:
[17:10:03]    <Ramond__> one other thing maybe, while testing your own level the game will auto-save each of your successful attempts, it will clutter after a while
[...]
[18:25:10]    <Forestidia> The auto save feature is important.
[18:25:24]    <Forestidia> It can be turned off I think.
[18:26:14]    <Ramond__> yeah it is important for playing, but rather hindering during level testing
[18:26:33]    <Forestidia> But what is your suggestion?
[18:27:06]    <Ramond__> I don't really have any proper suggestion, it only felt a bit annoying to having to clean out the replays manually
[18:27:15]    <Ramond__> maybe someone else has a good idea
[18:27:16]    <Forestidia> okay
[18:27:44]    <Forestidia> You can Esc the level before you hit the save requirement.
[18:27:58]    <Forestidia> I often do that when testing.
[18:29:02]    <Ramond__> that's a possibility but still a slightly tedious workaround (always having to have that in mind)
[18:29:27]    <Forestidia> The thing is to have a replay for the final version is important for coverage.
[18:30:08]    <Ramond__> dunno if feasible but what if there's a way to directly go into a 'test play' mode from the editor (skipping going back to menu to select play) which is identical to the normal play mode except it won't auto-save? (can still be saved manually somehow)
[18:30:49]    <Forestidia> A test-play mode from inside the editor would be good for other reasons as well.
[18:31:28]    <Forestidia> Since it's then generally less tedious to test your level.
[18:31:44]    <Ramond__> yes
[18:31:51]    <Ramond__> though for some reason I thought it was intentionally left out
[18:32:14]    <Forestidia> I don't think so actually.
[18:32:27]    <Forestidia> But I don't know for sure.)

I'm not really into complex level designing, but I'm mainly interested in trick showcase levels.

The attached level is meant to enforce one particular trick but I'm not fully sure if it does.

Just some tile groups I've built together (with current existing tiles). tiles.zip contains the level files with the tile groups. tilespics.zip contains the pictures of these groups for reference.

Description how to integrate tile groups in other levels.

Most of the tile groups are recreations of Simon's culled tiles. bridgetiles are recreations of Matt's old oriental bridge tiles.

I just wanted to collect two (known) builder edge cases that can lead to backroutes.

1. Turning around the crowd with two builders (and one blocker)
By stacking stairs you can block the crowd but usually you need three stairs for that.
But you can force the situation with two stairs as well.
For that you need a blocker. The builder turns at the blocker which can lead to copying or stacking of stairs so that you effectively have two stairs next to each other instead of one. So you can simulate having three stairs with just two.
I've created a replay to showcase this called "twostairsblock.txt" (level used is Any Way You Want; I freed the blocker in the end to show that you have indeed a blocking stair wall). It's rather precise to perfom when on flat surface. It could be very well easier to perform on slopes.
Even if you already have to use a blocker which blocks the crowd anyways this has use cases.
For example you can use stairs to cross a gap or catch the lix in a loop but after the route is built you want to free them of the loop or let them go into the gap.
(Theoretically you can make a blocking wall with one stair and two blockers but I don't see a good application case.)

2. Ramond's 2-builder cancelling (issue 268)
Two builder cancelling works in Lix and was found out by Ramond.
It has a very peculiar and precise setup since it depends on the distance between lix, especially when the second lix arrives at the first builder.
But there are ways to manipulate this distance. One of them is using the shrugger animation of the first builder if you have more than two stairs. The shrugger animation lasts multiple frames which lets you readjust the distance between first builder lix and second.
I've created a replay to showcase this called "twobuildcanc.txt" (level used is Any Way You Want).