I'll steelman a case for the restrictive behavior 2) No, and weakly 1) No:

You have 50 lemmings in a dense pack. The replay contains a future builder assignment for one of them, followed by a largely-completed 10-skill route (he's a main worker). Now you want to bash with one of the 50 lemmings in the dense pack. You click into the middle of the pack. If you're unlucky and bash with the soon-to-be builder, you lose the builder's future, i.e., you cut the 10-skill route from the replay.

In Lix, this risk is reduced because Lix (under default options) is in insert mode whenever the tweaker is open. In the tweaker, you see the hovered lix's future assignments highlit. You'll think twice before you click. NL doesn't have this default behavior and indeed warrants separate risk-vs-annoyance balance.

Ideal would be: 1)-2) Yes, and some previewing power into the replay/click, and an undo stack for changes to the replay. Such undo is expensive to implement. Will and I consider undo out of scope of this issue here.

Please participate in WillLem's call for feedback (in the post before this)!

-- Simon

Implementing the function from voice chat.

I can't build Delphi here to test. There will probably be many small errors.

How wise is cutting future nukes when we cut an assignee's assignment future? I think it's correct to cut the future nuke. If you disagree, put Continue; instead of the empty statement ;. I erase future nukes in Lix, got no negative feedback, and most NL levels behave like Lix levels in this regard. Nuke levels are rare and you can always re-insert the nuke. Inserting a nuke shouldn't cut future assignments of anybody.

procedure TReplay.EraseLemSkillAssignment(
  L: TLemming;
  aFrame: Integer;
  DoCutFuture: Boolean);
var
  Item: TBaseReplayItem;
  i: Integer;
begin
  for i := fAssignments.Count - 1 downto 0 do
  begin
    Item := fAssignments.Items[i];
    if (Item.Frame < aFrame or (Item.Frame <> aFrame and not DoCutFuture)) then
      Continue;

    if (Item is TReplayNuke) then
      ; // Always delete a future nuke, like in Lix. Okay in NeoLemmix or not?
    else if (Item is TReplaySkillAssignment) then
      if ((Item as TReplaySkillAssignment).LemmingIndex = L.LemIndex) then
        Continue;

    fAssignments.Delete(i);
  end;
end;
-- Simon

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