Dullstar, I haven't heard from anybody else with a Mac. Is it time you dust off yours? >_>

In #431 are my first ideas to start debugging; if you're fine with github, we can continue to post stuff right in that github bug.

-- Simon

It's a title bar in the Curve theme from Xfce 4 on Linux. No particular settings for VLC.

Dekstop stuff must be reasonably dark, moderately small, completely static (buttons or scrollbars shall not roll in and out) and overall nonintrusive.

-- Simon

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

Swim Team Rush v2: Backroute, abusing a finnicky start to save time.

Stop Blowing Up v2: Looks sensible, but still feels too comfortable near the end and loses only 2, not 4.

Natural Born v3 (higher pole), thanks for the hint. I haven't found a solution, but I have new ideas to try later. Interesting things will happen.

Tomato Watcher: No worries!

-- Simon

It's a screenshot of VLC playing the attached video. It's not a direct screenshot of NL.

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

Replay Verification

You can run Lix noninteractively on a directory full of replays:

• lix --verify mydir will tell you, for each replay, whether it passes its pointed-to level. Finally, Lix tallies passes and fails.
  
• lix --coverage mydir does everything from --verify mydir, and will also list the uncovered levels, i.e., levels in a level directory into which at least one replay pointed, but that themselves had no passing replay.
  

It's really a single feature with two forms of invocation. You want --coverage when you expect most levels to be covered by your replay collection and want to find omissions. Otherwise, you want --verify, which also makes sense for individual replay files.

The origin of replay verification: Around 2010-2013, geoo wanted to maintain online highscores for Lix. He considered to write a server based on Django, let people upload replays, then have the server run Lix in the background to verify the replay.

Thus, from day one, I saw a clear need to make replay verification run with as little of Lix as possible. I would still have to initialize graphics to load tiles, but I wouldn't be able to run the graphical user interface on the server. Everything had to work from the command line and print results as text output.

In the end, we never had online highscores. Nowadays, I don't even want them, they're extra stuff to maintain. There are enough other juicy objectives for Lix development in the next few years. But even without online highscores, the replay verification enjoys fast runtimes. It doesn't have to maintain a graphical land, only a physical land.

The biggest use case of replay verification is not competition between level players; it's tooling for level authors to verify pack solvability. I don't remember when exactly we realized this use case. Maybe we always had it in mind and it merely became the main use case over time.

Fully covered packs serve me as physics test cases: Whenever I touch physics code, if all replays pass, then most likely, I haven't changed physics.

I believe we had cross-pollination between Lix and NeoLemmix about replay verification, but I forgot the details. Most directly comes to mind: I'm still worrying how to associate replays to levels. Neither (level path only) nor (NL's level ID only) is perfect. And we eventually must start classifying replays in the proof collections: Intended solutions, accepted alternatives, backroutes, ...

-- Simon

Thanks for the feedback! Yes, that spoiler said exactly what I figured it would probably say.

Next Hopeless stream will be in a few weeks. I'll be busy this weekend. Next week, geoo will visit me for a few days, and there is already a multiplayer session.

-- Simon