I'd like to investigate:

• Air clicking still cuts the global future.
• Assigning still cuts the future of that lix.
• When you hover over a lix without future assignments, still say "Click to insert."
• When you hover over a lix with 7 future assignments, say "Click to replace 7 future assignments."
• You still need the tweaker to cut a single lix's future without assigning anything to her. This is a problem, but the scissors panel button wasn't the answer to it in 2023.
• Opening/closing the tweaker doesn't toggle the mode, unlike Lix 0.10.32, because there will be only a single mode.

I want better visibility/previewability of what your click will do, i.e., from things such as list item #4. Wisdom will be found in better visibility of system status, not in modes.

I don't know whether I should keep two modes or if it's possible to condense cut mode and insert mode into one.

The ideas come from NL: Erase future of same lemming in insert mode.

I'll have to user-test with newbies when all is said and done. It's possible that a single global timeline is easier to understand than many interwoven timelines ... even though I find the single global timeline unnatural. Wonder how newbies will react to either philosophy.

-- Simon

This is still open.

Watching replays is different from rewinding to fix mistakes. You rarely want to interrupt. But you should still be able to interrupt.

-- Simon

Task: Design 1)+2) Yes in a way that prevents my above post's worry of 50-lemming lottery.

Idea: In insert mode, whenever you hover over a lemming, show the number of future assignments that will be cut if we click. You'll know it even in a dense pack, and even without looking at any replay listing. I'll see when I find the time to implement this in Lix.

-- Simon

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