CE 1.0.1
NL 12.14

During Insert Mode between physics updates N and N+1, when you insert a skill assignment to lemming A that will affect physics update N+1: First erase the future of A in the replay (erase all assignments to A at N+1, N+2, N+3, ...), then assign to A.

This will fix two problems at once:

• The garbage will be automatically deleted. In existing NL, the player must now either go to the replay editor to delete the garbage by hand, or, worse, let it clutter the replay and hope.
  
• You naturally allow same-frame-same-lemming overwriting. CE 1.0.1 blocks same-frame-same-lemming, which is the most annoying type of failed assignment because the intention is clear.
  

If you're concerned about losing data, we can talk. The hunch is that you shouldn't worry, but I'm happy to be convinced otherwise.

Armani and I have already argued for this in Improve same-frame assignment behaviour in Replay Insert mode, which is now closed. That thread, anyway, became more about the sound for failed assignments and whether to advance physics on failed assignment.

-- Simon

NL-CE 1.0.1

The replay editor (what I call tweaker in Lix) sometimes prints some lines in blue (rather than black). I didn't find explanation anywhere in the program about what that blue means.

Ideas:

• Introduce a new column for this the information. You can still keep the blue if you want.
  
• Write static explanatory text in the tweaker.
  
• Ditch the information altogether?
  

It feels unsettling without at least one of these.

---

Speculation: It means that the assignment entered the replay during insert mode.

The support for this is the weak connection by color to the blue R in the panel. The meaning of the blue R is similarly mysterious, the program conveys information only by color without explanation. At least, the blue R had the connection to the hotkey that you mapped yourself by functionality name and then pressed.

If I'm right and a blue line really means that this assignment was added during insert mode: I draw moderate benefit from of it. Over half the replay ends up blue in complicated levels. After entering insert mode, I stay in insert mode all the time until I have to click air to cut. At least it gives some random structure to the list for finding assignments by eye.

If you stay in insert mode and fast-forward physics past the end of the replay, then assign more skills, these new assignments are still blue, even though you couldn't see the blue R in the panel.

-- Simon

Testers: crispweed (author), geoo, Simon, cobayeshimaru (presumably from crispweed's Discord group).

crispweed's game 0.0.4, received via PM.

Collection of loose ideas, to be split into topics when an idea gets traction.

Distribution:

• Please choose a name for your project! It's hard to call it "crispweed's game". geoo has begun to call it "client", you probably don't want that to stick. I put it into a directory "crisp", which is better but you should still consider if you want that to stick. If you choose a long name, people will abbreviate it. If you stay around and choose no name, I'll be tempted to call the game "Crisp", which isn't searchable, but it's clear at least to me.
  
• Sleep over whether you want to open-source it. There is no need to rush the decision.
  
• Store releases in a public place, then you don't have to upload it several times (e.g, as a PM attachment).
  
• My preferred way to get it would be either to fetch the source from a public git repository and build it myself, or to download binary releases from your public place.
  
• You told me in chat that you're fine with livestreaming (of such playtesting sessions) or with redistributing your binaries (e.g., for troubleshooting). That's helpful to know already.
  

Networking:

• It's smooth, there is no noticeable lag. I wasn't sure whether it's from a good lag-combatting algorithm or whether it's because we're all from Europe (France and Germany).
  
• Game freezes occasionally by design until all everybody's lag-spikes have clearerd. Felt fine, it hasn't been worrisome so far.
  
• There are two classic ways around the lag: Input delay (Starcraft, Clones) and recomputation of history (Lix). Clones's input delay became problematic when geoo and I in Germany played with the Clones devs in Canada. See me on Clones and geoo on Clones: "in the current implementation, the lag affects the assigning player with every single assignment. With the alternative, it only affects the other player when he happens to be watching the morph assignment in this precise moment, poised to react, which is a less frequent occurrence." And L++ was the precursor of Lix.
  
• The Online Players tab miscounts players, you already know about that.
  
• Confusing screen after play: You have two lists, one for players who haven't returned from game to lobby, and another for players who have. It looks like half the players have dropped from the networking altogether. As long as player X is in the room, X should appear on the visible list.
  

Physics:

• The rectangles (lemmings) get stuck in seemingly-traversible terrain. We estimate that your walker ascension height is too strict. Consider: Lemmings-1 lemmings ascend 6 pixels, Lemmings-2-the-Tribes lemmings ascend 4 pixels. Lix ascend 12 pixels but in hi-res, it's equivalent to Lemmings-1 ascension. Clones was overly strict, see geoo's Lend a Helping Hand remix.
  
• Long tunnelling is expensive because bashers/diggers run out of power after X pixels, and need reassignment to continue. That can be desired or a design bug, you decide. As it is, we, as players, plan the route to tunnel where the terrain is thin.
  
• Reassignment is hard. Reassign too early, and you shorten your reach. Reassign too late, then the lemming will have turned, and you waste an entire skill and opportunity (you can't re-turn him forward). If you're sure about running out of power (like builders do in L1 after 12 bricks), consider shrugging.
  
• Builders don't hit their heads, only their feet. That's refreshingly lenient. Makes it easier to get out of nasty holes or nooks. I have a soft spot for your choice. The builder's head bonk in Lemmings 1 is the design oddity here, not your feet-only collision.
  
• Absolute time timit is a simple and clear way to end stalemates. I like it. I expect that there will be problems with it eventually, but everything else is more complicated.
  
• Allow resignation in matches between exactly 2 players/teams.
  
• Free-for-all games have no straightforward resignation without unbalancing play. That's a design problem for later.
  
• Avoid physics options. It makes level design hard when the level author can't control how his level will behave.
  
• Avoid pushing too many design choices to players. If you must, then also pick really good standards, so the players can still avoid design work. Usually for a given multiplayer level, there is one good set of options (how many diggers, what spawn interval, ...) and players will play that setting over and over.
  

UI:

• Please add hotkeys for skills, and make them remappable. geoo and I play Lix with one hand on the keyboard (accessing ~20 hotkeys) and one hand on the mouse.
  
• I forgot that directional select was still on, and missed some assignments.
  
• geoo and I remember that we weren't able to assign because the selection rectangle didn't appear even though the mouse was near a lemming. But I didn't catch this on video: geoo didn't record, and my instance was earlier this week.
  
• Middle mouse button is hard to press. It's hard for me to scroll. Instead, I zoom out and hope.
  
• Map the scrolling also to the right mouse button by default. Better, make it also remappable.
  
• I don't see bridge holes when I zoom out. But you can consider this a physics bug, not a visibility bug, and make your bridges thicker.
  
• On the contrary, I see bridge holes where there are none, because the zoom will hide the tiny white bricks.
  
• I forgot on which team I am, and, once, what color I play.
  

-- Simon

crispweed's game 0.0.1, I received binaries via PM.

Running client.exe in Wine 10.12 on Arch Linux. Arch is a rolling-release distribution and has no particular versions. Steps:

• Extract archive into new directory. I have client.exe, entry.png, ..., all in same directory.
  
• I copied the credential file 'credentials.bin' (received via PM) into the same directory.
  
• $ wine client.exe
  
• Client starts without problems. It presents a graphical window titled "SDL3 application" and asks me to enter my name.
  
• I type "Simon" without quotes, with this exact capitalization, into the blue text entry box.
  
• I press Enter.
  

After 0.2 seconds, the same window tells me: "Fatal Error: Client version not accepted by Server, please update your client."

Expected instead: Probably access to the lobby? Something else than version mismatch. I've used client 0.0.1 to which you've linked me via PM earlier today. My internet connection is up.

But at least, yes, it looks like SDL 3 Windows binaries will run well in Wine.

-- Simon

• Start composing a private message to another forumer here.
  
• Attach a file: Click Browse, pick a file from disk, and wait for it to have uploaded successfully.
  
• Click Preview.
  
• Click Preview a second time.
  
• Click Preview a third time.

Expected: The attachment is still ready to be sent. It should be listed below the composed message text, and its checkbox (where you pick which attachments you want to send) should be checked.

Observed instead: The attachment is gone.

• In the first preview (= after step 3), it's ready to be sent, as expected.
  
• In the second preview (= after step 4), it's still listed, but its checkbox is off. This unchecking is the bug, because we won't send an unchecked attachment.
  
• In the third preview, the attachment isn't even listed anymore under the text. And again we won't send the attachment now. This is technically correct because step 4 unchecked the attachment.

Now I had to send a second PM and look like a dunce who announces attachments and then fails to attach them. :-P I compose bottom up: Attach first, then type the text, then type the subject line, then add the recipients. It's near-impossible to forget it this way, and I investigated and found this repro. Happy Simon.

-- Simon

CE 1.0.1
NL 12.14

Clear Physics Mode shows the silhouettes of all gadgets in rotating colors. There is a global timer, and the color of the silhouettes is that timer modulo N in the circle of fully-saturated colors (red, orange, yellow, ..., cyan, pink, red).

Enough with that! I use Clear Physics Mode when details matter, and I don't want this distracting color clashing.

In 1.0.1 Clear Physics Mode, lemmings are dark-blue (0, 0, FF). Instead, make lemmings medium-blue (80, 80, FF). That's easier to see than dark blue (this alone will be an improvement!) and it will remain sufficiently different from the cyan athletes (0, FF, FF).

Now you can make gadgets dark green (0, 80, 0) and you won't step on any toes.

Pick other colors than what I propose, I'm happy to try other choices.

-- Simon

CE 1.0.1
NL 12.14 and other versions from years ago.
Wine 10.6

• Play any level.
• Fast-forward 5 minutes.
• Press and hold the 1-physics-update-rewind hotkey.
• During this rewinding,
  
  • start to right-click scroll (press and hold),
  • or zoom with the wheel (rotate several notches),
  • or select skills by hotkey.

Observed for right-click scrolling:

• You have a 50 % chance that the starting click for hold-to-scroll fails. If this click fails, the subsequent holding also fails, guaranteed. You have to release right mouse button and re-click-and-hold.
  
• Rewinding continues correctly, it doesn't depend on the scrolling's failure or success.
  

Observed for zooming with the wheel:

• For each of the mouse wheel notches individually, you have a 50 % chance that it will fail.
  
• Rewinding continues correctly, it doesn't depend on the zoom's failure or success.
  

Observed for skill selection by hotkey:

• The skill has a 50 % chance to get selected.
  
• Rewinding stops. It doesn't depend on the skill selection's failure or success; it always stops.
  

Expected: Rewinding always continues, and the second input always succeeds.

The 50 % probability is on small levels: Automaton Maintenance, or Save Our Souls. On big, laggy levels, the probability of failing increases. I fail to right-click scroll with 70 % or 80 % on Space Program 10,000 BC.

The probability of failure increases during in-game times such as x:x9, x:x8, x:x7. It's lower immediately after an internal 10-second savestate around x:x1, x:x2.

-- Simon

---

For the record only: WillLem's first reply (= reply #1) was for my old and wrong report:

Quote from: Simon

• Start a level.
• If it's a small level, zoom in until you can scroll.
• Scroll with the hold-to-scroll feature. E.g., map this to the right mouse button in NL's options, then scroll by holding the right mouse button.
• While you hold-to-scroll, press a skill hotkey to select a different skill.

Observed: You have a ~50 % chance to select the new skill. Otherwise, the skill key has no effect and the old skill remains selected. (The hold-to-scroll will always continue to scroll correctly, whether the new skill selects or not.)

Expected instead: The new skill gets selected for certain. (And the hold-to-scroll will always continue to scroll.)

NL 12.14 on Ubuntu in Wine 10.0
CE 1.0.1 on Arch Linux in Wine 10.6

The splat ruler lags the entire engine as long as it's active.

Repro:

• Play different levels in NeoLemmix for 2 hours. (I believe? Some preparatory step here is necessary because I can't repro it here on a fresh program run. Or do I have to screenrecord NL? I doubt it.)
  
• Play Turrican's level Space Program 10,000 BC v1.01, it's attached. It's large and it contains many special tiles. The file alone is 400 KB.
  
• Scroll around (with right-click scrolling) to get a feel for performance without the splat ruler.
  
• Tap the key for the splat ruler.
  
• Scroll around (with right-click scrolling) to get a feel for performance with the splat ruler.
  

CE froze for several seconds. If I hold (not merely tap) the key for the splat ruler in step 4, CE froze for 10 seconds, then stuttered at 1 frame per second. It was severe in my livestream from 2025-05-28:

Video: Splat ruler freezes CE for 5-10 seconds (70 seconds long, 4.4 MB)

NL/CE return to regular performance (= less lag) after we release the key. And if we play more/different levels afterward, the ruler doesn't dent the performance anymore there, even after it had dented performance on Space Program 10,000 BC.

Backgrounds on/off seems to make no difference. Can't test again now because step 1 is hard to guess/repro. So strange that it doesen't reproduce immediately after a fresh game run. So hard to guess what's going on internally ... it's such lag, and only on Turrican's level. And why do other levels run fine afterward even with the ruler?

Quote from: Guigui on June 02, 2025, 11:43:07 PMon my machine, the ruler is a bit laggy. When I press the key it appears correctly, but it stutters when I try to move it accross the screen. To move it, I better make it disappear, then reappear again elsewhere, not very handy.
Is it just me (running NeoLemmix on Ubuntu + Wine) or all NeoLemmix users ?

-- Simon

Players don't remember the exact rules of overtime and nuke. People ask why the overtime doesn't start, or why the nuke doesn't work. I'll treat these questions as bug reports against the nuke/overtime design.

In 0.10, if you nuke, you lose all remaining skills immediately, and overtime starts once you have 1 or more points. This is too complicated. The original design goal in 2010 was (a) to prevent people from nuking before anybody can score, and (b) to challenge other players to beat your score. Yes, the 0.10 nuke solves this, but pays too high a complexity cost (it has too much if-then).

In a 4v4 team game (of 2 teams), if the newbie nukes on your team, all players on that team lose their skills. That must become impossible. The obvious answer -- changing the nuke button into a majority vote, i.e., more than 50 % of the players on your team must push nuke for the nuke to activate -- would pile even more if-then rules onto the existing unrememberable nuking system. We can do better.

But the whole nuke-overtime system is a hard design problem to solve.

I'm contemplating to ditch the loss of skills altogether when you press nuke. Your nuke still triggers overtime, but you keep your skills and continue playing. In 0.10, it's strange that the loss of skills doesn't always go hand-in-hand with the start of overtime: When you nuke and have 0 points, you lose the skills, but overtime doesn't start.

It feels correct to keep the nuke as a game element. It allows you to force the remaining players to bring an almost-over game to a timely conclusion. I don't want to ditch it altogether.

None of this solves the confusing overtime, i.e., when exactly the overtime starts. This is still too confusing to explain to new players. The first hunch is to start overtime immediately when somebody scores 1 point from his own lix (to prevent accidental triggering by others who start near your exit), but that, again, wouldn't be elegant to explain. I have no good answer.

-- Simon

School quiz! This is about the rules of multiplayer Lix. Consider a 4-team game, with teams red, yellow, green, blue. A red lix enters an exit.

Question 1: The exit shows the team colors of red and yellow. Who gets points for the red lix?

Question 2: The exit shows the team colors of green and blue. Who gets points for the red lix?

Question 3: Is Simon happy about this? Why?

Question 4: What design do you think he will propose instead?

Question 5: Why is wrong to implement the design that you think Simon will propose, and what should he implement instead?

Answers to Q1 and Q2

Exit has red and yellow, red lix enters: The red team gets 1 point. The other teams (yellow, green, blue) get nothing.

Exit has green and blue, red lix enters: The green team gets 1 point, and the blue team gets 1 point, too. The other teams (red, yellow) get nothing.

Questions 3-5 don't get a spoiler immediately. I will eventually write down my ideas. But I'd rather not stir the pot before I've seen other people's opinions. There will be no failing grade here; everybody who answers will pass the course.

-- Simon

NL-CE 1.0.1.

Repro:

• Have a level with climbers, shimmiers, and a ceiling to which we can climb.
  
• Make a lemming climb the wall.
  
• Select shimmier in the panel.
  
• Near the ceiling (but before he reaches it), hover over the climber and click.
  
• You'll hear the sound for a failed assignment.
  
• Wait for the climber to reach the ceiling.
  
• The lemming will shimmy. Edit: You'll also hear the sound for a successful assignment.
  

Observed: Sound for the failed assignment in step 5 and successful shimmying in step 7.

Expected instead: No sound in step 5 when we click. (Reason: The click produces an effect, it queues a shimmier, therefore it was successful.) Still successful shimmying in step 7.

-- Simon

Hi,

I will livestream the candidates for Level of the Year 2024. The stream will be Saturday, May 10th, starting 16:00 UTC.

Help solve the levels in chat! (Unless you had already known the solution by heart before the stream.)

Stream will be at: https://www.twitch.tv/simonnaar

-- Simon

NL CE 1.0 in Wine 10.2 on Arch Linux.

• Start CE.
  
• Click in the main menu to go to a level preview.
  
• Wait for the fade-in to finish or not, it makes no difference.
  
• Press Esc to start the level preview's fade-out.
  
• Press Esc a second time, either before the level preview has finished fading out, or before the main menu has finished fading in.
  
• Watch the main menu fading out.
  
• See NL crash. Screenshot of the error box is in the attachment.
  

20-second video of the crash

Expected instead: No crash. I should get the same result regardless of how often I mash Esc during the fade-outs.

The program quits cleanly when I wait until the main menu has finished fading in before I press Esc the second time.

No data is lost. The program has already saved all user options and level results before it ever tries to quit from the main menu.

-- Simon

Hi,

∫tan x dx develops NeoLemmixSharp, a work-in-progress C# port of NeoLemmix.

I don't have a C# toolchain readily installed, therefore I can't tell about any details. Judging only from the size of the codebase (70 % to 80 % of Lix), it looks significantly advanced. But I can't tell if NeoLemmixSharp is already playable. I assume it's not yet, because you haven't announced it yet? I'll see when I get around to install a C# toolchain here on Linux.

Last year, I've met ∫tan x dx in Leeds. You told me about this project, and that we should eventually discuss some implementation details on the forums.

-- Simon

Here are questions from Tuesday, 2025-02-04 when I looked with WillLem at the NL-CE source.

Downcasting in Delphi happens with as, e.g., myDerived := myBase as Derived. This is the equivalent of Java's instanceof or C++'s dynamic_cast<Derived*>(myBase), where I get null if the runtime type isn't Derived. In OO design, it's hackish to force usercode to downcast. Thus:

Does Delphi allow to type-parametrize my own types? Or: What is the closest Delphi equivalent to C++ templates/Java generics? If we have two lists of replay entries (one for assignments, one for RR changes), I want one to be a list of Assignment and the other a list of RrChange, not two lists of Base (the base class of both Assignment and RrChange). Then my callers don't have to downcast.

What is the closest Delphi equivalent to std::span (a slice, a pointer-with-length)? E.g., my object contains the array [0, 1, 2, 3, 4, 5], I would like to return the view [2, 3, 4] to my caller without making a copy of the entries.

I expected the search function (find the assignment for a given physics update) in the list class, not in the replay manager class. The search works purely with that list and it's a natural operation for that list.

The search has at least one near-duplicate.

When your list (of assignments, of ...) is always ordered, you can find elements by binary search instead of by linear search. But this doesn't matter when you have 30 elements in the list and you search it only a few times per second. And this (5 to 100 assignments and RR changes) is the extent of most Lemmings solutions. Don't prioritize rewriting the searches to binary search.

-- 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

Dosbox too loud?

mixer master 10:10

Execute this line within Dosbox before you run your game in Dosbox.

E.g., put it in your configuration's autoexec section (see the bottom of dosbox.conf), or type it at the prompt before your game.

What it means

"master" means Dosbox's master mixing device. This affects all sound sources in Dosbox, e.g., Sound Blaster, PC Speaker, ...

"10:10": The two numbers separated by a colon define the two volumes for the two audio channels (left and right). Practically always, you want to put two equal numbers separated by a colon. But you have the option to put different numbers.

You can give each number in one of two formats:

• You can give a number unadorned, then Dosbox interprets the number as a percentage (popular but nonsensical), where 100 is full scale (the sensible maximum without clipping) and 0 is silence.
  
• Or you can write d- in front of the number, then Dosbox interprets your number as negative decibels from full scale. Here, d-0 is full scale, and d-inf is silence.
  

Fractional values are allowed: mixer master 5.5:5.5 is a volume between 5:5 and 6:6, even though Dosbox will print it rounded to integer. You can put several digits after the decimal point, e.g.: mixer master 1.23:1.23

The percentages really mean the following:

mixer master 100:100	means  mixer master d-0:d-0	(full scale)
mixer master 10:10	means  mixer master d-20:d-20	(a nice volume)
mixer master 1:1	means  mixer master d-40:d-40	(pretty quiet)
mixer master 0.1:0.1	means  mixer master d-60:d-60	(almost silent)
mixer master 0:0	means  mixer master d-inf:d-inf	(absolutely silent)

For −x dBFS, percent(−x) = 100 ⋅ 10^(−x ÷ 20).

For p percent, dBFS(p) = 20 log₁₀(p ÷ 100).

Miscellana

Type mixer without any arguments to see the current volume.

Put /noshow after the command to suppress Dosbox's immediate printing of the new volume levels, e.g.: mixer master 10:10 /noshow

You can choose volumes louder than full scale, e.g: mixer master 120:120 Or: mixer master d+2:d+2 But these volumes clip. You should first consider other means outside Dosbox to make the overall volume louder.

Sources

• Own experimentation in Dosbox 0.74-3
• Topic "mixer command" on vogons.org
  

-- Simon

2017 -- 2018 -- 2020 -- 2022 -- 2023 -- 2025

---

UI

Scissors mouse cursor: Change the mouse cursor to scissors when a click will cut the replay. I tried this, and a full scissors cursor was annoying, it made it hard to point at things. Instead, it's now done in 0.10.30 as a small sidekick to the cursor, Github #400.

Add an icon near the mouse cursor that means insert mode. There is no obvious icon for inserting. Done in 0.10.30, source of the idea.

Explain gadgets on mouseover (catapult, steam, trap). This is good newbie onboarding. Newbie onboarding is important; bad UX confuses newbies and they never play again. Done in 0.10.30, Github #494.

Add flying shovel/jackhammer for basher/digger who hits steel. Done in 0.10.29, Github #496.

Upgrade Allegro DLLs in the Windows release to 5.2.10. I forgot why I wanted that. But it's the newest version, updating is good anyway even if I don't remember why.  Done in 0.10.29.

---

Physics

Fix several of these bugs:

• #47 The ❤-Bug for Basher/Miner. When a basher or a miner turns at a blocker, the basher/miner won't consider the new terrain that now blocks his path. The basher/miner can clip through walls. Miners can clip through floors.
  
• #491: Jumper clips upward through terrain
  
• Basher (after lowering) clips forward through terrain. This is the same underlying bug as the ❤-Bug. Again, we put unexpected terrain in front of the basher, and the basher clips through that terrain. Here, we didn't use a blocker; we used the basher's down-stepping.
  
• Miner hovers in mid-air when he mines along a builder staircase. You can assign blocker to cancel in mid-air. The lix will then fall and revert to walker.
  
• #471: Platformer is inside his first brick. When you assign jumper at a specific time, the lix will be stuck and not jump.
  
• Remove unglitching out of wall: Ascenders travel inside the vertical wall. This requires extra code in tumbler.d to move the ascender out of terrain when something is about to fling an ascender. The ascender should take a better path outside the wall.
  
• Runners Bypass Exit, Walkers Exit: A moving lix looks for exits or triggered traps only at the end of her entire physics update, not during her path. We want to look during her entire path instead.
  

Write a manifesto on Lemmings physics. Never should a lix willfully enter terrain, unless we override it explicitly, e.g., for ascender. Never should a lix hover, unless we override it explicitly, e.g., for builder. Replace some physics primitives, e.g., scan at (x in front | y up), e.g., move ahead unconditionally, ... with higher-level commands: "walk ahead" should mean { move ahead iff you're standing on floor and there is air ahead }. Rewrite some physics in these higher-level terms. See how much of the physics will break. We can still decide if all this is too aggressive.

-- Simon

Hi,

Lix test executable for many mouse buttons

This adds support for more than 3 mouse buttons.

Do you have a mouse with extra buttons? Please try this (put it into a full Lix tree, e.g., from a fresh download). Bind your extra mouse buttons to some skills or functions. Will the bound mouse buttons work during play?

Silken, please turn off your external mouse-to-keyboard binding tool for this test. Lix should really see you mouse buttons as-is, not as keyboard keys.

This doesn't yet export the new bindings to the options file. As a result, this version of Lix doesn't remember the extra mouse button bindings after you exit and restart Lix. Before we can merge this, I'll have to decide how exactly to export/import mouse button bindings from the options file.

-- Simon

I've toyed with the zoom behavior in Lix 0.10.26.

Existing rule from Lix 0.9 and Lix 0.10: Generally, preserve mouse-on-land when you zoom. But if you can move the camera to see more land (and less void, i.e., less of the dead area outside the level boundaries), always prefer to shift more land into view over preserving mouse-on-land.

Experimental rule A: Generally (and more often than before), preserve mouse-on-land when you zoom. Only shift more land into view if the camera would center on a void pixel after the zoom. Or, worded in a different way: Eventually, we still shift land into view, but the camera will allow some void (up to 50 % each of left/right/top/bottom may be void) before the camera prefers more land.

Bonus effect of rule A: When we zoom in, we zoom into the mouse cursor, which enlargens (or at least keeps the same amount of) the land on all four sides of the mouse cursor. This can never run into the situation where rule A wants to shift more land into view. (Only zooming out can shift more land into view.)

Downsides of rule A: When we zoom out, the land isn't necessarily anchored at the panel at the bottom any more. I can try to change the rules and re-anchor, but it will come at the cost of less mouse-on-land preservation.

See it animated

Both of these gifs are under this experimental rule A.

• In the 1st gif, the zoom preserves the mouse-on-land completely.
  
• In the 2nd gif, the mouse is close to the corner of the screen. Here, preserving mouse-on-land would eventually shift too much void into view, and rule A tells us to move the camera to avoid more than 50 % void at the left side of the screen. (This can only happen when we zoom out, never when we zoom in.)
  

Test it yourself: Put lix-0.10.26-halfvoid-camera.exe into your 0.10.26 tree, or build branch camera from my unstable repo. Either way, you'll get experimental rule A.

What do you think? Is this useful or annoying?

Do you want to allow even more void, to preserve mouse-on-land even more often?

When you zoom out so that we could re-focus the camera to show the entire level at once, should we refocus (instead of preserving mouse-on-land) to show the entire level? Or do you prefer to scroll yourself to see it all?

-- Simon