Lix 0.10.34 released.

Download for Windows 64-bit -- recommended
Download for Windows 32-bit -- fallback for ancient machines
Download for Linux 64-bit
Source code
Changelog
Issue tracker

How to update

Quick and dirty: Extract over your old installation. Level moves will then result in duplicate levels that remain in your level tree.

Clean method: Extract to new directory, then copy these directories from old Lix into new Lix:
user/
replays/
...and any levels that you've built yourself or added manually.

• Edge scroll speed is now proportional to the screen/window size. The same setting will scroll by more pixels on a bigger screen/window.
  
• Remove the tooltip that told you how to use the hold-to-sroll feature. Before, every time you edge-scrolled, Lix would tell you how to scroll with the hold-to-scroll feature, e.g., with the right mouse button.
  
• In insert mode, when you're about to replace the future of a single lix, the top of the screen tells you how many future skills you replace.
  
• When you load a replay from disk or re-watch a completed level, you don't see "Replaying. Click to play from here." at the top of the screen. Instead, the mouse curser's sidekick icon has a little letter R. Once you click, the R turns into the regular scissors cursor, the top text appears, and the next click will cut the replay.
  
• When you tweak skill assignments, the sound for a replayed assignment will now always play, and the assignment arrow will always appear. Before, they would only appear when you tweaked an assignment to a target time to which it hadn't been tweaked before. When you tweaked an assignment back and forth, sound and arrow would be missing on the second time.
  
• Re-introduce the two options whether air clicks cut the replay. One option applies when the tweaker is open, the other when it isn't open. The default is: Air clicks always cut, both with or without the tweaker.
  
• Code: The internal replay data structure now carries the lix's tribe color with every assignment in addition to the assignment's player number. This denormalizes the internal replay data structure, but it makes several parts of the program more straightforward. The networking protocol still sends plies only with player numbers to stay compatible with all Lix versions 0.10.x. The replay file format still saves the assignments only with player numbers to stay identical to the existing format.
  

<SimonN> Now the most important problem. What animal will go in the thread.
<Mindless> It's gotta be a dinosaur this time.
<SimonN> Dinosaur because Lix has turned 20.
<Flopsy> Oh dear, the Jackbox joke will have to change now. It used to be "Lix, 10 years in development and no end in sight" usually accompanied by a skeleton lying in ruins as a picture.
<SimonN> I pin the first lines of L++ to April 1, 2006. Yeah, over 20 years and no end in sight. I've been doing this for half my life now.

-- Simon

Stream is over! Recording will remain for 14 days at:
https://www.twitch.tv/simonnaar

-- Simon

Stream starts in 2 hours.

I have a few minor Lix fixes ready for release. The stream will be a live test. Lix 0.10.34 will release this Saturday/Sunday.

-- Simon

Lix savestating/rewinding internals from today.
Golems savestating/rewinding by Mindless from 2024.

These backbones/algorithms are interesting regardless of how much power you'll eventually expose to the user.

---

RetroLemmini supports assignments during pause that keep it paused. You can also advance by 1 physics update and keep it paused, even without assigning a skill. This is already full control that removes all execution difficulty. Given full control, if you withhold precise rewinding even though you could offer it, you'll introduce artificial annoyance. That won't feel well.

The game design sets the entire stage. Execution difficulty yes or no during forward-only play? Timed bombers suggest yes, the existing control features say no.

The appropriate rewinding power follows from that and shouldn't be a standalone design decision.

-- Simon

I like it too!

Coherence is good: Things that go together are together, unrelated things are more apart. Important lines are green, secondary lines are blue.

Blue buttons, why not, looks reasonable and good.

Minor leftovers:

• How consistent are blue buttons with other screens? Does it even matter?
  
• What is good spacing between the preview picture and the title below it? Looks a little tight on Crystal Playtest in Will's most recent reply #21.
  

-- Simon

Hi,

here's how Lix implements performant rewinding and recomputation. This is the backbone of singleplayer rewinding. And during multiplayer, when an incoming packet had some lag, we can integrate it into the replay and recompute.

Automatic savestates:

• Right now, it's 10:00 UTC, 22nd of August, 2026.
  
• We remember 00:00 UTC, 22nd of August, 2026.
  
• We remember 00:00 UTC, 21st of August, 2026.
  
• We remember 00:00 UTC, 1st of August, 2026.
  
• We remember 00:00 UTC, 1st of July, 2026.
  
• We remember 00:00 UTC, 1st of January, 2026.
  
• We remember 00:00 UTC, 1st of January, 2025.
  
• We remember the creation of the universe.
  

How it stores:

• When the game loads, backup #1 into #8. That #8 will never be overwritten.
  
• Every midnight, we save #1 (the current world) to either #2 or #3.
  
• Even-odd rule: Even-numbered days will always be saved into #2, overwriting the previously saved even-numbered day. Odd-numbered days will always be saved into #3, overwriting the previous odd-numbered day.
  
• Every new month, we save #1 into #4 or #5, again with an even-odd rule.
  
• Every new year, we save #1 into #6 or #7.
  

I call the pair of #2 and #3 a "leapfrogging pair of savestates". Reason: The even-odd rule above means they'll leapfrog each other. Sometimes #2 is the newest and #3 is one day behind, sometimes #3 is the newest and #2 is one day behind. So far, it alternates nicely. When the user rewinds and replays, it's possible that we'll write to #2 several times in succession before we ever write to #3 again, because of how it's used for rewinding:

How it rewinds:

• To rewind, load the latest savestate that's not later than the rewinding target time, and recompute from there to the time.
  
• E.g., to rewind by a few hours, you might need load the savestate that's between 1 and 2 days old. Load it, and recompute. During this recomputation, we'll run over a midnight. We should save this! Because of the even-odd rule, this will overwrite the other savestate among #2/#3 from which we didn't load at the beginning of this rewinding.
  
• Even longer rewinds will load the savestate from last month. During recomputation, we'll cross several midnights, and we should re-save the world every time into #2 or #3.
  
• Very long rewinds recompute from a few years ago. Along the way, we'll re-save to #2/#3 and to #4/#5, possibly also to one of #6/#7.
  

What are good intervals for savestating? Days/months/years are only good for the example. The unit of time in Lix is the physics update, not days/months. Normal gameplay speed is 15 physics updates per second. This leads to the following leapfrogging resolution:

• The current world, age n.
  
• Every 10 physics updates, if n % 20 == 0.
  
• Every 10 physics updates, if n % 20 == 10.
  
• Every 60 physics updates, if n % 120 == 0.
  
• Every 60 physics updates, if n % 120 == 60.
  
• Every 360 physics updates, if n % 720 == 0.
  
• Every 360 physics updates, if n % 720 == 360.
  
• Every 2160 on non-huge levels, if n % 4320 == 0.
  
• Every 2160 on non-huge levels, if n % 4320 == 2160.
  
• Every 8640 on smaller levels, if n % 17280 == 0.
  
• Every 8640 on smaller levels, if n % 17280 == 8640.
  
• The beginning of the level.
  

n is the age of the world in physics updates.
% is modulo (computes remainder of division).

Reasoning for the value of 10 for the fastest pair:

• 10 physics updates take 0.666 seconds at normal speed. The fastest leapfrogging pair will offer two savestates between 0 and 1.333 seconds of real-time. That's slow enough for most networking lag, e.g., for bad lag around 0.5 seconds.
  
• For singleplayer, it's fast enough for the common single-frame rewinds. Most rewindings will recompute only a few physics updates. You can conduct 60 rewindings per second and display all outcomes to the user at 60 fps.
  

See My implementation on github. I've abstracted each pair into its own struct LeapfrogPair. The physics cache has 5 leapfrogging pairs, and each pair maintains two savestates ("frogs").

To save VRAM on huge maps, I keep only 3 or 4 pairs, not 5 pairs. But this decision is largely out of fear. I don't know how much this helps with crashing for being out of VRAM. It's unrelated to the discussion of the algorithm. Nonetheless, it's in the code like this. Don't copy this decision; use many savestates.

Optimizations:

• Try different widths for leapfrogging pairs. Each of my pairs is 6 times as wide as the next-faster pair; try 5 or 8. My fastest pair is 10, try 5 or 20. So far, I've been happy with my choices of 6 and 10.
  
• When you rewind for months or years to today, 10:00 UTC at August 22th, you don't have to save into #2 or #3 the stuff from August 2nd, August 3rd, August 4th, August 5th, ... because they'll have been discarded again by the end of the rewinding-and-recomputation operation. What matters is that you remember the newest two: 00:00 August 21st and 00:00 August 22nd.
  
• During turbo-fast-forward which goes at 540 physics updates per second (36 times faster than regular speed of 15 physics updates per second), I don't save to the fastest leapfrogging pair #2/#3. I accept that the first rewind will take minimally longer because it must load from #4/#5 instead of from #2/#3, and during this rewind I'll refill #2/#3. I don't know if this is still useful in 2026; it looked useful in 2015.
  
• During non-graphic replay verification, don't save anything at all. You don't need this system of savestating because no interactive user is going to rewind.
  

-- Simon

Hi,

see kaywhyn's announcement post above:

Starts in 20 minutes.

-- Simon

Hi,

Flopsy has started converting some of his singleplayer levels from NeoLemmix to Lix. I've got Flopsy's first batch of 26 Lix levels.

And I'd like to playtest always-insert. I.e., airclicks cut the replay, but clicking lix doesn't cut the replay; instead, other lix' futures is preserved. How will it feel?

Let's see:
Livestream Saturday, August 22th at 14:00 UTC = 15:00 British DST = 16:00 CEST.

https://www.twitch.tv/simonnaar

-- Simon

Happy to have you here!

I can provide full sleeping gear (airbed, sheets, pillow, blanket) for up to 2 guests in the living room. It makes sense to offer this option to guests from the UK first, to allow you to travel light. I recommend that extra guests book a hotel, but I can host a 3rd guest at my place as long as he brings full sleeping gear himself.

-- Simon

Quote from: WillLem on August 17, 2026, 02:29:54 AMtry in the next update.

All right.

In the long term, I'll see if the unsolvability detection produces fringe cases or false positives with cloners/neutrals/... and I'll let you know.

Time yellow/cyan is open question, can't advise yet. Sand is yellow. Cyan for attention makes sense, too.

Quote from: WillLem on August 17, 2026, 02:29:54 AMwe'll do away with the 15 seconds 'warning'. Nobody has piped up in support of that, so... let's get rid of it and see if anyone complains later.

After sleeping over it: The 15-second warning has had a job before. In ancient times, if you didn't see the clock running out, the level would quit to menu by surprise, and you couldn't rewind. Overtime fixes this design, and the leftover 15-second warning hack can now go.

-- Simon

Quote from: WillLem on August 19, 2026, 03:07:13 AMHonestly, I now think this looks a bit bland.

I think it's too colorful now. Unimportant/random lines jump to eye.

Title is important, and time limit is important (hide the entire line if no time limit). And the buttons along the bottom are important. Maybe reserve green for those buttons?

Ah, and: Time limit line on preview is yellow. Sand is yellow. Therefore time limit during play should be yellow, no?

-- Simon

Happy to have you here!

-- Simon

Hi,

we have a few German members. Who's up to meet for a few days?

I live in Kassel, Germany and am considering hosting the meetup at my place. Reasonable dates will be around February 2027 or March 2027. I have a weak preference for early March, but really anything in February/March would fit. I'll make up my mind and will let you know within the next few months.

Flopsy considers flying here from the UK for a week. To book a flight reasonably cheap, Flopsy needs concrete dates in 2027 by October/November 2026 at latest. I'd like to pin it down by November.

IchoTolot lives nearby and will be happy to come over.

Ideas for what we can do:

• Play board games.
  
• Share Lemmings levels and solve each other's levels.
  
• Work next to each other our computers, on Lemmings projects or other projects.
  
• Take a small hike.
  

Are you up to join? Let me know what dates suit you best.

-- Simon

If insert-by-default is confusing (because it keeps earlier and later assignments, both related and unrelated), the old non-inserting replay mode must be confusing at least half as often (because it keeps earlier assignments, and it ditches future unrelated assignments, which is surprising/annoying in a multithreading level).

I'm beginning to feel that airclick-to-cut is a fundamental design dead-end (= no problems as long as you don't design any further), and all the other design problems follow from having it. But airclick-to-cut is so ingrained that it should remain on by default ... at least until we have much clearer UI about what's going on and how to cut it.

Had I to design this from scratch today, here is what pops into mind:

• Idea: I'd put "Replaying. [Stop here and cut all future]" somewhere big, and something like "next assignment in 0:03" below. Such a glaringly obvious alternative to the airclick is also the fix for saxdude-like confusion (new user exits and restarts NL to stop the replay).
  
• Idea: Along the bottom of the screen, always show the replay as a timeline, like what a video player displays. Assignments are points along the line, and you have a playhead. You can click to navigate, similar to the minimap. (The minimap is becoming more and more obsolete after the zoom bugfix and after possible future RMB-scolling fixes).
  
• Idea: Tweaker always open, which is practically the timeline, but bigger and with all the bells and whistles. But it would take a lot of screen real estate. And it's an expert feature and it looks like one. Not what I'd want to show first-timers.
  
• Idea: Over each lemming who will receive a replay assignment in the next 5 seconds, we paint a large arrow with the skill on it and a countdown. You can click an [X] on that arrow to cut the lemming's future.
  

I'm also beginning to think that namida foresaw these airclick issues, forbade airclick in insert mode, and put the explicit future-cutting hotkey as a replacement.

-- Simon

Tetris has a good reason for the urgency because your strategy differs toward the end.

Lemmings doesn't have anything like this in the final seconds. What are you expected to do in the last seconds? Click harder? Fast forward faster? Use a consistent color for unwinnable. Unwinnable number of lemmings is red? Then overtime should be red.

If you change this as Proxima and I recommend, you'll have a good chance to get used to the consistent meaning of red. Red means unwinnable state. Time limit hasn't become meaningless. It's the opposite! Time limit is now doing its only job it can ever do: Preventing you from winning.

Since you're looking for examples from other games: Pushover and One Step Beyond have time limits. Both allow you to continue into negative time where you can't win. Positive time is yellow, and negative time is red.

Alternative to minus sign: The yellow hourglass (that has sand in both halves) turns red (together with its number) and has all the red sand in the bottom half.

---

I too have a weak preference for the minus sign in the save requirement, but I can't make a solid case.

The satisfied save requirement is a flag with a checkmark. Consider removing the flag and have only a checkmark in this icon. Makes it easier to see the checkmark, and the switch into the winning state will pop a little better.

Don't introduce options, you're already on the way to make the usual situation non-screaming. Green unmet save requirement is the most important for this. We agree on this already.

-- Simon