All right, I've noted Saturday, March 7th, 15:00 CET (14:00 UTC). See you!

-- Simon

Hi! Thanks for coming back to this.

Time is tight these weeks. I can offer you: [some dates, WillLem picked Saturday, 7th]. Time of day is your choice, ideally in the atfernoon or early European evening.

This is mainly to look at the NL source to look at the existing infrastructure, and to rule out potential bugs that would arise from the implicit cutting of same-lemming future.

-- Simon

Rubix, you're welcome! I'm busy these weeks/months away from the Lemmings Forums, but the work on Lix will resume, as it always has.

Sorry for the late reply.

-- Simon

Thanks!

Already in 1990, the devs worried about levels breaking after a physics change, and level authors left some leeway for builder bridge widths.

-- Simon

Yes, happy Valentine's day, and happy Lemmings release anniversary -- it always coincides, and one is a reminder for the other.

Welcome to the forums!

-- Simon

Here's a way to split a stream of lix into two. It relies on the catapult's cooldown time. Then it delays the non-flung stream in a zig-zag to let the flung stream catch up.

Another way, like Icho explains, is to place two opposing entrance hatches next to each other.

Or you can dig manually out of a pit. But this needs a manual skill assignment.

There is no randomness in Lix. Physics are 100 % deterministic. The chaos is emergent from skill assignment side effects, and from multiplayer interaction. Happy level building!

-- Simon

Right, always complain about what sucks. Otherwise I can't make things better.

There is no immediate difference between a bug report and a feature request. In both cases, the user wants X, the program does Y, and it shouldn't make a difference whether the programmer/designer wanted X or Y or neither.

Anything that touches physics needs a strong plan for backward compatibility. How much will break in other people's levels? I have control over levels that I ship, but not over what people build in the editor. How quickly will people update, to be able to netplay with each other again? Will it require a change in the level format? This is the most annoying one; people will feed new levels into old Lix and old Lix must react in some way. Many physics ideas go on the backburner, but I still read them.

Tilesets don't necessarily have to be higher quality than what's in NeoLemmix, but they should be at least as nice as what's in Lix on average. Tiles should also be free from copyright restrictions. All existing tiles in Lix are effectively in the public domain (via the CC0 copyright waiver). And, yeah, it's nice if tiles interact nicely with existing tiles. Multiples of 8 or 16 are easy in the editor. Shapes should have clear outlines to make physics easy to see. I recommend against fickle shapes where lix get stuck in unobvious ways. But it's fine to have meticulously detailed paint inside a block of clear outlines.

It's hard to remove tilesets after people make levels with them, tile removal is practically equivalent to a physics change. That's why I'm reluctant to add everything on a whim. Of course, people can still make levels even if the tiles aren't in the main Lix download, but you'll have to tell others to install your custom tiles.

-- Simon

Don't use red for the benign state (none saved yet) that you see 70 % of the time.

Required mental computation with this display: 46 (hatch) 27 (space) 79 (exit) 5, how many more may die here? Can you still win?

Printing {alive in the level, excluding what's in the hatch} can't be optimal if room is costly. Consider printing {alive in level + in hatch} instead. That would have helped me more toward computing winnability than {alive in level} and {alive in hatch} separately helped me. There are more detailed arguments in those 10-year-old topics for what exact numbers are helpful.

How will the panel look after the hatch is empty? Does it still make sense to show a hatch icon then, and not a lemming icon?

-- Simon

A reason behind putting {saved minus required} and {lems alive} next to each other: You compare these counts to see how many you can lose. {Lemmings in hatch} is unrelated, and should go to the side.

Don't use red for the completely normal state (level not yet won) that you see 95 % of the time.

The negative count has always been questionable UI; we did it because it saved space and because it uncluttered the panel. It makes sense in theory, too: It's a debt. saved/required was nicer, but it needed 4 numbers. History: Clam proposed in 2015 to show the save requirement during play.

It's conceivable to write {lemmings in hatch} onto the hatch instead of into the panel. Reason: When you need this number, you're looking near the hatch anyway. Unsure.

The NL panel comes from the archaic design of Lemmings 1's panel, which hid the save requirement. NL panel's main value is nostalgia.

-- Simon

Quote from: WillLem on February 04, 2026, 05:41:14 AM

QuotePlayer:if more than one player is in the NeoLemmix folder (however it'll only detect Legacy and Community NL for this editor) you can choose between which is played, this will be greyed out if only one compatible player is in the folder

I can't quite decipher what you mean here.

I guess: When there is more than one game executable, the editor should allow to choose between them for playtesting. No choice (greyed out or choose-1-out-of-1) when the editor finds only a single game executable. The editor should only count CE and namida's NL as game executables.

namida and Eric called the game a player (edit with the editor, play with the player). Multiple game executables can happen at minimum when you exctract CE into namida's tree.

-- Simon

I'm not sure either whether wheel-up or wheel-down is better for rewinding. Option is sensible.

I think it's correct to continue offering one-shot LCtrl, RCtrl, LShift, ... If it clashes with that rewind, so be it. I assume the wheel-rewind will eventually be optional altogether (not merely which direction, but whether the wheel rewinds at all).

No idea yet for how to reconcile the feature with the remaining hotkey mappings.

-- Simon

Welcome!

Happy to see Lix working well on Fedora, and that you aren't running into any problems even with your grand level designs.

None of A, B, C are possible in Lix 0.10. Silken has already explained it well while I was typing, but I'll post the full answer nonetheless.

A) I have no satisfactory explanation for why there is no upwards digging. The best argument is historical. I reimplemented the 8 skills from Lemmings 1 and then a few things from Lemmings 2, and that is it so far.

B) Splat height is fixed. Even a fixed height is hard to eyeball. It needs the splat ruler in play, and I still have an open bug report for how the editor lacks the splat ruler. It's the nastiest part of running physics mentally, and I'd prefer not to exacerbate.

What exactly do you want to do with adjustable splat height? Do you need falls survivable in specific places? You can catch lix at the bottom of a long fall with steam (the white steam clouds, or the blue transportation beam, both are in the traps dialog) and it resets the lix' fall distance.

C) More control over entrance hatches is interesting. I feel that the existing system is too simplistic: Round-robin across all hatches from the same initial count of lix. At the very least, it should become possible to place a single lix into a level outside of the existing round-robin.

You can already have different shirt colors by making multiplayer levels. You can run them in singleplayer, you control every team. You can't make puzzles in this way (multiplayer levels don't have a goal number of lix to save), but you can still make pretty paths.

-- Simon

I would bake this into the executable.

But there are alternatives. Allow editing the file, but checksum on load and warn nonintrusively on mismatch.

Icho's position is interesting. What do you think about externalizing even more physics? E.g., create a physics configuration text file. Let people set custom splat height in it. Warn nonintrusively about custom physics when it contains anything else than 63 safe, 64 dead.

-- Simon

The link for CE 1.0.1 is broken.

-- Simon

Oh, you're hardcoding. Then:

My hunch is to rewind with wheel-up + modifier keys, and to forward with wheel-down. Guigui recommends it the other way. And it sounds like WillLem has implemented it Guigui's way.

Reasons:

• Wheel-up moves back in a document. It should move back in time.
  
• Wheel-up zooms into details. It should move into history (= the details/reasons for the present).
  
• Wheel-up moves toward the top of a list. NL lists the earliest plies at the top of the replay editor. But it's not only NL: Lix lists the early plies at the top of the tweaker. And both NL's and Lix's replay files are sorted by in-game time, with early plies at the top.
  

Or, Guigui, do you have a specific reason why you want to rewind with wheel-down?

This feature has potential. Might warrant more love than hardcoding, but if we hardcode for the first release, we should think about direction.

-- Simon