Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - Simon

#1
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
#2
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 log10(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


-- Simon
#3
Lix Main / 2025 Roadmap
January 18, 2025, 01:54:14 AM
2017 -- 2018 -- 2020 -- 2022 -- 2023 -- 2025



UI

#400: Scissors mouse cursor: Change the mouse cursor to scissors when a click will cut the replay.

Add an icon near the mouse cursor that means insert mode. There is no obvious icon for inserting. See: Old post with icon ideas, even though these ideas were for a panel button, not for something at the mouse.

#494: 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.

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
#5
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
#6
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
#7
Preformatted inline text with the "tt" tag worked in SMF 2.0, but fails in 2.1:

example

With preformatted text, I mean text in a fixed font that clearly disambiguates lowercase-L from uppercase-i or the digit one, uppercase-o from the digit zero, etc. That's common for code snippets and for command lines that I want others to run.

There is the "pre" tag, which typesets the text preformatted indeed, but it sets the preformatted text into its own
line,


and I don't want
that.



There is "font=Courier New", which works inline, but it has two disadvantages: It's unwieldy to type by hand, and it doesn't produce preformatted text independent of systems, because Courier New isn't necessarily installed everywhere. E.g., in Firefox on Linux, I get a serifed font from "font=Courier New". I want logical formatting, not a specific font.

(In the admin panel, I found a grab-bag of BBCode tags that one can activate or deactivate, and "tt" looks activated there already. I didn't see anything related there other than "tt" and "pre".)

How do I typeset preformatted inline text?

-- Simon
#8
Hi,

This October, I'll visit the UK.

I'll be up for a forum meetup on Saturday, October 26th, 2024 around the area of Manchester or Leeds.

There is nothing specific planned yet for that Saturday, October 26th. I'm staying with WillLem. I expect WillLem or Flopsy to pipe up here soon, but I'm sure others from the UK have good ideas, too. Where should we meet? One loose idea is to meet in Leeds where the UK forumers met in August 2023; after all, many of you had the chance to come together there.

I have the Sunday, October 27th, free, too, and will fly back to Germany on the following Monday. I believe the Saturday is easier for whoever can spend only a single day, therefore I'm proposing to meet on Saturday and keep the Sunday as an optional second day.

Edit after Flopsy's 1st reply: Reason for why I am in the UK in the first place: WillLem, Flopsy, and I will take a road trip to Dundee, to see the Lemmings statue and the DMA office. The meetup on Sat, Oct 26th is after we return; we'll then be back in the Manchester/Leeds area.

-- Simon
#9
Edit Simon: Split off topic: Some ideas.

DanielOakfield wrote:

Visual alert on a match when one of the players has mathematically won, i.e. when the total number of lix still out is not large enough to make win whoever is losing (Team A 100 in, Team B 50 in, and only 49 total lix still out), sometimes we keep playing because we are too focused without realizing the match is actually finished. Maybe it's a matter of changing the color of the winner to green.

Flopsy then wrote:

While it seems like a great idea in games with more than 2 players, I think largely enough we only resign on a map in 2 player mode where it is clear there is not enough Lixes left on the map to overtake the leading team.
I think this feature probably never existed because a lot of the current community are very advanced in Mathematics and we usually know when we are beat and don't need the Lix engine to tell us we are beat.
Usually when we play maps with more than 2 players, we play the map to the end regardless of whether it is clear someone has won. We only leave the match early if someone has disconnected and the overtime timer is too long to wait for the nuke to trigger.


-- Simon
#10
Lix Main / Jumper Clips Through Horizontal Bar
August 18, 2024, 07:57:45 PM


Lix 0.10.26

The green lix (player ID 0) is already a runner-jumper-floater. Here, she becomes a jumper:
! 828 0 ASSIGN_RIGHT=JUMPER 0
Besides this jumper, green assigns no other skills near this time.

Expected: The green lix should not clip through the steel bar because there is at least one full horizontal row of air below the bar. She should bonk against the bar and fall down onto to the big triangle.

Observed: The green lix clips on top of the steel bar.

Replay: 2024-08-18-205947-Simon-6p.txt

This bug on github: Jumper Clips Through Horizontal Bar #491

-- Simon
#11
Split off Simon blogs.

Modern Lemmings

I like to call Lix's/NeoLemmix's predominant playstyle "modern Lemmings" or "contemporary Lemmings". By that, I mean: Solving puzzles in engines that remove execution difficulty and help me turn my imagined solution into level-solving skill assignments with little hassle.

But that name is not precise. It's merely the dominant playstyle these days. There are many more playstyles. Purely by gut feeling, I'd order the playstyles from most popular on Lemmings Forums to least popular:
  • Singleplayer puzzle solving with in-game tool* assistance
  • Real-time competitive multiplayer
  • Real-time singleplayer: pause-free challenges, RTA speedrunning
  • Out-of-game tool**-assisted plays: TAS, research
(*) In-game tools: Frequent pausing, advancing individual physics updates, rewinding mistakes, asynchronous solving in skill-inserting mode a.k.a. the blue R, and assignment tweaking a.k.a. in-game replay-editing.

(**) Out-of-game tools are the typical TAS emulators with savestating, rewinding of the entire emulated machine, input listings, and RAM investigation.

I haven't mentioned hand-editing replay text files. It feels like it's both in-game tooling (the games take human-readable replay files) and out-of-game tooling (it's done in a text editor). In any case, it's so rare that I'll ignore it here.



There is no clear and precise name for the most popluar playstyle, i.e., for singleplayer puzzle solving with in-game tool assistance. I'm tempted to continue to call it "contemporary Lemmings" at the cost of imprecision. After all, each of the above four wildly different playstyles from the above list is a distillation of 1991 Lemmings's mixture of ideas. Each playstyle relies on more modern and contemporary tech than we had in 1991.

-- Simon
#12
Hi,

Replay Insert Mode ("blue R") silently overwrites

namida, you closed the original topic, but you've never declared this fixed nor wontfix.

You consider this data loss. I agree.

You wrote that don't want elaborate fixes or physics changes; fine with me. WillLem offered help, you haven't replied; also fine with me, I assume you'll find something reasonable yourself.

Considering that you care about the data loss, you should at least chose one of the un-elaborate resolutions:
  • Refuse all same-frame assignments.
  • Refuse only to different lemming. Allow overwriting same lemming.
  • Allow noisy overwriting, i.e., tell the player that he lost his old data.
  • Allow silent overwriting and let people run into unnoticed data loss.
-- Simon
#13
Hi,

after Mindless released Golems on the forums here, he posted his ideas about what to include in a savestate, what to compress, ... I got inspired to investigate Lix rewinding performance. Over several evenings, I've finished the following three improvements:
  • Savestate only the mutable half of the world
  • Choose graphical frames of hatches/exits/... only when drawing
  • Refactor away from overuse of shared pointer to world
1. Mutable Half: The world in Lix consists of terrain, players, their lix, hatches, exits, traps, ..., and I used to keep everything in savestates. But some parts of the world never change: Water never changes. Fire hazards never change. An exit has some state (e.g., ownership, the red player gets points) but this state never changes during play. The initial value of the overtime never changes.

I've separated the world into a mutable half (land, lix, triggered traps, ...) and an immutable half (hatches, exits, water, ...). I copy only the mutable half into savestates. When I load a savestate, I attach the loaded mutable half to the existing immutable half, and that's the new world. This makes the savestates smaller in memory and reduces allocations. Each gadget (hatch, exit, trap, ...) is a heap-allocated class object. To track one in a savestate, we must deep-copy it, and it helps when we only have to save some of the gadgets, not all.

The name "half" is euphemistic. The mutable half is still the lion's share with the uncompressed land bitmap, the physics map, ..., and I didn't look into compression.

2. Graphical Frames: Ostensibly, exits still change over time because they animate. This animation has no bearing on physics, which is a strong argument to keep the exit in the immutable half of the world. But if the exit never changes, it can't keep track of its current animation frame.

The solution: During drawing, I tell the exit the current tick (physics update number) and the exit computes its animation frame from first principles. The drawing method ferries the arguments the to the exit.

Instead of incrementing the frame each tick and resetting the frame after reaching the end, we compute the modulus tick % animationLength. Naively, taking the modulus of integers is slower than adding and comparing integers. But there are performance benefits: We track less state in the exit now, which makes the exit smaller in memory by itself, and it makes all savestates smaller because exits can now be in the immutable half of the world.

Most importantly, non-drawing physics updates don't have to compute animation frames for exits anymore. When we aren't going to draw the results of some physics updates, we've saved many virtual method calls: One virtual call per gadget per update.

After all, we have our direst need for performance during singleplayer rewinding, during networked games with many players, and during mass replay verification. All three cases compute several (or all) physics updates behind the scenes. E.g., rewinding loads a savestate that is older than the target tick, then updates physics forward from the savestate until we're at the target tick.

3. Ditch Shared Pointer: A shared pointer to the world means two levels of indirection:
  • Usercode holds a shared pointer by value.
  • Each shared pointer points to the single reference-counting storage.
  • The reference-counting storage points points to the payload.
Compare this with unique resource handling (one indirection) or putting the world struct by value inside your world-handling code (direct access for the holder, and still one indirection for other parts of the physics).

In 2016, when I wrote D Lix, I chose the shared pointer for all holdings of worlds (the current world and for the savestated worlds) because I wanted easy savestating. The same world could appear several times in the savestating cache. I used the same type (shared pointer to world struct) everywhere. The problem was in the current world, which was also a shared pointer to a world struct. All physics that referenced the world (instead of, e.g., only the lix at hand) had to dereference the shared world pointer many times over.

Solution: Now, I hold the current world by value. After all, the world struct is less than 300 bytes; there is a lot of indirection in the world by itself already.

Sidetracking: I've also removed the shared pointers from the savestating cache. That wasn't necessary to change; it wouldn't have mattered for performance here. For now, I've resorted to manual management of copying/disposing between the current world and the savestates. To do what I really wanted, I need move semantics. D supports C++03-style RAII, but not yet the value-type-based rule-of-five resource handling that became popular with C++11. I want to write my program in the mathematical union of all the programming languages.




Overall Benefit

Mass replay verification is 3.5 percent faster. The 1077 replays from the replay collection take 18.9 seconds on my Intel i5-6600 3.30 GHz. Before, in the stable Lix 0.10.24, they took 19.6 seconds.

It can't be from the smaller savestates because mass replay verification doesn't generate savestates. It must be either from holding the current world by value or from from skipping graphical frame calculations and avoiding their virtual calls. I can't tell which of the two improvements it is, I have only measured all three optimizations together.

During singleplayer, I've kept the full 60 fps more often during hard rewinds when Lix 0.10.24 would dent to 55 or 50 fps. This is hard to quantify because it depends on the level. It's also hard to guess which of the three optimizations played the biggest role here. The bottom line is: The benefit is at least measurable during graphical play.

We'll see if and how much it helps in practice, after I release this in Lix 0.10.25. :lix-smile:

-- Simon
#14
In May, after work, I had a colleague try Lix on his notebook computer. I believe we had a mouse, not only the touchpad. He had played Lemmings ages ago.

Any Way You Want: No problem. A few died, but that's expected. You must save 1/10, he saved several.

Pipe Dream:

  • Unclear what to do. The exit isn't visible at the start of play.
  • Once, he bashed out of the left of the map and had to cancel or restart.
  • He assigned some bashers in the open, without a nearby wall. (This is OK, I expect this with new players.)
  • He repeatedly bashed facing away from the wall instead of facing towards the wall. I told him how to do it right, he said "yes", but his success rate didn't increase.
  • He ran out of basher! Pipe Dream gives you 20 bashers. You need at least 6 to pass. If you squander 15, you're stuck, but you don't know it yet.
For the next Lix release 0.10.24, I'll increase bashers from 20 to 50. Unsure if the other findings are a huge problem. Or, if they are: Unsure how to fix them.

In hindsight, even the L1 devs were wise and gave you 50 bashers in You Need Bashers This Time.

I'm reporting this like a usability test here, and while it produced usability findings, the session wasn't planned as a usability test. In a proper test, I should explain as little as possible. Here, I explained things along the way, which can steal attention.

-- Simon
#15


I found this in the current Lix 0.10.23, but this bug must have been in the physics forever, at least since I've presented C++ Lix in 2009 to the Lemmings Forums.

Expected: When you assign blocker to a miner, the lix starts blocking.

Observed: Timed well, on the right terrain, the blocker assignment cancels the miner and makes the lix walk again.

This cancelling works with a batter assignment (instead of a blocker assignment), too.

Explanation: The floor must be shaped like a builder bridge. In the physics, the builder bricks are 2 hi-res pixels high, i.e., 2 units of distance. Naively, this is too high a drop for the miner to continue, therefore the miner has leeway in its code to continue mining along such a bridge. To trigger the bug, assign blocker while the miner is hovering over an air pixel, i.e., while the miner's foot is at Foot1 or Foot3 here:

                          Foot0
                        +--+--+--+--+--+--+--+--+--+--+--+--+
                   Foot1|  |  |  |  |  |  |  |  |  |  |  |  |
                        +--+--+--+--+--+--+--+--+--+--+--+--+
             Foot2      |  |  |  |  |  |  |  |  |  |  |  |  |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       Foot3|  |  |  |  |  |  |  |  |  |  |  |  |
            +--+--+--+--+--+--+--+--+--+--+--+--+
 Foot4      |  |  |  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+--+--+




Bug! Bug! Bug!

-- Simon
#16
Lix 0.10.23 will release today, and for this release, I'll move some multiplayer levels around, as follows.

For each player count (2p, 3p, ..., 8p), I've looked for authors who have built only a single level for that player count. This produced single-level folders. For Lix 0.10.23, I'll merge the levels from single-level folders into a new folder other/ under that player count.

Example: Yung has built only a single 2-player level, teamattack.txt, and I've moved it from 2p/yung/ to 2p/other/.

Full list of levels that moved

2p/yung/teamattack.txt
2p/nessy/theabandonedsanctuaries2p.txt
3p/minimac/hellinacell_3p.txt
3p/dominator101/rescuedouble3.txt
3p/kingshadow/rescuereduction3p.txt
4p/willlem/letpandemoniumcommence.txt
4p/dominator101/rescuedouble4.txt
4p/nessy/theabandonedsanctuaries4p.txt
5p/minimac/hellinacell_5p.txt
5p/dominator101/rescuedouble5.txt
5p/ichotolot/staircasesofsorrow5p.txt
5p/proxima/twelvebar5p.txt
6p/raymanni/rainbowroad.txt
6p/dominator101/rescuedouble6.txt
6p/nessy/theabandonedsanctuaries6p.txt
6p/proxima/twelvebar6p.txt
7p/steve/elevator_7p.txt
7p/minimac/hellinacell_7p.txt
7p/dominator101/rescuedouble7.txt
7p/kingshadow/rescuereduction7p.txt
7p/amanda/snatched7p.txt
7p/ichotolot/staircasesofsorrow7p.txt
7p/raymanni/thefroghotel.txt
7p/proxima/twelvebar7p.txt
7p/anonymous/viciouscircleofcats.txt
8p/raymanni/followthethread.txt
8p/dominator101/rescuedouble8.txt
8p/nessy/theabandonedsanctuaries8p.txt

I wasn't sure if we should also merge two-level authors or even three-level authors into other/. I haven't done it for now; I've only merged the one-level authors at each player count. You're not stuck one way or another; if you build more levels, I'll move you back into your own folder. :lix-smile:

I'm not sure if sorting by author is useful. It's merely the obvious method, similar to how we sort singleplayer levels into level packs, which typically have one author. See also the 2019 topic: Organizing Multiplayer Levels: Tag System.

-- Simon
#17
In Future of NeoLemmix development, Crane wrote:

Quote from: Crane on March 06, 2024, 04:07:59 PM
One thing I would like to do one day is get NeoLemmix working on the Raspberry Pi.

It is a bit of an undertaking though because besides porting the source code over to the Free Pascal Compiler, [...]

That's interesting -- I've always thought that NL builds (1) only on Windows, (2) only for Windows, and (3) only with certain compilers/IDEs. You sound like none of these 3 restrictions need be set in stone, and removing the 3 restrictions is a medium-scope project for an experienced Pascal/Delphi developer.

Background: I spent one night on installing a Delphi toolchain in Wine on Linux and failed because the graphical IDE wouldn't run. I wouldn't mind trying again, and trying it with different versions of the Microsoft toolkits that the IDE needed.

But even better would be to build NL on Linux from the command line without installing any fat IDEs.

It's okay if it generates Windows binaries (i.e., we crossbuild from Linux to Windows) because the Windows binaries run well in Wine. Linux binaires would of course be nice, but they aren't essential yet. It's also okay if I can't change the GUI dialogs without installing an IDE or a graphical GUI editor.

-- Simon
#18
General Discussion / geoo visits Simon, May 2024
May 18, 2024, 04:45:00 PM
Hi,

geoo will pay me a short visit next week. He'll arrive on Thursday, May 23, and leave on Saturday, May 25. With only two days, there isn't much time, but I'm looking forward to:
  • Discussing Lix development. What is important? Which bugs are most nagging?
  • Discussing Lix physics. We have some long-open small physics oddities. Let's fix at least some for 0.12, whenever that will release.
  • Testing a top-secret work-in-progress feature. Well, it's only semi-secret because I'll give you a hint:
To get into the mood, here's our topic from the February 2023 visit.

-- Simon
#19
NL 12.12.5.

1. Build a level pack including some talisman levels.
2. In NL's options, name yourself X.
3. Cover your levelpack including all talismans with replays played by X.
4. As X, mass-verify your replay collection.
5. In NL's options, name yourself Y.
6. As Y, mass-verify your replay collection.

Expected: Identical output in steps 4 and 6 for each replay.
Observed: Different output in steps 4 and 6 for each talisman-winning replay.

When Y mass-verifies replays from X, then NL will still test for pass/fail correctly. NL will print pass/fail correctly to the screen and to the results file (the text output file in your NL worktree). But NL will refuse to tell Y whether X's replay achieved a talisman. NL will print talisman-winning replays as plain wins.

I understand that Y doesn't want X's talismans recorded in Y's personal statistics, but Y doesn't want X's plain wins written there, either. Then why does NL still print win/loss, but not talisman, during Y's mass-replay verification of X's replays?

Experienced NL designers/level maintainers: When you co-author a pack, or when you inherit a pack with talismans from another maintainer, how do you work with his replay collection? Do you mass-rename the player to yourself in the covering replays before you mass-verify the replays? Especially co-authoring a pack sounds impossible under this NL behavior without constantly renaming the players in all those replays.

-- Simon
#20
Lemmings Main / DOS Game Club on Lemmings 1
March 15, 2024, 02:36:01 PM
Edit 2024-04-10: It's released; download here:
DOS Game Club's Lemmings 1 podcast episode
Runs for 2 hours and 9 minutes, as MP3, 148 MB.




Hi,

the DOS Game Club is an online community. Each month, they pick a DOS game to play. Afterwards, they record a podcast (~1 hour) about it, and publish it on their website.

The next podcast will be about DOS Lemmings 1, and I'm invited as an expert. Most likely, we'll record the podcast next week. Let's make sure that I don't forget important topics. Thus:

What's important about DOS Lemmings 1?
  • L1 was the big hit for DMA.
  • I should know the Lemmings History essay.
  • DOS L1 was one of the main ports, with SNES L1 and Atari L1. The original L1 was on Amiga 500.
  • Lemmings 1 in particular serves as the inspiration for most other Lemmings-trademarked games and fan-games.
  • Pure singleplayer (no multiplayer) on DOS.
  • Passwords, unlimited retries, no lives. Still, if you got stuck, you were stuck on a single level.
  • Execution and puzzles went hand-in-hand. E.g., it had All or Nothing, which becomes trivial in modern engines, and even in DOS L1 when you know the cursor-flickering trick.
  • Even the L1 editor manual (on Mike Dailly's site, LF forum topic) tells you: You can hide your exits.
  • The quirky soundtrack and the unused Music from TV show themes.
  • Physics oddities. It's possible to solve They just keep on coming with 0 builders by disabling steel with blocker trigger areas.
What levels from DOS L1 were iconic?
  • No Added Colours or Lemmings
  • It's Hero Time
  • Cascade, with 100 % saved
  • Hunt the Nessy, the quintessential builderfest
  • The Great Lemming Caper
  • Postcard from Lemmingland
  • Save me, it's the hardest level
  • The VGASpec levels: Beast, Menacing, Awesome
What's important about contemporary Lemmings culture?
  • Custom level design!
  • It's common to release ~100 levels as a standalone pack, like Lemmings itself did.
  • We send each other our replays to improve the puzzles.
  • Some levels are about one specific idea. Other levels are open-ended but can still be difficult.
  • Engine design, tileset design. You can get involved in other ways than level making or solving.
  • NeoLemmix is most popular.
  • Lix has single- and multiplayer.
  • 100 % focus on puzzles (ideally, 0 % execution) in NL and singleplayer Lix.
  • Lots of tooling: Rewind, replay tweaking, insert mode, ...
  • Still, ideally, your level should never need the powerful tools. Be lenient where you can.
  • We tell newbies: Don't hide traps! Don't hide anything!
  • SuperLemmix, because it points to other elements of singleplayer than pure puzzle solving.
  • Vanilla Lemmix? Lemmini? Cheapo? CustLemm? Patrick, one other participant in this podcast, has built a 10-level pack for CustLemm -- and, for sure, included a level with hidden exits, because that's fair game in 90's-style Lemmings 1.
  • Community work to find min-skill DOS L1 solutions, DOS L1 challenge solutions, ...
  • Martin Zurlinden's pack is an early quality custom pack of 30 levels, inspiring others.
Even if I'm not 100 % knowledgeable about something, it's fine: The club regulars are good researchers and acheologists. E.g., for their Jazz 1 podcast, they dug through the developers' past, had quirks to tell, and even found my table about Jazz 1 versions and the 2021 GOG patch.

-- Simon