I actually even have a level idea that revoles around sending a Basher down a Fencer tunnel, exploiting the Basher's "sloping" behaviour, in order to make that Fencer tunnel Shimmier-friendly . Before the introduction of the Shimmier, the only way to enforce this being necessary that I could think of was involuntarily resealing the Fencer shaft somehow, in order to make the Basher going through it even necessary. You might have guessed it: That "involuntarily resealing" part required the use of Slowfreeze.

One way that the forced-resealing could be done without slowfreeze, is requiring the use of a stacker at one end to create a wall a climber can go up - resealing the tunnel in the process.

Quote

A similarly unusual result can be had by assigning a bomber or stoner to such a digger, instead of a blocker. Because the basic rule is "diggers do ohno before exploding", they will go through the "ohno". Ohnoers will fall if there's no terrain under them, so the was-digger will explode on the ground below, not where he was when the skill was assigned (or if the fall is very far, he'll explode in midair; or if he hits an object that removes the lemming from the level, he'll be removed by that without exploding first).

Ah, namida... stop giving me ideas involving stupid tricks with Oh-Noers... The only one I tried was trying to exploit Oh-Noers to avoid splatting, like in Lemmings Revolution - but I discarded that idea because Oh-Noers can't actually fall as far as splat height before exploding. Now you've shown me two examples on the same day where Oh-Noers can be used for tricks...

Spoiler (click to show/hide)

So, if you ever see a Digger moving towards a thin stripe of terrain covered deliberately in one-way-up arrows, separated by steel pieces to prevent the Digger from digging all the way down to the one-way terrain... you know what to do!

You want to talk about Ohnoer tricks? Take a look at...


...or even older...

When he drops into a water pond at the last moment, the water extinguishes the fuse, and therefore, the lemming can't actually explode (even if he wanted to). He will simply start drowning, like any other lemming would, and consequently, you could save him from drowning like any other lemming. However, there's no need to save him from oh-noing anymore, because the water actually does that, and it makes total sense - both mechanically and flavourwise .

This would only be consistent if (a) an already-existing swimmer also cancelled the exploding upon hitting water, and (b) it was not possible to assign a bomber to a lemming while swimming. Not to mention, that explanation doesn't make so much sense for stoners - I haven't tested, but I'd believe everything mentioned here is equally applicable to them, based on that the ohnoer is the same state either way, just with a flag that determines whether it explodes or stones when finished.

Certain situations already skip the OhNo animation

While this is true, there is currently no situation in which the OhNo animation is interrupted mid-way with an immediate explosion. All situations currently either skip the ohnoer entirely, or have the full ohno'ing animation. Not that this outright means that isn't a possible solution - I actually think that's not a bad idea - but just that there isn't a precedent here based on that.

Yes, in this case, it should definitely be using the defaults. Alright, I can rule out the above theory.

The general setup for these cases: Assign a bomber such that (a) the lemming ohno'es, and (b) the lemming falls into water before exploding.

As far as I'm aware, the bomber can be substituted with a stoner. I haven't tested this, but can't think of any reason why it wouldn't work. I have confirmed that the nuke can be used for this, it doesn't need to be an actual bomber skill.

First, see what happens when the above is done with no further steps. The ohno'er becomes a drowner, and drowns.

Now, try assigning a swimmer to the ohno'er before they hit the water (you can't do this during the ohno, it must be done before assigning the bomber). Notice how instead of drowning (since swimmers can't drown), they continue falling to the bottom of the water, exploding when appropriate. This part, IMO, is fine.

The bug - in general (and this part itself isn't a bug), you can assign a swimmer to a mid-drowning lemming to save him. However, you can do this even when the above bomber hits the water. Becuase the lemming was no longer going to explode, you've now got a fully functional lemming again. Given that a non-drowning but has-swimmer ohnoer will not start swimming, and cannot be saved by water, I feel this is a bug.

I'm not entirely sure what the best resolution for it is, though. Possibilities are:
a) Ohnoers always ignore water, instead of just if they're swimmers.
b) Ohnoers always drown, even if they're swimmers.
c) Specifically prevent the above case - either the swimmer can't be assigned to the drowner in this case, or upon making the assignment the lemming immediately explodes.

I think B might be the most logical course of action here. A feels less natural, while C means we're introducing a specific new rule for an edge case instead of slightly tweaking an existing one - in a way that should have very little if any side effects - to cover the edge case better.

Related thing to check: Do ohnoer-disarmers falling onto traps also avoid exploding? I suspect not - my first prediction is that they'll get eaten by the trap; though "they ignore the trap and explode" is also possible. That's a much more obvious case and I think Nepster would have thought of this one - if I didn't think of it myself when initially implementing the disarmer, which itself is fairly likely.

Here's a level and a replay that illustrates this bug (and cannot be solved without it - activated via the nuke, rather than a bomber skill, in this case).

Okay, I'll look into this bug and in particular, whether or not it was fixed via changes to the default postview messages file. If it was fixed via such changes, this would mean the fix doesn't automatically carry over to any packs with custom postview texts - and it seems a lot of packs have a copy of the default file (as it stood at the time of conversion), possibly due to the convertor from old formats not really being able to detect custom vs default messages and just treating all postview texts as custom (and thus creating the pack-specific file).

Fully fixed in commit 55DBF96.