A basher oddity found by Icho during multiplayer in Lix 0.10.5. Thanks! Here's a reduced example level.

Rule 1: Bashers walk forward during some frames in their cycle. This forward movement is allowed to enter terrain, i.e., the basher's foot is allowed to move into and through terrain.

Reasoning behind rule 1: Either the basher's swing removed all terrain here, therefore we won't walk into earth anyway. Or the basher hit steel, immediately stopped bashing, and won't walk forward.

Rule 2: During the walk forward, bashers lower themselves into holes. Bashers never gain height.

Reasoning behind rule 2: We removed all terrain onto which we might step upwards, or cancelled on steel in the way. Either way, there is no need for the basher to ever rise. But the basher may try to walk over holes, and the basher should certainly fall into such holes if they're deep enough. If the holes are shallow, it's okay for the basher to continue; shallow holes shouldn't break mental pathfinding.

As a result of rules 1 and 2 combined, the attached level Basher Walks into Terrain is solvable (saves 1 of 2, using 1 cuber, 1 basher, and a few jumpers to position the cuber and basher). The thin white line is steel.



The most noticeable effect here is that we can clip through a particular arrangement of steel.

The second effect is that a basher falls through an arrangement through which a following crowd would not fall. The non-falling crowd alerted Icho in the first place.

I don't have a good solution.

• Basher source on github
  
• github #47: Basher/Miner Interact with Blocker, Passes Through Wall, a closely related bug that comes from the same two rules.
  
• geoo's post from 2015: basher/miner❤blocker interaction, desired behavior? -- the same bug as #47, but on Lemmings Forums instead of on github.
  

-- Simon

NL 12.5.5.

Have a lemming near the top of the level, almost at the ceiling. Have space in front of the lemming. Select jumper in the panel. Hover over the lemming.

Game draws an arc that goes out of bounds (where nothing is drawn, and this is correct), then returns downwards from the ceiling. But if we assign jumper, the jumper does not follow this arc. Instead, the jumper dies beyond the ceiling and never returns. The arc and the path do not match even though there is no interaction with other lemmings.

Expected: The arc comes back from the ceiling if and only if the jumper survives.

-- Simon

Hi,

This arose from Lix's Replay Insert Mode discussion. Independently, I discussed the NeoLemmix behavior shortly on my twitch livestream a week ago.

nin10doadict describes the problem well:

Consider the example:
Phyu 59: Lem 5 gets a basher.
Phyu 60: Lem 6 gets a builder.
If you go back and insert at phyu 59: Lem 6 gets a builder, then depending on whether we're using Lix or Neolemmix we get different behaviors.

In NeoLemmix the previous assignment to Lem 5 at frame 59 is silently overwritten and won't happen anymore. Could have disastrous effects on the rest of the replay; now any other assignments that were dependent on that one will be in unhelpful locations or fail for one reason or another. I find myself manually shuffling through the frames when using replay-insert to ensure I don't accidentally overwrite something, which seems annoying.

NeoLemmix's insert mode ("blue R") is reasonably hard to access: You'll have to map a hotkey to it, remember the hotkey, and conciously decide to use this mode. Thus, the problem won't hit everybody.

But if you use it, sooner or later, you'll accidentally assign on a same frame and thus ditch a seemingly-random assignment from the middle of your replay. It's a small data loss bug. Granted, it's softened by the ease of recreating the overwritten replay. But it's insidious because you won't notice right away that you overwrote an assignment.

Solution ideas:

Should the player have to manage this?

Can the game notify the player that an overwrite has occurred with a sound or visual cue?

Should the game prevent the overwrite altogether? If so, can the player force the overwrite anyway with repeated attempts?

I think that the accidental overwrites should be hard or impossible. A dumb, but robust and easy way is: Flat-out disallow the new assignment and keep the old. If we want to be cheap, then give no feedback besides the obvious failure to insert.

namida, how much energy would you want to invest here? I'd happily chew through some UI suggestions if others pipe up here, and maybe I'll have more insights on my own, too.

-- Simon

Hi,

this thread assumes that you've kept checked the option Keep replay after ◀▮ at all times. If you uncheck it permanently or temporarily, also look at topic: Rewind as Undo: Still Preserve a Loaded Replay.

Rewind is browsing. You keep "Keep Replay After ◀▮" checked at all times. This is the default. You treat the replay functionality like a book, and use framestepping to browse through this book. Only when you're really sure, you cut content by clicking air or by assigning. You accept that Lix occasionally surprises you with unwanted assignments when you forget to cut the replay.

Let's try to improve this style even more. The behavior of Lix 0.10.3 is:

• While you're viewing a replay (a loaded one, or your current attempt after rewinding), Lix will assign by itself the remaining future assignments from that replay.
  
• Click air (really, click anywhere in the game map where no lix is) to cut the replay. Cutting discards all future assignments from the replay. Because you're now at the end of the replay, the floating R disappears.
  
• Or assign to a lix. This first cuts the replay as if you clicked air, then adds your now assignment to the replay. It also advances physics once, therefore the assignment is already in the past. Again, you're now at the end of the replay, and the floating R disappears.
  
• The tweaker (filmstrip icon) allows you to discard assignments (past or future), or to move assignments by single physics updates. Tweaking preserves the remaining future assignments, and this is deliberate -- it's really a tool to edit history and see what future results from that single change only. To discard all future assignments, click air as usual, or discard all future assignments manually in the tweaker.
  

Design hole: In Lix 0.10.3, there is no way to insert new assignments into the replay without cutting the replay.

I'd like to offer replay insert mode. Let's design it. Insert might become a user option (that you toggle from the options menu only, and never during play), it might become a mode during play, or it might even become a default.

In my recent livestream, I've experimented with a hacked Lix version that inserted all assignments instead of cutting the replay before appending the assignment. This was very useful when many lix had to work together in a tough singleplayer puzzle. But it was annoying on ccx's 100% Built By Lixes: Here, many builder assignments go to a single lix, and each assignment desynchs future assignments to that lix. I got surprised and annoyed from Lix constantly replaying future assignments because I failed to cut them. As a result, I'm considering:

Idea (*): Click air to cut all future. Assign to discard only that lix's future.

Example:
In phyu 100, lix #0 builds.
In phyu 200, lix #1 mines.
   Phyu 300 is now.
In phyu 400, lix #0 digs.
In phyu 500, lix #1 climbs.
In phyu 600, we nuke.

 (Phyu means physics update, a.k.a. physics frame.)

In Lix 0.10.3, when you click air here, Lix cuts the two future assignments and the nuke. Likewise, when you assign to either lix #0, lix #1, or an entirely different lix, Lix cuts the two future assignments and the nuke, then inserts your new assignment for phyu 301. Even with idea (*), when we click air here, Lix cuts the two future assignments and the nuke.

The difference of idea (*) is when we assign. If we assign to lix #0, we discard the assignment in phyu 400 and the nuke, then add an assignment to lix #0 at phyu 301. If, instead, we assign to lix #1, we discard the assignment in phyu 500 and the nuke, then add an assignment to lix #1 at pyhu 301. If, instead, we assign to lix #29, we discard only the nuke.

Is (*) sensible? Or do you see a different way to improve Lix in this direction?

Should we offer (*) as an option, in addition to offering how 0.10.3 always cuts all future actions on assignment? Should it be a user option in the options menu, or should it be a button during play? Either way, should (*) be the default or should 0.10.3's cutting be the default?

-- Simon

Hi,

while I composed today's main issue about about negatively-worded binary options, I thought about how namida and Nepster worded those options in the config file. Then I stumbled onto this bug on the side:

NeoLemmix 12.12.5.

The user options file settings/settings.ini does not persist the option "Don't Replay After Backwards Frameskips". If you check that option during your session, it will be forgotten after the end. settings/settings.ini contains no line for that option. When you run NL for the next time, the checkmark will be gone. During play, then, NL will replay your actions after you've rewound them.

Expected instead: NL writes that option to settings/settings.ini. NL restores this on next session.

(Other options save properly to settings/settings.ini and restore properly.)

Who needs the option to ditch actions from the replay on rewind? I haven't seen anybody ranting about this bug before. It looks like I'm the first to run into it, and I only ran into it during the naming research, not because I wanted to toggle that option. Lix offers a similar option ("Keep replay after rewind") and Forestidia and mobius prefer in Lix the rewind to be an undo. Forestidia feels strongly about this in Lix. Thus, it feels like it makes sense to keep the option. But stay tuned over Christmas for the popcorn on insert-into-replay in Lix.

-- Simon

Recording will remain for 14 days at:

https://www.twitch.tv/simonnaar

-- Simon

Hi,

Proxima has laid down maintainership of Lix's lemforum level pack.

As long as we don't have a designated maintainer, we'll still work together on the levels, but nobody's word trumps others. I'll glean from the discussions what might be best, and implement that in Lix. Everybody, please speak up if I make odd decisions, and I'll happily do something else in the next version of Lix. Also, if you know lemforum well, you can step up to be maintainer and call the shots!

Lix lemforum is the flagship pack. One possibility is to stabilize lemforum, which means that we'll mostly fix backroutes, but avoid larger level swaps. This is best for speedruns, and it preserves the spirit of the contributions. If Lix gets fancy new features or new levels, we can put those separately from lemforum.

The alternative is to keep cutting weaker levels every now and then, and let lemforum slowly adapt to Lix when Lix gets new features like neutral lix, or new tilesets. This allows us to recommend lemforum to new players as a sample of the state of the art, and still have the vast majority of the content from 2010 to 2012, although not necessarily all of it.

You can mix the two ways to a degree, but they're fundamentally incompatible. I'd like to recommend to new players at least some cross-section of Lix's features and level designers' work. Proxima prefers a stable lemforum that we still recommend to new players as first pack, as we've always envisioned.

It's an amicable parting. I'm sure geoo's and Proxima's handwriting will stay visible on lemforum. Thanks for your contributions! Proxima, you're busy in life, about to get a foot into the door of the software industry. And in Deadly Rooms of Death, you've got a big project on the brink of release. I wish you the best of luck with both projects!

And barge in if we ever screw it up.

-- Simon

Hi,

darkshoxx joind our recent Lix session on Saturday, November 26th. I streamed the session to twitch, and darkshoxx also streamed the session to twitch. To familiarize himself with Lix, darkshoxx played Lix singleplayer for an hour before the multiplayer session.

darkshoxx's Lix stream from 2022-11-26
(twitch will delete this on Dec ~10th)

Thanks for the stream! Here's my feedback:

Button caption: darkshoxx played the first level Any Way You Want and reached the end-of-singleplayer screen. The button at the bottom says "Back to the browser". darkshoxx reads the button, and says: "What? It's not a browser. Whatever."

Indeed, the level browser is a level selection first and foremost, and it only happens to be also implemented as a file browser that can browse to every level. I'll recaption the button to "Back to Level Browser" or maybe "Back to Level Selection".



Feedback on winning/losing: darkshoxx played Let's Block and Blow?, which has a save requirement of 19/20. First attempt, he flings several lix to death. Obviously this is wrong, and he resets.

Second attempt, he carefully assigns the exploder to not fling any lix to death. And he succeeds in this goal. This second attempt saves 18/20, it doesn't save the exploder and the blocker. This comes short of the save requirement of 19/20. Since he didn't fling anybody to death, he believes that he's won, nukes the blocker, reaches the end-of-singleplayer screen, and happily moves to the next level.

The end-of-singleplayer screen always presents the next level, even if you've lost. I like this, but it makes winning and loosing look nearly alike on that screen. The only difference are the small numbers at the top left, and the caption "Congratulations! You solved:" vs. "Try again:" over the solved level in the top right. We're all conditioned to not look much at the solved level in the top right.

During play, I'd still like the nuke to exit regardless of winning/losing. I think it would be awkward to pause after nuking a losing attempt.

As annoying as it is to admit: Winning and losing is central to every game, and Lix fails to present it properly. We need better feedback about winning/losing, both during play and during the end-of-singleplayer screen. I have loose ideas, but nothing ready to discuss yet.

---

This third finding is feedback for darkshoxx, it's not for Lix.

You had us in Mumble. At first, your viewers considered us too quiet. You raised the audio output in Mumble, but that didn't affect the loudness of Mumble in your stream. I think you should lower the Mumble audio output back to 100 %, to reduce the chance of audio clipping.

Then you put gain on the Mumble output. We were pretty loud already then, at least as loud as yourself. Then you put gain on the Mumble output a second time. Now, we were very loud, far louder than yourself. When I spoke, we got audio clipping in your stream. Maybe it's the mix of more than 100 % on the audio output, maybe it was from my side, but it ended loud in the stream.

I think a good amount of gain was how much you put on us the first time, before you raised it for the second time, together with Mumble at 100 %.

Or perhaps even slightly less gain than the first time (but still more than nothing)? Then you're at least as loud as anybody on Mumble, and your viewers want to hear you after all.

-- Simon