Quote from: roltemurto on April 14, 2026, 09:44:07 AMCongratulations on the 3.1 Update!!!
Personally I think it's a work of art!
...
May life put a smile on your face. Have a wonderful day!

Thank you for you kind words of appreciation. They are a rare currency in this day and age, I shall treasure them

Quote from: kaywhyn on Today at 12:34:53 AMthe problem was with you suggesting it be done quickly, which Proxima and I think isn't the approach to take with this. There's a lot of levels to scrutinize here, and that will take a lot of time in general.

There has definitely been a misunderstanding about what I mean by 'first draft'. Essentially, what yourself and Proxima want to do is skip what I'm calling the 'first draft' and go straight to sorting through the levels.

And that's totally fine, as I said previously I support whatever approach Proxima wants to take. If it doesn't help you guys to have a 'working playlist' (which is probably a better descriptor for what I'm referring to than 'first draft'), that's not a problem. Do what works best for you.

Anyways, take all the time you need with sorting through the levels. You're right, it's important not to rush that particular part of the project.

And, this should now be fully fixed. We can now prioritise objects by type rather than individually.

So, all OWWs have equal priority, and lower priority than all traps, which have lower priority than all force fields/blockers, which have lower priority than exits. This is the list in full:

    static final int PRIORITY_GADGET_MASK =
        Stencil.MSK_EXIT
          | Stencil.MSK_BLOCKER
          | Stencil.MSK_TURN
          | Stencil.MSK_TRAP_FIRE
          | Stencil.MSK_TRAP_REMOVE
          | Stencil.MSK_TRAP_LIQUID
          | Stencil.MSK_ONE_WAY;

This additional layer of abstraction is the key; we now have fully working object prioritisation in RetroLemmini.

Fixed in RLPlayer commit 1285213.

So, I'm a step closer to having this fixed.

It turns out that OWWs (and indeed any objects) were never truly 'overlapping', at least not in the sense that their triggers were all effective at the same time. Lemmini has always had index-based prioritisation for objects. So, whichever object was drawn last occupies any given trigger pixel.

For instance, in previous versions of Lemmini, laying a OWW over a fire object will override the fire object.

I wanted to fix this in RetroLemmini by hard-coding the object prioritisation, with Exits being at the highest priority. This was all well and good apart from the fact that each individual OWW object had to be prioritised separately, which is why any levels using overlapping OWWs were suddenly broken: RetroLemmini was pre-selecting which OWW object should be at the highest priorty, regardless of draw order (which is what the levels relied upon previously).

I've implemented a fix in which Exits are now the only object which is prioritised over all others (RLPlayer commit d8ae78d). All other objects are once again prioritised by draw order. However, I'd like to see if I can refine this further. It seems silly that a OWW overlapping a fire or water object should effectively nullify the fire or water.

Further work is needed.

OK... frustratingly, the above fix actually didn't work after all. I've now reverted it.

So, we can overlap OWWs again, but there is some wierd stuff happening when they overlap. I'll come back to this later.

OK, I've had to revert allowing overlapping OWWs, at least for now.

The new bit handling system requires certain mask types to bypass prioritisation, and in order to preserve OWW overlapping behaviour from previous versions of Lemmini, I added OWW objects to the bypass list.

Doing so unfortunately created a side effect where terrain with overlapping OWWs would sometimes not be erased (correct), but the lem could still move through it (obviously not correct). I'm not sure exactly why this was happening, but removing OWW objects from the bypass list instantly restores good behaviour.

This fix does mean that it's once again not possible to overlap OWWs in RetroLemmini and have them all be effective. Instead, a OWW can only be guaranteed effective wherever it doesn't overlap with another. In fact, the built-in priority is (highest to lowest): Up > Down > Left > Right.

Any existing Lemmini levels which use overlapping OWWs to create Bash/Mine-proof terrain will therefore need to use individual Upwards-facing OWWs, rather than overlapping Left and Right OWWs, to get essentially the same effect (that is, if they're ported to RetroLemmini).

Overall, I think this is correct engine behaviour. Overlapping Left and Right to create a makeshift "Up" OWW, whilst ingenious, looks messy and shouldn't be necessary. It can also be confusing to players, who wouldn't necessarily be sure how the setup should be interpreted. Whilst in Lemmini it meant that Bashing/Mining in either direction was not possible, it would be equally reasonable to assume that the OWWs would cancel each other out.

So... let's remove the doubt, restore the ability to prioritise engine-side, and ensure that levels look less messy and are easier to interpret at first glance.

I'll supplement this fix with the addition of Upwards & Downwards-facing OWWs to all of the OG styles in due course. Any levels which require this effect will therefore have a purpose-specific object at the ready.

EDIT: Commit dropped.

In addition to the above, another similar bug has had to be addressed. I've posted  here regarding this one.

Fixed in RLPlayer commit 5a26622.

This is a physics update and could break existing replays, but only if they specifically involve turning a Miner on a OWW.

Thanks to hrb264 for reporting this one on Discord.

The replay is for the DoveLems level Maze in a Clepsydra, but the glitch will happen wherever this precise setup occurs:

A lemming is walking across a platform <=2px in height.
The platform has a OWW facing the opposite direction of the walking lemming.
The walking lemming is assigned a Miner.

Expected outcome:

No terrain is destroyed. The lemming stops mining and turns to walk back the way they came (i.e. facing in the same direction as the OWW)

Actual outcome:

No terrain is destroyed, but the lemming completes a full miner swing and steps through the <=2px platform, falling through the other side. They remain facing in the same direction (i.e. the opposite direction to the OWW).

---

Possible cause:

Best guess is that the miner detects the OWW too late, and has completed a swing (during which their Y position is increased) before they react to it. We need to detect the OWW earlier and adjust the miner's journey appropriately.

Quote from: Proxima on April 12, 2026, 03:54:02 PMI think we should add some new ones to help out the very beginning of the pack, while dropping some of the less interesting existing ones.

You're definitely thinking along the right lines as far as pack approachability is concerned; your post above has my full support.

Two additional suggestions that might be worth considering:

1) When deciding which levels to feature as "X-of-each", look to the general layout of the level. The more detailed and featured it is, the more likely an X-of-everything version will work well in its own right. I'm sure you're already aware of this, but just thought it was worth mentioning in-topic. Also, I'm happy to post a list of possible candidates when the time comes (i.e. if you're taking suggestions on specific levels).

2) Consider that not all X-of-everything needs to be 10. For instance, 5, 3 and even 1 of everything can make for great quality accessible levels. I'd suggest adjusting X to suit the level layout being used. Again, I'm sure you're already aware of this anyways

We need a volunteer (or several volunteers) to give the 2 attached style sets a hi-res retrofit.

The images have already been scaled up to 200% using nearest neighbour, so are currently identical to their low-res counterparts. The idea will be to add pixels around the edges, perhaps make the shading pop a bit more, and just generally upgrade the pieces to befit a hi-res platform such as RetroLemmini or Lix.

If nobody wishes to take this on, we can use the pieces as they are of course, but a hi-res upgrade by one of the community's artists would be a particularly nice bonus.

There's no rush on this, it will likely be several months before they're actually needed. If you want to get involved, feel free to grab the styles and have at them!

10-of-everything levels are not just for beginners. They make good warm-up levels to get the cognitive synapses firing ready for more challenging fare.

Above all, though, the most important thing a pack should have: variety.

So:

Quote from: geoo on April 12, 2026, 09:25:09 AMSure, levels with lenient skill sets are beginner friendly as they allow players to explore mechanics. But similarly, levels can have a small set of skills (in particular few different skills) and only use straight-forward mechanics and thus be beginner friendly and yet not easy ... At least these could be interleaved between the 10-of-each levels.

Yes, agreed - mix it up, give people a bit of everything.

Quote from: kaywhyn on April 10, 2026, 09:40:56 PMLevel selection is a very lengthy process, much more than you think, so I'm in agreement here with Proxima that rushing to get a first draft of level selection for Pack 1 isn't the way to go Especially for a project of a large size like this one. Hence I prefer that Proxima and anyone else who wants to help with level selection take time and not rush through it.

Maybe people are misunderstanding what I mean by "First Draft".

My suggestion is simply that we set up a framework on which to build. Levels can be swapped out, moved around, and we get a clear sense of cohesion and direction right from the very start. I'm not suggesting that the first draft be viewed as something that could potentially be released, which is what people seem to think. On the contrary, the first draft should really be nothing more than a list of placeholders. I mean, it could literally say "to be decided" for every entry at this stage!

With that said, the spreadsheet is providing real-time progress updates, which is great. And, Proxima's mentioned that he intends to draft the first rank fairly soon anyway. At that point, things will start to take shape and we'll have a clearer idea of what we're dealing with.

Quote from: kaywhyn on April 10, 2026, 09:40:56 PMAt least personally, I rather do things right the first time around

Impossible. That's why versioning is a thing.

Thanks for sharing the spreadsheet, Proxima! This is a great way for everyone to see what's going on with the pack in real-time.

After speaking with Proxima on Discord, it's become clear that Goal #1 is to curate the pool of levels.

The best thing anyone can do to help right now is to play through this version of RotL and provide feedback, share replays, list your favourite levels, list your least favourite levels, and comment either here in topic or directly on the spreadsheet.

Keep up the good work!

NeoLemmix Editor Version 2.0 Update

A significant update with the following features/bugfixes:

Templates
 • It's now possible to create, save and load level templates.
 • From the Template Loader, choose a template to use as default. This template will then be loaded when opening the Editor or creating a new level.
 • The Template Loader is shown on startup by default. This can be toggled on/off at any time.

Crop Level Width/Height
 • Added a new Crop rectangle which makes it much quicker and easier to adjust level width and height to fit the layout.
 • This has full hotkey support (X to toggle the Crop rectangle, Enter to apply, Esc to cancel.
 • Note that some Editor features (such as dragging pieces) become unavailable when the Crop rectangle is active.

Cycle Select Pieces
 • Shift + LMB (by default) cycles through pieces within 16px of the cursor, so that each subsequent click grabs the piece at the next-highest index.

Show/Hide Steel
 • Added menu item and hotkey support for Show/Hide Steel (Ctrl + F2 by default).

Control Hints
 • When the mouse is hovered over a control, information about that control is now displayed in the status bar. This can be toggled on/off in Settings.

Pieces List
 • Added a 'Pieces List' window which displays all pieces currently active in the level.
 • From here, pieces can be selected, moved behind/in front of other pieces, and deleted.

Style Manager
 • Added 'Remove' button so that styles can be removed from the list.
 • Bugfix - 'Sort Alphabetically' becomes available only when multiple items are selected.

Piece Browser - Auto-replace selected pieces
 • Pressing [Ctrl] or [Shift] whilst clicking-to-add a piece from the Piece Browser will directly replace any currently-selected piece in the Level Arranger. Note that this only works if a single piece is selected.
 • Pressing [Alt] whilst clicking-to-add a piece from the Piece Browser will add that piece to the same X/Y co-ordinates as any currently-selected piece in the Level Arranger. Again, this only works if a single piece is selected.

Misc UI
 • Improved/fixed layout of corner text (in both docked and windowed Level Arranger).
 • Piece selection is now preserved on Undo/Redo.
 • Increased maximum number of dropdown items in Main & Piece Style combos.
 • Updated some default hotkeys (Level Arranger is now Ctrl + L, Piece Browser is Ctrl + B, Expand All Tabs is Ctrl + Space).
 • Removed support for 'classic hotkeys'.
 • 'Missing Pieces' menu item is now only shown when relevant.

Bugfixes
 • 'Select Pieces Below' (Alt + LMB by default) re-triggers selection correctly, even if used whilst a piece is already selected.
 • Grid is now drawn to its own layer rather than the background layer (so, it's visible even if backgrounds are toggled off).
 • Enhanced support for non-English locales.
 • Fixed repeat renderings when auto-resizing the form.
 • 'Use Auto Screen Start' is now written to/from a setting object rather that directly to/from the checkbox.

---

Download the latest version of the NeoLemmix Editor.