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

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.

-- Simon

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

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

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.

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

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

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

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

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

NL doesn't tell the player during play how to cancel the replay. This confuses random reople on the internet. You don't always have the luxury of people reporting their confusion here.

I believe that this is far more annoying for new users than most experienced players assume.

---

Example from 2022-02:
Bug: Uncommanded clicking

Dave4 creates an account on LF specifically to report this bug. This report was his first post.

Dave used to work around this by exiting NL entirely, then restarting NL.

---

Example from 2023-06:
Join development team

yoyoz files the automatic replay as a bug, and has already changed the NL code to fix it: "There is a problem when you click on restart button: Same actions are replay. I have fixed it. But for the moment, i havent found where fix when you restart the level with the menu screen."

---

Example from 2023-07 that I found today:
https://www.twitch.tv/videos/1878712696?t=0h17m23s -- watch from 17:23.

Saxdude26 fumbles in the NL ingame UI and level selection UI for 3 minutes. He restarts several times, which doesn't solve his problem. He saves the replay to disk, which doesn't solve his problem. Eventually, he goes to the options (dialog doesn't show on stream) and (presumably) disables replay after backwards frameskip. That's his solution -- he cuts highly useful things. Ends with: "Do I like having replays? Yes. Do I like that it keeps replaying when I restart the level? No."

He hasn't clicked air in those 3 minutes. He has clicked practically every panel button, but never the air. Why should he click air when NL doesn't nudge towards clicking air?

---

Writing these down because WillLem is considering ingame text over status panel for Don't exit on losing all lemmings.

-- Simon

Rant.

When your lemmings die, play exits to postview, and you can't rewind. Many people have reported this bug, and it's still open 3.5 years after.

2020: WillLem, Simon, Proxima, Dullstar, mobius
2023: Crane, Simon, WillLem, Proxima, Dullstar

This is particularly nasty because you don't see it coming. Oh, split-second too late releasing the finger off timeskip? Tough luck, plow through the menu, start play from the beginning and fast-forward to where you want to go. Oh, you want to go to almost the end? Better take extra care to not run into the bug a second time!

Solution is to stay in play, but prevent further physics advances. It's only okay to exit here if I've already won, or if I've nuked.

I'll paypal 200 Euros to whoever fixes this (Edit 2024-05-15: WillLem got it and donated a share to namida), releases code and binaries, and prods namida to include it upstream (whether successfully or not). Never exit an unsolved unnuked level until I exit manually. Caveat: If namida gets the 200 Euros, 100 of them must go to LF hosting.

Every time:

• You promise people to play their levels.
  
• You finally find an hour of free time, and load the level in NL.
  
• You play for 3 minutes.
  
• You run into such a UI problem and resign.
  

It's beyond me how anybody can play under this bug without tearing all hair out. And this sounds familiar: I feel the same about the unfixed zoom bug. The workaround to the zoom bug is to never zoom, and instead play fullscreen on the biggest monitor you can buy. Yes, play fullscreen ... until you run into the exit-on-losing-lemmings bug.

There is also the slippery right-click scrolling, but that is hard to debug (happens under Windows or only under Linux) and hard to fix (freeze the OS cursor?). Again mitigated by big monitor. Not that big of a deal as the other two bugs (exit on losing all lemmings, and the zoom bug), but it aggravates the zoom bug because the zoom bug breaks the alternative scrolling via zoom-out-zoom-in.

Not sure what is 4th-most agonizing bug.

I've told Flopsy in IRC: NL has improved a lot since 2014. Yes, it has. It merely still has a few bugs that lead to dents in office furniture.

I understand that it's hard to make software bearable. I should write about and debug the laggy mouse cursor in Lix. Even the Allegro 5 example for endless mouse movement has that bug. Looks like it's worse on Linux than on Windows. I'm surprised nobody has ranted about that in Lix.

-- Simon

Hi,

Here is an experimental version of Lix. Edit 2024-01-14: Removed the attachment. All of this is now in the stable 0.10.18.

This allows you, when you start an n-player map in singleplayer, to control all n teams.

Put the attached executable into an existing Lix directory. Start an n-player map (from levels/network/) from the singleplayer browser. You'll play with lix in n different colors for the n different teams. Whenever you hover over a different color of lix, the skills in the panel change to that team, and you can assign skills to that lix.

This cannot netplay; it fails to connect. I gave it version number 0.10.−17 to distinguish it. Keep a regular current Lix 0.10.x around for netplay.

I hope that this is helpful for Flopsy to illustrate his multiplayer strategy guide with screenshots.

In the long term, I'd like to include this feature in the normal stable releases. It's not only useful to stage multiplayer screenshots; it's a useful feature on its own: We can playtest n-player maps with this and see the correct spawn timings, correct hatch orders, ..., as it would be in real multiplayer. But it's too early for me to call it stable: Behind the scenes, this has lot of assignment code changed to allow switching the local team. I'll have to playtest it several times and sand a few more rough corners. Still, I release this ASAP as experimental because Flopsy has a lot of time over the holidays and asked for this feature. Here it is. Merry Christmas.

-- Simon

Hi,

Lix's IRC channel is #lix on irc.quakenet.org, join chat in your browser or use a dedicated IRC client.

The logs are usually at Nordicbots, but the logs are are down. I have seen that error, "At least one service is unavailable at the moment. Please try again later.", several times this year, I don't know if the logs have been up in the meangime.

Also, the logging bot, named Lovely, isn't sitting in #lix. I don't remember when he was there for the last time. From my client-side log, the latest entry for Lovely has been:

2023-08-22 22:42:11 * |Lovely| has quit (Ping timeout)

The following two bots are unrelated to logging: Bot Q is for nickname authentication; to have owner rights and operator rights on #lix, I have to be registered with Q. Bot __ (two underscores) is Mindless's relaying bot for forum posts from Lemmings forums.

I haven't investigated more than this.

-- Simon

What? Are we late for something?
On the contrary! We are too EARLY!

Temporal (2008) is a freeware action-puzzle game by renboy.

Watch trailer on Youtube

Download Temporal 1.11
Download Temporal's original soundtrack

On Windows: You can double-click temporal.exe, but then Temporal will force a hardware fullscreen resolution of 1024x768. If you have a wide monitor, run Temporal windowed instead:

temporal.exe -win
On Linux: Temporal runs well in Wine, but the forced fullscreen is even nastier here. To run Temporal windowed:

wine explorer /desktop=1024x768 temporal.exe
Controls:
Left/right arrows to move.
Up arrow to fly.
Down arrow to use the device in which you're standing.
F1 shows overview of all other hotkeys.

About: You'll solve real-time physics puzzles that first look impossible, but are solvable by going back in time. You can accomplish more things while your earlier instances of yourself are busy elsewhere on the level.

Temporal has 30 main story levels that you must play in order, plus 5 unlockable challenge levels. Even as a dedicated puzzle solver, you'll spend several evenings on the main story. And I haven't solved all challenge levels either.

Most tasks require experimentation and solid route planning. Several tasks require precise execution; if stuff goes wrong near the end, you'll have to repeat 1 to 3 minutes of work. You have infinite lives and there are automatic in-level checkpoints, but you can't quicksave.

I've known Temporal because, back in 2008/2009, I lurked the Allegro 5 forums and saw renboy's release thread. I have versions 1.00, 1.03, and 1.11 lying around; the 1.11 is in the download above and it's the latest that I know.

Temporal doesn't feature level editing or user content, and I don't know any active dedicated websites or communities. renboy eventually lost ownership of his domain potato-factory.com around 2010.

Music bug workaround: In level 18, named "Synchronized", if you move away too quickly while the long dialog is still on screen, music won't play for the remainder of the level. If you reach the checkpoint in level 18 and you hear no music, you've run into this bug. The workaround is to restart the level and:

• Either cancel the long dialog explicitly (press return),
  
• or stay around until the last line ("Now, begone!") has disappeared.
  

-- Simon

Hi,

I'm back from a 3-week vacation to Vienna.

geoo, Ramond, and Peter live in/near Vienna. I've been there in 2015, and I've always promised them a re-visit. This September, we finally did it. Thanks to Peter and geoo for hosting me for over a week each at their places!

We took long walks, swam in the Danube, rode bicycles, raced Lix singleplayer, cooked Gargantua Blargg's spicy stew, and played a heap of board games. I'll post the stories here after I've got the photos off my laptop computer.

Sneak (card game) already got its own topic for playtesting/development. Nobody of us had played before; we discovered Sneak during my vacation in one of my books.

-- Simon

Hi,

geoo and I are working on Sneak, a card game designed by David Parlett.

3-6 players. One or two standard decks of 52-cards.

Sneak rules on Parlett's website

We started with the above Sneak rules. Technically, we didn't start with the website, but with the Entensuppe book, a German book from 2008 with translations of Parlett's games. But the website and the book appear to agree.

We played with 3 or 4 players and always used 52 cards.

Eventually, we changed some rules:

• #1: Replace the standard 52-card deck with Five Crowns, but remove the 6 jokers. This new deck contains 110 cards: 3456789TJQK (no aces, no deuces) in 5 suits and 2 copies per card.
  
• #2: Rank straight flush higher than matches (a.k.a. tuples, n-lings).
  
• #3: Rank flushes higher than straights. (Both still rank below matches.)
  

The re-rankings feel appropriate for the 5-suited deck, and it's handy that the rankings now agree with Poker.

It's possible that even for the standard double deck of 104 cards, straight flush should be ranked higher than matches, but we didn't playtest that. We went directly from the standard single 52-card deck to the Five Crowns deck.

Longer decks increase the scope of play before the stock runs out. Still, hoarding cards in hand until the end may be too good: Never sneak, rarely challenge other people's plays, and if you challenge, do it only with your very strong hands. At the end of the game, be the one player with cards left in hand and put them into your pile of winnings.

We'd like to encourage a more daring playstyle. Toward that, geoo is considering to change Parlett's endgame rule to:

• #4: After a player has drawn the last card from the stock, there will be exactly one more round of turns, starting as usual with the player after the drawing player, ending with the drawing player. On your turn, you must flaunt; if you have zero cards in hand, skip your turn. After this final round of turns, leftover cards in hand become worthless. You don't add them to your pile of winnings.
  

If this proves sensible in playtesting, I'll write down a full ruleset with these adaptions. Edit: Done, full ruleset with Simon's/geoo's current rules

-- Simon

What's This

Turnierbild Dark is a cardset for PySolFC, a free-and-open-source solitaire/patience collection written in cross-platform Python 2. A cardset is an alternative skin for the playing cards in PySolFC.

Turnierbild Dark is my modification of the XSkat German cardset that ships with PySolFC. I've recolored the four suits according to the four-color tournament Skat deck, called Turnierbild, which gives my cardset its name. I've changed the card paper from white to dark grey. The face cards are dimmed.

How to Install

• Install PySolFC. I tested with version 2.21.0.
  
• Download the attached .zip.
  
• Find your PySolFC user directory. On Linux, it is: ~/.PySolFC/ Maybe you must run PySolFC once to have it create that directory.
  
• Extract the .zip into the directory cardsets/ in that user directory. You should now have this directory structure: <your user directory>/cardsets/cardset-turnierbild-dark/01c.gif
  
• Run PySolFC.
  
• Options -> Cardset..., select: Turnierbild Dark
  

I recommend a dark table to go with Turnierbild Dark, e.g., the plain black from my screenshot, or the galaxy at night. Choose the table color in Options -> Table tile...

Bugs

By design, four colors remove the tight coupling between (diamonds and hearts) and bewteen (spades and clubs). That's a problem for games with alternating red-black packing. Look at the screenshot. In the rightmost column, we can grab and move 8-7-6-5-4-3-2 as a unit, but we can't move the entire Q-J-...-2 because the 8 and 9 are both black suits. Ideas to improve the red-black problem are welcome. Although I'll be picky. There is personal taste at stake. I must subjectively like the resulting set.

Face cards have indices only in two corners, not four. Let me know if you find games where that is problematic. Forty Thieves fans the discard pile leftwards, but you can still see the indices at the bottom right.

Graphics for open spaces aren't in dark mode. E.g., in the screenshot, the two empty club foundations are too light, as is the free weaving space on the very left in. Let me know if you find a way to fix that.

-- Simon

Here's some loose rambling from pushing source code around. I don't have concrete plans to rework anything here, but I've re-examined the existing memory layout this weekend. Thus, why not write it down, maybe it's of interest.

A lix (the struct Lixxie that describes a single lix) is 56 bytes long, assuming we're on a 64-bit machine with 64-bit pointers. The layout is roughly like this:

Bytes 0-32: The lix's job, an emplaced subclass of Job. All subclasses fit into 32 bytes.
Bytes 32-36: Position as two 2-byte integers
Bytes 36-38: 2-byte bitset for all the bools such as facing direction, ability to climb, ...
Bytes 38-40: Queued fling speed as two 1-byte integers
Byte 40: Style (color, player affiliation)
Byte 41: Encounters (water, exits, ...) during the current physics update
Byte 42: Exploder timer in multiplayer
Bytes 43-48: unused (5 bytes)
Bytes 48-56: Pointer to the entire physical world. Kitchen sink object, only filled & used during updating.

The first 32 bytes of that are the emplaced Job; in detail, the Job looks like this:

Bytes 0-8: vtable pointer for the Job class object
Bytes 8-16: monitor pointer for the Job class, an unused (?) multithreading D object per class object
Byte 16: Activity (determines vertical frame in the spritesheet)
Byte 17: Horizontal frame in the spritesheet
Bytes 18-32: Subclass payload: Job subclasses define it, e.g., leftover builder bricks, miner anti-shock

Things in the Job subclass are properly aligned. If the first field wants to be 4-byte-aligned (e.g., the common 32-bit int, which has size 4 and alignment 4), it goes at byte 20 in the Job, with bytes 18 and 19 unused padding. In D as in C++, a single-inheriting subclass starts its data after the base class's data, and the base class's data comes after the hidden vtable pointer (and in D the monitor pointer).

+----------------------+
| 0-8: vpointer of Job |
+----------------------+
| 8-16: monitor of Job |
+--+--+----------------+
|Ac|fr|      18-32:    |
+--+--+     subclass   |
|           payload    |
+----------+-----+-----+
| 32-36:pos|flags|fling|
+--+--+--+-+-----+-----+
|st|en|tm|  5 unused   |
+--+--+--+-------------+
| 48-56: world pointer |
+----------------------+

---

Cache lines in most computers are 64 bytes. If you fit into a cache line, you're quick to load.

The lix is 56 bytes long, that fits. Still, I should try to pad it with 8 more unused bytes. The padded lix would then always be 64 bytes long, and it's possible that it'll be even more cache-friendly (even though it's longer!) than the 56-byte lix.

The alternative experiment would be to pack everything into 32 bytes. The bytes will then be as snugly packed as a pile of kittens. We'd have to pass the pointer to the outside world in the methods, or abuse the memory layout and cram it over the (hopefully unused) monitor pointer. I think I could reduce the Job subclass payload from 12 to 8 bytes, and cram the Job-independent fields from 16 bytes into 12. It would be an elaborate experiment.

The elephants in the room are really the pointers. These 64-bit pointers (8 bytes) are fat walruses. You can't herd too many of those in your bathtub at the same time.

-- Simon

Hi,

Phyu in Lix is a contraction of "physics update", and denotes the number of physics updates that have passed since 4 seconds before the spawn of the first lix.

Phyu is a bad word:

• It's a made-up word that appears nowhere else but in technical discussions of Lix.
  
• It's nondescriptive, you don't necessarily guess that I use it as a measuring unit.
  
• It's a contraction of a verb (we're advancing physics), not of a noun (we have updated physics this often).
  
• It's annoying to pronounce.
  

Replacement ideas:

Frame: I don't like frame because we can confuse physics frames with graphics frames. Lix runs at 60 fps, these frames are graphics frames, and we update physics at normal speed 15 times per second, 15 fps. I'd like two clearly different words instenad.

Age: I like this best. We're at age 100, and soon we'll be at age 101, very nice. Still, it leaves a sour taste: We update at 15 age/s, age(s) per second, huh? Age sounds like it must be far longer than a second.

IGT: An acronym for In-Game Time, as opposed to real time. Lix runs at 15 IGT/s? Sounds strange.

More proposals or arguments please, otherwise I'm sticking with age.

I'm even open to redefine age (or how we call it) to start at the first spawn, not at 4 seconds (= 60 physics updates) before the first spawn. I'll still write replay files as if the first spawn were at phyu 60, not at age 0. The 4 seconds are because networking games, and even singleplayer in old (2007-2010) versions of C++ Lix, start 4 seconds before the first spawn, and blissful teenage 21-year-old Simon immediately baked it into the replay files.

-- Simon

Prompted by the DMA manual's figure of level width 1600, I've re-tested level size and edge behavior on DOS Lemmings 1.

You can scroll around to see 1584 pixels of the official 1600 pixels, i.e., all but the rightmost 16 columns. You can't scroll any further to the right.

The left edge turns lemmings.

The right edge extends even beyond 1600 pixels as extra air, still inaccessible to the game's main camera, but observable on the minimap. There is considerable empty space at the right, certainly more than 16 pixels beyond the visible 1584. On DOS, in Rendezvous at the Mountain (DOS password GKNONNIIJQ), I can build an entire 12-brick bridge into the unscrollable void and I still see lemmings fall off the end of the bridge, dying only in the void at the bottom. With only the first brick visible, the bridge is 22 pixels long, and I sneak in another builder to make it at least 23 pixels long beyond the visible 1584.

So far, this agrees with Proxima's post about L1 edge behavior: Left is solid, right is open on DOS and Mac.

Compare with the Rendezvous Amiga screenshot on Lemmings Encyclopedia, which is 1591 pixels wide. The rightmost 7 pixels in this screenshot are not viewable on DOS. The left edge in the screenshot agrees with the DOS visible left edge.

But, lurking in the darkness, there is more.



New and exciting! There is an eventual solid right edge on DOS Lemmings 1. It's about 2 or 3 bridge-lengths away from the visible section.

You can't hover the mouse over lemmings in the scrolling-incessible section, which is everything beyond the first 1584 pixels. The method to build bridges in the inaccessible section, to eventually reach that solid right edge, is to abuse the right-click bug:

• Select builder in the panel.
  
• Hover over an eligible lemming which you want to build later.
  
• Press RMB, holding RMB throughout all remaining steps.
  
• Hover over a blocker. (Or any lemming that cannot receive builder.)
  
• Wait until the eligible lemming is where you want him to build.
  
• Click (press LMB) on the blocker. The eligible lemming will now build.
  

Repeat this bug 1-3 times with fresh lemmings from the rightmost hatch on Rendezvous. Eventually, you've reached the solid right edge, and lemmings will return to the visible area, as in the screenshot above.

It's so far right that the green points (that mark lemmings on the minimap) are getting on the minimap's red border. There is more to research here about where exactly that solid right edge is. I took a wild guess in that it's around X = 1640; it took me 3 bridges to get there. But I didn't build optimally.

There seems to be nothing special about the DMA manual's figure of 1600 for the level width. Scrolling stops earlier than that (at 1584), but physics stop later (at ~ 1640).

-- Simon