<Nepster> Yes, more guidelines for objects would be nice. This needs a proper forum topic though and I am currently not in the mood to make one.

You play a level in a new tileset, and there is a little house. Is this an exit? Trap? Teleporter? Receiver? Who knows? It's whatever the set designer liked that day.

Whatever looks like a house or archway, I suppose it's an exit. Bonus points if the house has torches. This guideline was set in stone in L1. Very consistent, very good. L2 Sports had the dumb flag in the Sports tribe, but that doesn't violate the rule that every archway is an exit.



L2 began violating the guideline with the airlock. This doorway looks like an exit, because up to here, all the archways were exits. But it's not, it's a trap.



L3 Egyptian has this awful fake exit, and the rotatable wall with hands, of which I didn't find a picture. Both are traps.

Please don't make traps that look like archways. Avoid avoid avoid. If it looks like a building with an inviting door, it's good to enter.



Whatever the L2 devs were smoking, they made this, and it's the L2 Scottish set. This looks like terrain or decoration, but it's again a trap.



Compare with the coastal suction function! This is perfect trap design. The coastal suction function hovers above the path, with a dangeorus tube coming out that aims at the lemmings. It looks mechanical, and not at all like a house. Obviously a trap!

Teleporters must look reasonably different from receivers. Door open or door closed? I don't look at that, I look at the shape of the thing. And if it looks like a house, convince me first that it's not an exit. It's not enough if it doesn't animate. If it doesn't animate, convince me first that it's not terrain.

There's a teleporter in the marble set, it has striped pipes coming from it. Why shouldn't these be solid? They look exactly like the other pipes. Beware of levels that connect real pipes to the fake pipes.

Teleporters could get a consistent symbol throughout all tilesets. Real life has no teleporters, so we must invent something. A lightning bolt? A star? Something that doesn't yet have meaning in Lemmings!

-- Simon

We discussed this in #nl yesterday.

Chat summary: The game scrolls slower during pause. This is dubious: During play, we update physics and draw, but during pause, we only draw. Pause cannot possibly run slower than play, because it's strictly less work -- unless there is a bug.

namida has suspected that the game renders the level twice during pause.

Source code: In v1.47, GameWindow.pas:247, procedure TGameWindow.DoDraw; seems responsibe to render everything. This tells gadgets, lemmings, and the terrain to draw themselves.

When I grep the codebase for DoDraw, I find 7 calls to this method, spread across GameWindow. With so many calls all over the place, I didn't try to reason whether DoDraw gets called too often.

One solution is to make DoDraw do nothing but set a flag. When all input and physics are done, and the flag is set, draw. You already have fNeedRedraw, but aren't using it consistently for this.

-- Simon

I've dabbled in the Lemmini source on bitbucket, or
git clone https://bitbucket.org/fade0ff/lemmini
Does the Superlemmini source sit somewhere on the web, too? namida pointed me to the zip in the Superlemmini 1.03 release thread.

I've always wondered whether Lemmini is fully hi-res, or lo-res physics with hi-res graphics. The lemmings move very smoothly compared to other games. Is this a purely visual perk, or are the game physics this smooth?

The answer is full hi-res: Builders move 4 pixels ahead during a cycle, that's hi-res. Nonetheless, hi-res isn't obvious: Fallers fall 3 pixels per physics update, that's the same speed as Dos L1 fallers, which would imply lo-res. Hmm.

The solution is that Lemmini performs a physics update every 30 ms, this means 33 frames per second. It updates twice as fast as Dos L1 or Neolemmix at 17 fps, and more than twice as fast as Lix at 15 fps. If we fall at Dos L1 speed, and the distance fallen is half as much as Dos's due to hi-res vs. lo-res, and we fall twice as often, everything fits together again.

But 33 fps isn't obvious from the source either. The source boldly claims:
/** Lemmini runs with 50fps instead of 25fps */
TIME_SCALE = 2;
Bleh? This comment won't digest smoothly with
/** time per frame in microseconds - this is the timing everything else is based on */
MICROSEC_PER_FRAME = 30*1000;

...and this is the code used in the main loop. But doesn't matter, either 25 fps or 33 fps is more than Dos L1, and the thing is definitely hi-res.

Now, if you watch Lemmini closely, you will notice that the lems moonwalk. In detail: Walkers alternately move ahead by a hi-res pixel and animate, and then, in every other physics update, they move ahead by a hi-res pixel, but don't animate. This comes from TIME_SCALE = 2; the lemmings animate only every other physics update.

I conjecture that Windows Lemmings was lo-res physics with hi-res animations, and then Lemmini took the hi-res animations into faster, hi-res physics. Can someone shed light on the Windows Lemmings?

-- Simon

Hi,

this topic is outdated: Lix 0.8 and onwards has networked multiplayer, and we've played some nice sessions already in September 2017. Get a recent Lix from the Lix homepage.

---

I have begun developing the networking in D Lix. Networked multiplayer is the cheese feature, Rubix and NaOH have joined LF after playing Lix multiplayer in C++ Lix. We must have multiplayer in D Lix.

Game rules: Each player has lixes in their own color. You may assign skills only to lixes of your own color. There is an exit with your color, try to get many lixes into that exit. You get a point for each lix in your exit, no matter whose lixes they were. Screenshot of multiplayer in C++ Lix.

Technical background: Each player runs Lix on their own computer, and connects to a server. When a player assigns a skill to their lix, the server relays this event to everybody else. The game calls high-level networking functions like "send assignment", "choose level", "send chat message".

I have written an abstraction layer that exposes these high-level functions. The abstraction layer sits between the game and enet, a C networking library. I get my hands dirty here, read from bare ubyte*, count precise lengths of data structures, cast data types around.

The networking layer is standalone: It doesn't include anything from the remaining game. Therefore, I can test the abstraction layer outside of the game.

How far am I: The abstraction layer has most features and is well-debugged. My next step is to write the lobby. The lobby will be a graphical user interface inside Lix, it will connect you to the server, offer a text field to chat, and buttons to choose colors and levels.

-- Simon

The builder generates terrain behind itself with every brick. Here, the builder barely bypasses the exit. Walkers coming from the left will jump into the exit, because they will walk over the extra terrain.

Keep? Remove the lo-res pixel (= 2x2 hi-res pixels) behind the builder? Remove the lo-res pixel and add a pixel at the tip of the bridge, keeping the shape?

-- Simon

IchoTolot: ah ok the bug front :P
Simon: the bug front is exciting
Simon: I love bugs, everybody should report bugs against every software

Long and technical post, programming.

Github bug #132: Walker bypasses trap, faller is killed, found by Ramon. Equivalent to a bug in C++ Lix, Fast flinging through traps, found by geoo. I want to find the best solution to this.

What happens? When you enter and leave triggered traps, the game scans for traps only at your final position. The game knows that you went through a trap somewhere, but it doesn't remember where you encountered a hungry trap. Whenever you somehow went through a hungry or already-eating trap, the game sets a flag. If this flag is set, then after your full motion, the game scans for hungry traps at your final position.

Compare this with our fire solution: When you enter and leave fire within the same frame, the game still remembers that you went through fire, and kills you. You got to perform your full motion and affect the environment, but after that, you die.

Desired instead: When you move through a hungry trap, then leave it during the same frame, this trap kills you. I don't know whether you should move away or not before the trap kills you.

Sketch of call stack

single lix performs physics update:
    perform job:
        some work
        move ahead:
            if encounter trap:
                set flag
        more work
    if flag:
        feed trap
        die

I don't know whether "more work" should execute when we are going to die. "More work" can easily move you somewhere else, and then it could be harder to determine the correct trap.

Idea #1: throw exception

Have moveAhead throw on trap encounter, and catch this exception in singleLixPerformsPhysicsUpdate. The intention is to stop performJob early.

Benefit: Program flow mimicks what we see and expect. We die immediately.

Disadvantage: I use the exception in a non-exceptional case. This may happen several times per second. In effect, it's a goto that jumps between methods of different classes.

And exceptions produce the slowest code. Throwing may be idiomatic in Python, you even throw when your iterated range is empty. This isn't Python, exceptions are slow. I had file-searching code that relied on exceptions internally, it became 10 times faster after rewriting internals to return success or fail. You don't want exceptions flying everywhere in a multiplayer game.

Maybe it's not a huge performance dent and I should profile.

Also, are exceptions designed for this? Exceptions are for when you encounter non-bug problems with your input or environment, and you don't know how to handle. But I know exactly how to handle traps. My desire is to stop the outside logic, not to inform the outside logic.

Idea #2: disable movement

Once we touch a hungry trap, disable further movement.

Advantage: Relies on encounter flags (did we touch water, fire, trap, steam, etc.) like every other encounter.

Disadvantage: We don't die immediately. The movement-calling code, "perform job" in the call stack above, contiues to happily call moveAhead, and yet we don't move ahead.

Idea #3: remember reference to trap

Once we touch a hungry trap, remember a reference until the end of performJob.

Advantage: We know the correct trap 100 % of the time, instead of deducing which one it was after the fact. We don't ever remember references to already-eating traps, even though we moved through their area. When the job calls moveAhead, we will still move ahead, even if we die afterwards.

Disadvantage: Extra mutable state. We don't die immediately.

Hmm.

I like #3 best, then #1, then #2. (Completing the motion after seeing the trap) shouldn't be problematic. Lixes never affect each other with traps: One lix performs at a time, traps snap immediately before the next lix performs.

-- Simon

Hi,



Here's a bug level, Wheel of Misfortune. See attachment for level, and for the solving replay.

Successive hints for solving yourself

Hint 1

You need both builders for the exit platform. Therefore, you must contain the crowd with 1 blocker, 1 exploder, 1 disarmer.

Hint 2

If you removed the trap from the level, the level would be unsolvable!

Hint 3

The floor is thin, an exploder crater would make a fatal hole. Yet the exploder is a key skill.

Hint 4

The 2nd lemming builds. The 4th lemming gets all the remaining skills.

Hint 5

The 4th lemming blocks directly on the wheel's trigger area.

Hint 6

The 4th lemming is already a disarmer when it blocks on the trap.

Hint 7

Assign disarmer to lem #4 on spawn. Assign blocker to lem #4 when directly on the wheel's trigger area. Assign builder to lem #2 at the cliff. Assign exploder to the blocking #4.

This level highlights an inconsistency of the engine. Decide whether there is a bug, and if so, what to do!

The inconsistency -- spoiler

Exploder reacts to exits and traps: An exploder cannot be assigned anything, but it will react to trigger areas. Exit trigger areas turn the exploder into an exiter. Trap trigger areas turn the exploder into a disarmer, or begin eating the lemming.

Blocker reacts to exits, but not to traps: Put a blocker in front of a locked exit. Open the exit. The blocker jumps into the exit. But put a blocker on a busy trap. Wait until the trap has finished eating. The trap will not eat the blocker!

My proposal -- spoiler

Make blockers react to traps. As soon as the trap has finished eating someone else, let the blocker disarm the trap, or get eaten.

-- Simon

I'm unhappy with Lix's information architecture within the application. Playing Levels and viewing their replays should be close together. But it's not: You play from the singleplayer browser, and view replays from the replay browser.

Idea: Redesign into a singleplayer browser, and a hack browser.

Singleplayer is for play, and viewing replays. Singleplayer browser can list replays for the selected level.

Hack browser is for play, edit, delete, mkdir, list and view replays, rename replays, export level as image, what-have-you. Hack browser is a strict superset of the singleplayer browser. The hack browser is a nightmake to make, because it must be powerful and needs lots of extra GUI for rename, mkdir, list replays, etc. Whatever you maintain by your favorite shell or file browser right now, it would become a reasonable feature request for the hack browser.

If hack browser exists, why keep singleplayer browser? Reason #1 is streamlined UI without clutter. Reason #2 is that you don't want a full-fledged filesystem shell within other people's packs.

-- Simon

I maintain replays for the community pack, lemforum/, on github:

Download replays as zip archive or
git clone https://github.com/SimonN/lemforum-replays

These replays won't help you in C++ Lix. geoo has 800 C++ Lix replays with 100 % coverage.

-- Simon

Simple 1 through Simple 10 on Youtube
Simple 11 through Simple 20
Simple 21 through Simple 28
Simple 29 through Simple 38
Simple 39 through Quirky 8
Quirky 9 through Quirky 14
Quirky 15 through Quirky 20
Quirky 21 through Quirky 27
Forest of Fears, Lix Lata
Quirky 29, 30 = Snowball Battle
Quirky 31-34
Quirky 35-40
Cunning 1+2
Cunning 3 through Cunning 5 = Lix Cannon
Cunning 6-10
Cunning 11-13
Cunning 14
Cunning 15-17
Cunning 18-22
Cunning 23-25
Cunning 26-28
Cunning 29-30
Cunning 31-34
Cunning 35+36
Cunning 37+38
Cunning 39+40
Daunting 1
Daunting 2+3
Daunting 4+5
Daunting 6 = Now This is Fun
Daunting 7-9 = Variety Day, Merge Sort, Backslash
Daunting 10-11 = Go West, Stickup (sorting before v.0.9.12)
Daunting 2 = Round Trip
Daunting 12-14
Daunting 15 = Railroad Plot
Daunting 16-17 = Derailed Level, Lixes in Motion (does not solve Derailed Level)
Daunting 18-19 = Too Much Stepping Stones, Jack in the Box
Daunting 20-22 = Slipping, Slipping Again, Lix Ferenda
Daunting 23 = Segmentation Fault
Daunting 24-26: Cornerstone, Repeating Patterns, The Crimson Room (does not solve Repeating Patterns nor Crimson Room)
Derailed, Repeating, Crimson, Feel the Pressure, Beneath the Lab, Slaughterhouse

Early videos show both Windows's mouse cursor and Lix's mouse cursor. This effect comes from the recording software, it puts Windows's cursor back into the video. Flopsy doesn't see the Windows cursor during play, not even during recording.

When you pull the mouse hard enough to a window side, Lix releases the mouse. This is a feature. Depending on your mouse speed in the game and in Windows, it feels like a bug instead. I fixed this in the later Simple levels.

SI, in the panel, means spawn interval, the physics updates between successive lix spawns. I should write that on hatches instead, during pause, and not use the abbreviation either.

-- Simon

Tested in 1.42-B, but Wafflem's avatar suggests that it's still in the current version. <_<

The pin (effective coordinate) of an L1 and NL lemming is inside the floor. The lemming's white foot is above the floor. Therefore, the pin is 1 pixel below the white foot.

The NL editor allows preplaced lemmings. Preplaceds have a special sprite in the editor: A still walker frame, and a red dot. The red dot is on the same height as the foot. When you run the level, a lemming appears with its pin exactly where the red dot was. We see how the red dot marks the pin correctly.

When you insert a preplaced, you must move its foot into the terrain. Only then will the dot be at the correct position. The ingame lemming will have its foot above the terrain.

Expected instead: The sprite should be shifted upwards by 1 pixel in relation to the dot. The dot stays where it is.

-- Simon

Hi,

Lix is a free-and-open-source game inspired by Lemmings. It's in the public domain and runs on Windows, Linux, and other platforms. We have singleplayer, a level editor, and networked multiplayer.

Download Lix -- if Windows, prefer the 64-bit version

• Play the included lemforum community pack.
• Play the included ClamLix, NepsterLix, Rubix's pack, ...
• Design new levels in the included editor.
• Play multiplayer: Post on the forums to agree on a time, or join IRC.

Homepage
Source code on github
Source code as .zip

Get help, report bugs/features:

• Create a new topic on this board, Lix, on Lemmings Forums.
  
• Or file issues on github.
  
• IRC: irc.quakenet.org #lix, chat in your browser
  

Lix comes with over 700 levels designed by Lemmingsforums members. Build your own levels with the included editor.

-- Simon

Hi,



Related chat on 2016-07-06 at 21:00 UTC:

Gronkling: SimonNa: Thanks for the backroute! here's a V2 of the level which will be included in the finished game (unless any other backroutes are found) https://drive.google.com/open?id=0B24bnHjK2QUDTGNhMWNxeWJVNlU
SimonNa: Gronkling: that level segfaults NL immediately on loading the level. What NL version do you use?
Gronkling: im using v1.43 for the player
SimonNa: okay, hmm
SimonNa: maybe I lack the tilesets, and the game doesn't give a proper error
Gronkling: just checked and i can load in my player
SimonNa: okay, cool
Gronkling: yes that might be it because i bundled the tilesets with the nxp

-- Simon

Are you on Linux? Make your life easy with scripts de luxe!

Windows users: If you're cmd-savvy, a Powershellist, or use Python, please share your Windows scripts, too.

Strip level from replays

You maintain replays for your awesome level pack. Replays may include a copy of their level. Lix has weird rules on whether to run the replay against the included level, or against the pointed-to level. To guarantee that Lix uses the pointed-to level at any time, strip the level from each replay file.

Both of the following solutions rely on how all levels' first lines begin with $BUILT<space>. The editor consistently saves like this, but it's not specced anywhere.

• geoo's solution: The Python script is attached to this post. It creates new replay files without the levels.
  
• Alternatively, the following Bash one-liner modifies replays in place. It doesn't keep backups. It recurses through subdirectories.
  find . -name \*.txt -exec sed -i '/\$BUILT /Q' {} \;
  

Sum initial lix

From all levels recursively found within the current directory, we extract the number of lix, then compute the sum.

find . -name '*.txt' -exec grep "\#INITIAL " {} \; | awk '{s+=$2}END{print s}'

Mass-verify replays

Verify all levels recursively found in the given directory replays/path/to/your/dir. Lix will check all replays against their pointed-to level, then output which replays solve, or don't solve.

This command is the same in any Windows or Linux shell:

lix --coverage replays/path/to/your/dir

-- Simon

Porcupine reads glider code, porcupine quills go up, porcupine carves out test map to prove hunch.

You have plastered the entire map with updrafts.
You have a n-pixel-wide vertical shaft of air, with vertical walls at each sides, for n > 0.
You have a glider in this shaft.

Observed: The glider ascendes in each shaft of thickness 2, 3, 4, ..., and descends in the 1-pixel-wide shaft.
Expected: The glider ascends in each such shaft.

-- Simon

1. Let lemming spawn from hatch.
2. Highlight the lemming. (Arrow shown over its head.)
3. Framestep-back to a time when the lemming is still in the hatch. It doesn't matter whether it would spawn in exactly 1 frame from now, or if the spawn will happen in several frames only.
4. Highlight-skill-assign floater. (This means: You hold the highlight key, and meanwhile, click the floater icon in the panel.) Observe how the skill sound plays, and a floater is deducted from the panel. You can assign many floaters.
5. Highlight-skill-assign exploder. Sound plays, you can assign many exploders.
6. Highlight-skill-assign climber. The game blocks these assignments, nothing deducted in the panel, no sound.
7. Unpause and let play. Observe how the lemming is neither floater nor exploder.
8. Framestep back and forth. "INVALID" flashes in the panel where the current activity of hovered lemming would be shown.

Expected instead: No assignments go through while lemming in hatch. INVALID never shown in panel.

Tested in the no-fading build, which shows 1.44n in the main menu.

-- Simon

Hi level designers,

Edit 2016-08: The lemforum pack is in good shape for D Lix. I don't ship Clam's and Rubix's levels until they too have good replay coverage. Clam and Rubix, ask me if you need help. I'll walk you through replay verification!

let's migrate singleplayer levels to D Lix.

Ideally, we should work to make all levels solvable in D Lix, possibly with slight changes from the C++ levels. Then, to guarantee solvability, we should prepare solving replays of all levels in D Lix.

Maybe a few odd levels can't be made solvable. Let's work out any problems together.

Get D Lix

Download for Windows <-- download
Download for Linux 64-bit (needs Allegro 5 runtime)
Source code
Changelog
Bug tracker.

Keep D Lix separate from C++ Lix.

What to do

Lemforum pack: D Lix comes with the levels as they are in geoo's github repository by 2016-04-14. Only difference to geoo's repository: Proxima is called Michael S. Repton, not Michael. geoo knows best how to proceeed from here. Wait for geoo's instructions.

Clam's and Rubix's levels: D Lix comes with the version of your levels that C++ Lix has. You can check manually which levels are still solvable. Or run D Lix's automatic replay checker over your C++ replays: If you've kept solving replays in C++ Lix, copy your C++ replay collection into D Lix's replay directory. Then run lix.exe --verify=replays/path/to/your/dir > output.txt. Ask me in IRC for help!

Differences of D physics compared to C++

• Spawn interval is fixed during play.
  
• Time is unlimited in singleplayer.
  
• Trampolines don't exist. Please remove all trampolines from levels. To help migration, the standard trampoline is still in the image tree, but it acts as a triggered trap that kills. I'd like to remove that tile within the next months.
  
• Basher mask is longer by 2 hi-res pixels.
  
• The builder gets closer to walls by 2 hi-res pixels before she stops and turns. You can now always build up to a vertical wall, then mine into the wall, no matter where you have started the builder.
  
• The imploder mask is wider by 2 hi-res pixels, therefore symmetric now.
  

Coming later

Screen start is automatic for now. Nonetheless, the D Lix editor reads and saves back to file existing manual screen starts. The value is merely ignored during play. I should probably implement custom screen starts, where you can choose a midpoint.

Hints and tutorial texts are preserved, but never shown. I have yet to implement hints. I'd like to improve their user interface from C++ Lix.

Report bugs! :-)

Roadmap

• Automatic replay checking. Done.
  
• Editor. Done.
  
• Declare the D port to be the standard version for singleplayer. Expect level designers to build against this engine, and expect all singleplayer replays to use a recent D port version. This also means that physics should not change erratically from here, at least in the master branch. Done: Since 2016-08-03, we have 100 % coverage for the lemforum pack.
  
• Work on stuff that level designers suddenly need/miss, to easen the switch. Tell me what bugs you most!
  
• Netplay, including the server code.
  
• Declare the D port to be standard Lix in every regard. Retire C++ codebase.
  
• Continue fixing bugs. I don't strive to make the D port as well-debugged as the C++ port before making it standard overall. Migrate early, expose bugs together, and fix them quickly.
  

-- Simon

Hi,

what is a smart algorithm for this?

Input data: List L of rectangles. Rectangle is 4 ints: (x, y) of top-left corner, (xl, yl) the two lengths. Also input data is exactly one torus map M -- this is a large rectangle, it's larger than any single rectangle in L.

Wanted output: Rectangle O that surrounds all the listed rectangles. This rectangle should be as small as possible. It's allowed to move the rectangles in L by integer multiples of the length of M. The output rectangle O should account for O-minimizing optimal shifts of the rectangles in L. (To clarify after NaOH's question: I want to minimize the lengths of O. You may shift the rectangles of L as often as you wish to minimize the length of O.)

I know: You can separate this problem by dimension: Consider only x and x-length first, then y and y-length.

Existing algorithms: I have an algorithm to find the smallest container on a non-torus map -- when you're not allowed to move the rectangles in L by the length of M.

For example, if the rectangles are denoted as Rect(x, y, xl, yl), the non-torus algorithm computes the correct smallest container for the following list of three rectangles:

    [ Rect(3, 5, 10, 10), Rect(5, 5, 9, 9), Rect(1, 1, 1, 1) ]
    .reduce!smallestContainer == Rect(1, 1, 13, 14)

I also have an exptime algorithm for the torus-smallest container: For each rectangle in the input list, try whether to set its top-left point in the range [0, M.xl[ or into [M.xl, 2 * M.xl[ instead. With an input list of length n, we have 2ⁿ choices to try. For each choice, measure with the non-torus algorithm. Use the choice that minimizes the non-torus algorithm target value.

Can I do it in less than exptime?

-- Simon

BitBucket: https://bitbucket.org/namida42/neolemmixplayer/issues/26/crashes-on-replay-saving-in-certain



Repro:

• Put the nxp file in ~/softw/win/neolem/nepsterlems/packs/
• Put the NL exe in ~/softw/win/neolem/nepsterlems/
• Be in the exe's directory
• Start the pack with wine NeoLemmix.exe ./packs/seb-1.00.nxp
• Win the first level

Instead of showing the results screen, game shows the above error, then exits after I click OK.

The bug doesn't manifest when I do either one of these:

• Go into the pack's dir, run the game with wine ../NeoLemmix.exe seb-1.00.nxp
• Move the pack into the exe's dir, run with wine NeoLemmix.exe seb-1.00.nxp

On Windows, when you drag a file from a different dir on an executable, what is the working directory?

[05:50] <SimonN> it is the build without the fading
[05:50] <SimonN> let me check version
[05:50] <SimonN> 1.44
[05:50] <namida42> the no fading build is based off V1.43n-F

-- Simon

Hi,

DMA released Lemmings 2 in 1992. For 24 years now, the assignment priority has tormented L2 players: You have a cluster of lemmings in a digger pit. You would like to assign to the digger among the walkers. But instead, the game assigns to a walker.

Challenge: Save 40/60 lemmings in Two's Company, Egyptian 1, using at most 3 skills.

Solution: Merge the two hatches at the top with a basher (skill 1). With a right-facing lemming, dig down the right-hand side of the column (skill 2). One pixel before breakthrough to the bottom, assign the to the digger a fencer. He will fence through both remaining pillars in a single go.



Trick: Assign precisely to the digger in a crowded digger pit! Here's how to do it.



Incoming...



Naive attempt: Hover the mouse cursor right on the digger in the pit. A sensible game would recognize this obvious desire to assign to the digger, right?



Nope, L2 thinks you'd love to assign to walker here. The digger keeps digging happily. The solution attempt is flunked.



The correct method is to move the cursor as far away to the left from the digger as possible. If we move the cursor farther than this, it would close. This alludes to the blinking cursor trick in L1, to select right-facing walkers. If the digger were alone in the pit, I don't believe the mouse would even open here!



This is guaranteed to select the digger. Try it!

I can't reproduce this with the cursor at the right instead of at the left. Maybe it depends on the direction of the digger. Maybe you have to offset towards the left independently of the digger's direction.

Don't let the assignment priority play tricks on you. Instead, you should perform tricks with assignment priority!

Not applicable to Sports 1: If your worker enjoys the company of stunners instead of walkers, you can't profit form this research. The stunners eat the click and don't delegate the click to the worker. You can't save more than 58 in Ceci n'est pas une pipe, Sports 1, with assignment research only.

-- Simon