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.

Hey, good to hear from you, NieSch - and to meet you! I wasn't really expecting a reply tbh, as you haven't been active for a while it seems. Just watched your Tricky 2 replay, and yes, I can see why'd you consider that one a 'nasty backroute' haha. Unlike mine, your solution is very elegant - especially the use of the shimmier-blocker turnaround; always a neat mechanic. I actually decided to return to Yippee! after playing through and enjoying all your levels in the 'Levels By NieSch' topic. I've moved onto Long Live Lemmings! now but it's been fairly slow progress from the get-go; even the Fun rank wasn't a doddle! I'm barely beyond Tricky and there've already been a couple of levels that had me tearing my hair out lol - usually ones involving sliders (can't stand those critters!). Contrary to what seems to be the prevalent opinion on the pack topic, LLL is generally harder than YML for my money. Still, hope to have some more replays for you there before too long as well!

Congratulations on finishing the pack, JawaJuice! It's nice to still receive feedback and see replays after so many years. You found many clever alternative solutions. The only one that is a truly nasty backroute is your solution for "Signs to Guide You". (My intended solution is in the first post.) But that one is cleverly found too. Well done!

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