The glaring bug here is that NeoLemmix doesn't tell how to cancel the replay (click into the air). I'm beginning to think that NeoLemmix should write that in big fat letters during replay.

You aren't the first to be confused on how to cancel the replay. I've heard about this confusion in Lix at least once before, and in NeoLemmix IIRC also another time before. It's a terrible problem. It has the potential to discourage new players from the hobby, and they'll never ask about it.

Welcome to the forums!

-- Simon

Welcome to the forums!

The best way to attract co-developers is to present a program that already does something fun and unique. It doesn't have to be perfect, as long as it's exciting to try. Compare it with some existing Lemmings projects here: All those projects started in the hands of a single programmer. Only over time, the projects attracted graphic artists, level designers, and extra programmers.

If you aren't into software development yourself: What would be the big new exciting idea? What do you envision that none of Lix, NeoLemmix, Lemmini, SuperLemmix, L2Player, Loap, ..., have yet? Do have a specific gripe about one of them that you want to see fixed?

-- Simon

Radical new plan. We'll ditch the scissors button again. Reasons:

• Wasn't nice in my own playtesting on stream.
  
• Behaves like a skill (mutual toggling, only one of those buttons can ever be active), thus goes into the skillbar. But feels alien in the skillbar.
  
• Unclear what you can do with it on first sight.
  
• I have other solutions for the design problems that prompted me to create the scissors button.
  

The design insights that suggest other solutions:

• I want to avoid air misclicks during insert mode that cut the replay and thus lose data. We can do that by disallowing { air clicks cut replay } at certain times. We don't necessarily need a new button.
  
• I see a lix on the map and want to erase her future. We can support that by better association between lix and their tweaker lines. E.g., we can highlight lines of the hovered lix (will be in 0.10.10). We can also highlight the lix of a hovered line (not implemented). It's not 100 % necessary to click the on lix to erase the assignments, we can also click on the assignments in the tweaker, which should also feel nicer.
  
• In a multi-hatch level, especially in a disjoint union, I want to see which assignments go to which hatch, or to which level component. We can solve that by re-labeling the lix: Instead of a running count across all hatches, we can label the lix <hatchID><runningCountFromThatHatch> (not implemented). E.g., with three hatches, we'll get lix a0, b0, c0, a1, b1, c1, a2, ...
  

In Lix 0.10.10, we only have the highlighting of tweaker rows for the hovered lix. That's a standalone improvement. I'm happy to add that ahead of time, regardless of what we'll eventually implement for inserting.



If I don't want a scissors button, then how do we choose between cutting and inserting? We can tie the insert mode to user options. I believe that I want to be in insert mode 90 % of the time. With the options in this screenshot, I'd check both of the bottom Insert Mode options.

The downside is that it's harder to discover, and I'll need tooltips.

I haven't tried an insert button yet, I merely know that the scissors button is not so nice. It would be another option (good default?) to have an option for an insert button. I.e., replace the bottom two bool opions in the screenshot with radio buttons:

• Never insert,
  
• always insert,
  
• insert only when tweaker is open,
  
• insert only when insert button active, which starts off by default. And you get the button in the panel only when you pick this option. This can be default.
  

Odd thing though and more elaborate to tie the panel button layout to user options.

We can even consider a button that only cuts the replay, without creating new modes. Heretic idea! What a waste of panel space! But after all this design pondering, it doesn't sound as far-fetched as before. I still don't want to make one yet.

-- Simon

Thanks for the feedback!

-- Simon

The UI bugs from the previous stream (Sunday, May 21st) are now fixed.

For the next stream: I'm still not sure if the scissors button is really the best UI. We'll see. The main point of the stream is to test the scissors button myself more. Maybe the levels are getting too difficult for your entertainment, I can't promise anymore that I'll solve anything.

-- Simon

Test Release 3 - 20/01/2022, Linux release (probably same for Windows)

The installation of L2Player tells us to extract it into the same directory where our L2 sits. This seems only necessary for the first successful run of L2Player because L2Player now extracts the L2 resources into its own tree that L2 cannot see.

The problem is that both L2Player and L2 contain several files in their root directories, and it's hard to separate the two programs later. E.g., if L2Player gets new files or drops files from its release, it's hard to wipe L2Player and cleanly reinstall. For now, I've duplicated the L2 files into L2Player's directory because I don't trust L2Player yet, it's a new program for me. :-)

I'd like a way to point L2Player to an L2 installation elsewhere for resource extraction. I expect L2Player to only read from that L2 path then, not modify any files in it. It's okay to continue to extract from the working directory if I don't explicitly point L2Player to an L2 installation.

The first idea that comes to mind is a command-line option, e.g.:
$ L2Player --extract-from=/path/to/l2/
or, if you need it more often than only during first run:
--l2path=

But anything is fine for now, e.g., you can ask me at runtime, or you let me edit a line in a config file. Or even declare it low priority. It's not so hard to duplicate L2 into L2Player.

If L2Player has already extracted the resources, I expect to run it later without pointing it to L2 again. In particular, if you don't give me a way to point L2Player elsewhere, I'd like to know how soon I can remove the duplicated L2 files in L2Player's root dir.

-- Simon

Test Release 3 - 20/01/2022

The Linux release contains OpenAL32.dll and wrap_oal.dll. The Linux executable is a native 64-bit ELF, and it runs as expected even when I delete both DLLs:

SpriteSheet: Calculated 102 font widths for ./data/cache/font_0.spt
Starting OpenAL... 1.1 ALSOFT 1.23.0, OpenAL Community, OpenAL Soft
[...]

Thus, you can omit OpenAL32.dll and wrap_oal.dll from the Linux release. You already instruct to install OpenAL natively.

-- Simon

Oh dear, did that level also cause frustrations?

No worries, Tomb of Doom produced a strong a-ha effect, and we never had execution problems. I can guarantee that it won't be a rant!

-- Simon