Next stream will be tomorrow, Sunday, Feburary 9th, starting 18:00 UTC.

https://www.twitch.tv/simonnaar

I'm back in Lix development, and I'll have a few singleplayer features to playtest during this stream:

• Scissors mouse cursor when you can click air to cancel the replay. Will it be annoying?
  
• Small scissors next to the cursor, or a small "+" sign in assignment mode, when the cursor opens over a lix during the replay.
  
• Explain the gadget in the infobar whenever the mouse hovers over a gadget. E.g.: "Goal. Save 10/20 to win." Or: "Catapult. Flings +4, ↑16 in 8 ticks." These texts appear where "Lix #7 is bashing" would also appear.
  

I'll play NepsterLix, and I'll start at its very beginning.

Over the years, I have looked sporadically at best at NepsterLix, ClamLix, and Rubix's pack. I'll have to try them properly. Last year, I've played geoo's pack on stream, and I can still warmly recommend that.

-- Simon

Cool, thanks for clarifying that the workaround works (copying Allegro DLLs from Lix 0.10.28 into current Lix). I'll have to investigate what exactly changed on Windows with this recent jump from Allegro 5.2.9 to 5.2.10.

I'll come back to you when I have new ideas.

-- Simon

I assume this is from the Allegro DLL upgrade from 5.2.9 to 5.2.10. Reason: Nothing related in the Lix code should have changed between Lix 0.10.28 and 0.10.29.

As a workaround, put the 5.2.9 DLLs (from Lix 0.10.28 or earlier) into Lix 0.10.29. Does that help?

-- Simon

All right, Tuesday (today) at 18:00 UTC. See you!

-- Simon

No strong opinion on the steel sound for a disallowed miner. If I assign during pause and the failed assignment doesn't advance physics, I know that it's not physically striking steel. If I assign unpaused, you risk misinterpretation.

-- Simon

Quote from: WillLem on January 30, 2025, 04:11:02 PMunknowingly overwrite the Climber assignment.

Permanent ability assignments are odd in modern Lemmings.

For the physical motion, there is no difference between

• queuing the climber for the next wall (let the engine assign it for you when lemming reaches wall) and
  
• assigning climber earlier than the next wall (assign at arbitrary time between two reachings of wall, but you still must choose a tick).

From the view of the replay, it's a difference because NL refuses to accept two assignments for a single physics update. The intuitive fix for insert mode, when the clashing assignment comes, is to shift the old climber assignment earlier/later by 1 tick, in hope that it doesn't produce different physical motion. This is nasty. It's not guaranteed to produce equal motion, and the climber can clash with another old assignment.

I recommend: Don't worry about permanents. Solve the other skills first, then think about permanent abilities. I have worried about this in Lix, too, and it's too rare a case to design the entire feature around it.

Quoteassign a Platformer to Lemming A instead of a Builder
now all assignments following frame Y are out of sync
solved by using the Replay Editor

... or by cutting the same lix's future.

By your point, we should either never overwrite (not even same lemming), or first cut that lemming's future and then insert (what I suggest).

I agree that it's odd to allow overwrite same lemming, but keep the lemming's future.

In 2022/2023, I've played Lix with insert mode always-on, as a playtest. The first result was that same-lix-overwriting sucks when you preserve the same lix's future.

Quote from: namida on January 23, 2025, 08:37:46 PMiffy about the idea of erasing all future assignments for the same reasons. Additionally, it might be useful for the player to refer to the future assignments when correcting them

This is vague, what exactly are you doing? Do you look at the listing (as if you loaded the replay in a text editor) to see what the original replay was? When I fix a replay, I know enough of the solution, I've never needed a mixed list of old and new assignments.

Or do you need this when you move assignments by only a few ticks earlier/later? You have a chance then that the old assignments stay meaningful.

Quote from: WillLem on January 30, 2025, 04:11:02 PMYes, because the player is in Replay insert mode, which never allows overwriting:
reinforcing the player's choice to be in Replay Insert mode

This is backwards. It's okay to look at what the existing mode does (to not confuse existing users), but it's irrelevant what either of us supposes for the existing mode's design.

In your design, there are two modes: Always cut, or never overwrite. If your never-overwriting mode comes closer than always-cutting to what the player really wants/needs, he chooses to use never-overwrite mode (regardless of any design ideas behind that mode) and can still be unhappy.

Indeed, the natural next idea is to consider three modes.

Quote from: WillLem on January 30, 2025, 04:11:02 PM1) hotkey to allow overwriting
accept that this will also allow overwriting to a different lemming

Quote from: WillLem on January 30, 2025, 04:11:02 PM3) third mode:
preserves everything it can, but does allow overwriting
accepts the potential for accidental overwrites

Here's how these will behave in practice:

• Lemming becomes builder at tick 100.
  
• We want to assign him basher at tick 100.
  
• We go to the always-preserving insert mode because that protects against overwriting a different lemming.
  
• Assignment fails (because of old same-tick assignment).
  
• We framestep forward and back to see which lemming has the old assignment.
  
• Ah, it's the same lemming, therefore the overwrite is safe.
  
• Hold hotkey, or enter third mode (essentially the same idea).
  
• Assign to overwrite.
  

Two annoyances:

With 1) or 3), you still require the player to back-and-forth manually in step 4, to see who gets the clashing assignment. You've already identified that this is a problem, and you're looking into other solutions, I'll get to it later.

With 1) or 3), you still don't cut the lemming's future in step 8. I recommend to either forbid the overwriting, or to overwrite by cutting the same lemming's future.

Quote from: WillLem on January 30, 2025, 04:11:02 PM2) make it optional
doesn't allow on-the-fly switching

At first, this sounded like 1) or 3), but with a user option instead of a third mode during play. But I won't dissect it yet, because then you write:

QuoteIt also means figuring out the how when it comes to implementing same-frame same-lemming overwrite, which (full disclosure) isn't trivial!

This is getting to the heart of the matter.

What we really want is freedom to design the mode around clearly visible system status. You want to see ahead of time who/what exactly will be assigned, so we know what exactly will be overwritten/why the click will fail. You'll give the player the best information before he clicks at all. (You can still give feedback after the fact.)

And the important starting point is to ferry information from replay to the UI ahead of time about who will be overwritten.

I'm happy to dissect the NL code with you.

Tomorrow (Tuesday, Feb 4th), I have a day off work, and I can offer you any time of the day for a Mumble session. Do you have time around 18:00 UTC?

-- Simon

Sorry, I had assumed that you wanted the 3rd column of widgets hidden (instead of partially visible). That's why I wrote: "The code [...] hopes that the window is small enough so [the widgets] are outside the visible window."

Now it sounds like you want them fully visible (instead of partially visible). And you have better ideas around that than anything I could guess from here!

-- Simon

Hmm, intentional same-tick-same-lemming assignment is more common than accidental same-tick-same-lemming assignment. But you have a point with how both such overwritings are still not common enough to spearhead the main design of the feature.

Regarding only a single lemming (disregarding same-tick-different-lemming worries), it's more common to kick a lemming's future from a wrong assignment onward, and then insert around that time.

I'll re-read the discussion with this insight and come back to your long post in a few days.

-- Simon

I'm unhappy with the audio volume levels. Music too quiet, people in voicechat too uneven.

Flopsy: Do you want my local recording of the session for uploading to Youtube? It has the same bad audio.

-- Simon

We agree that CE should not silently overwrite same-tick-different-lemming.

Now consider same-tick-same-lemming. How does it look in practice?

Lemming A becomes builder in tick 100. We want to assign basher to lemming A for tick 100.

We rewind to the result of tick 99. We select basher in the panel. We click lemming A, and expect lemming A to become basher. Under your proposal (never overwrite), lemming A becomes builder again. This will intuitively feel like a misclick, we failed to tell the computer that we want to assign basher. You can make the feedback more explicit (better sounds, better whatever), and then the program will look like it's telling the player: No, player, you cannot do what you want. I know that you want to bash here. There is builder in the replay, and I've clearly shown you the builder assignment during rewinding, therefore you'll certainly want to overwrite, but I still refuse to give you what you want.

You'll make the normal case rage-inducing!

Quote from: WillLem on January 25, 2025, 07:02:15 AMthe replay actions themselves are not visible

Actions of the same lemming were visible a second ago, during rewinding -- they were the sole reason for my rewinding. There is no accidental same-tick-same-lemming overwriting to prevent.

For same-tick-different-lemming, yes, we shouldn't silently overwrite.

The original feature request against NL was to avoid accidental overwriting to different lemming. namida originally thought: Let's not prevent overwriting because overwriting same-tick-same-lemming is so useful (source). It took some discussion to separate same-lemming from different-lemming; neither of us immediately saw the fundamental distinction. But, indeed, one is an accident, the other is useful.

-- Simon

Blitz, what is the use case?

Several people using the same computer? Do they use different Windows profiles? Do you want one installation of NL (sitting in some central place) to look into the different Windows profiles (and see different options/records/... per user, depending on who is logged into Windows)?

Or do those people all share a Windows profile? Since you're mentioning security, what is the goal? If all this happens in one Windows profile, the people can see/read/modify/erase each other's profile. What do you want to prevent with security?

Or is it for one person who makes several NL profiles? But then why worry about security?

Quote from: namidaI don't see any harm in it existing.

I do. In the best case (least harmful), this complicates the program in three ways:

• Separate the options into two groups, user-independent and user-dependent. The groups must store separately. The only user-independent option is which user is active.
  
• Load the user's option only after loading the user-independent options. Import older NL's user options, i.e., write extra code for backward compatibility.
  
• Switch user during execution, to an existing user or to a new user. This touches a global (current user) that affects state across the program, which invites bugs.
  

Depending on what Blitz wants, this complicates the program a lot. Security features in NL that don't rely on the OS?

Quote from: WillLem on January 25, 2025, 11:05:46 PMDecent idea. Anyone else in support of this?

Consider: Have people keep two NL directories. People already do that to have different NL versions.

Does Blitz want one installation of NL to work with different Windows profiles? Consider: Write options into the OS's user directories instead of into the NL directory where the executable sits. This can be sensible, but it breaks culture, existing users expect the options to be in the executable's directory. I support this in Lix: Immutable program directory, read/write to user directories elsewhere, i.e., rely on the OS's user handling. But it's a compile-time option, I deactivate it for the Windows release. Linux package maintainers must enable it (I tell them in the build notes) so that Lix can be packaged for Linux distros.

I had different profiles in Lix itself, with per-profile options, trophies, ... for the same OS user. I removed all of it. I was very happy after removing it.

-- Simon

I guess: Those number-entry widgets are only relevant when condition X is met, and X is false here, therefore the code moves the widgets to the right, then hopes that the window is small enough so they're outside the visible window.

The UI toolkit should allow you make those widgets invisible (shown = false, hidden = true, visible = false, invisible = true, ..., names vary, look for something related). Then the code will say what you really mean, and you don't have to hope for specific window rendering. The next user will run the application in Wine and have different geometry yet again.

I suppose that there are reasons against writing multiple layouts, where each layout has only the relevant fields (nonexistance of the widget vs. invisible widget). Invisible widgets can still be a hack, or they can be the best choice (as in: everything else is worse).

-- Simon

Yes, I have the same worry. We'll have to see it in practice. Let me know if it's distracting.

Naive fixes: Lower the lifetime of the debris. Or lower the velocity.

People are (too?) tolerant with eye candy and reluctant to report excessive eye candy. E.g., in multiplayer, you see assignment arrows for all enemy actions. Those arrows are good attention-drawing when the opponent hides a saboteur in your crowd. In general, when I think about it outside of play, the arrows feel like excessive design. You can't disable them: No user option exists. But nobody has ever complained about those arrows.

-- Simon

Lix 0.10.29 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.

• When a digger hits steel and stops, the jackhammer breaks into three pieces that fly away.
  
• After a basher has turned from hitting steel, the shovel flies away.
  
• Observers of a networking match can change the current team: Hover the mouse cursor over the lix of a different team to see that team's skillset and hear that team's sound effects.
  
• In solobattle (= play a multiplayer level from the singleplayer browser), you'll only hear sound effects for the current team. Hover the mouse cursor over the lix of a different team to change the current team.
  
• Update Allegro DLLs in the Windows binary release to Allegro 5.2.10.
  
• Document in ./doc/dev/nuget-dlls.txt how to extract Allegro DLLs from the Allegro 5 NuGet release.
  

-- Simon

NeoLemmix CE 1.0-RC1 in Wine.

• Extract to new directory.
  
• Copy settings/ from an existing NL into CE. (Should I attach a copy?)
  
• Run NeoLemmixCE.exe.
  

Observed: Main menu appears, and a message box appears: "A NeoLemmix update, V12.14.0, is available. Do you want to download it?"

Expected instead: Main menu appears. No such update box appears. Two reasons: CE 1.0 is newer than NL 12.14. And CE isn't distributed via the NL website.

(After this, CE runs well. Ah, this is wonderful, the zoom bug is fixed and it has the decreed 12.14 physics.)

-- Simon