Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - namida

Pages: [1] 2 3 ... 635
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.

Unless Lemmix is not replicating DOS Lemmings accurately, ohnoers will drown in DOS Lemmings.

In both DOS and NL, ohnoers can interact with exits. This is an intentionally accepted behaviour in NL.

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.

I created custom demo mode replays (for when the game is left idle at the title screen). Similar to those for official levels, they don't actually solve the levels, they show something that doesn't work then nuke the lemmings.

I also uploaded a video of the first such replay:

This shows a level that hasn't been seen (except by testers) yet.

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

I would prefer (c). To my mind, an ohnoer is already a dead lemming, and seeing the ohno animation is just flavour. They shouldn't be available for assigning skills. (Can you assign climber to a normal walking ohnoer?)

You cannot assign any skill to an ohnoer. This situation arises because the ohnoer hits the water and becomes a drowner, which you can assign one skill to - a swimmer. Assigning a swimmer to a drowner, causes them to transition from drowning to swimming immediately.

Bugs & Suggestions / [BUG][PLAYER] Swimmer-Drowner-Bomber physics bugs.
« on: August 20, 2019, 07:44:04 pm »
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).

And actually the digger behavior you are seeing in NeoLemmix is somewhat unique to DOS Lemmings.  In other ports like Amiga etc., the digger cannot go on with quite as little terrain as you can in DOS version.  They still don't need all 9 pixels but it's not like in DOS, where even a single lone pixel on the sides is enough to keep digger going.

If my understanding of Amiga physics is correct, NeoLemmix's digger is closer to that than it is to the DOS one. The outermost pixel on each side is not checked during the "stop or keep going?" check.

I haven't actually tried out yet whether Shimmiers can be canceled with Blockers. My guess is no. In this case, we'd run into somewhat of an inconsistency with the upward Digger, because regular Diggers can be canceled with Blockers if they have no ground under them. So it would be confusing for player expectations, depending on whether the player expects the Driller to go along with the Shimmier or with the Digger.

I just tested what happens with an interaction between a shimmier and a blocker. The shimmier turns around, which is what I expected.

Strato is talking about a different behaviour here, I think - and such behaviour definitely should not extend to shimmiers.

Assign a digger such that, at some point, he'll have no terrain immediately under him, but just some slightly to either side to keep him going. One way to set this up is to, in a level in a straight-edged graphic set, assign a builder at the very last pixel before a drop, then dig after the lemming steps onto the first brick. Once the aforementioned situation arises, assign a blocker to this digger. The digger transitions to a blocker (basic rule: "Blocker can be assigned to a digger"), then immediately does what blockers do when they have no terrain right under them. This is a relatively uncommon trick, but it's seen use in several levels (and challenge solutions) by now.

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).

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).

Currently, there's no formal structure of how NL releases are timed. I don't know if Nepster had a system; but for me, it's always been "I have a release ready? Release it."

I have proposed (and will probably adopt) such a schedule, as per my recent topic on the main board, but I'm seeing if anyone has any feedback on that first before committing to anything.

Fully fixed in commit 55DBF96.

Okay, so this is weird - the Delphi reference materials suggest that resizing is always possible; a "resizable" option (ofEnableSizing) exists, but supposedly does nothing; however, when I added it to the dialog's options flags, it became resizable (but aside from that, it remained as it currently is in 12.6.2).

"Resizable" is acheived in commit B3751D7, but I'd like to if possible fully restore them to how they were in the XE6 builds, so leaving this as an open topic for now.

I'll investigate more later - but, does this happen with levels that have at least 2 lemmings? There was a known issue in previous versions (although it's supposedly fixed now, according to Nepster - but maybe it snuck back in at some point) where levels with 0 or 1 lemmings displayed incorrect postview messages.

And the above are all fixed. Fingers crossed that this time is the good one! :D

As mentioned, one level ended up having to be replaced due to backroutes I couldn't see any way to fix. Since it won't be in the final pack, here's the removed level, "Four Towers" (a mid-Mayhem level), along with a replay to show the intended solution. It will replace Fun 9.

If you aren't able to use L3DEdit to load the replay, rename it to "REP.000", put it in L3D's "REPLAYS" folder, and wait at the title screen for the game to go into demo mode; you'll see the solution replay for this level as the first demo.

In Development / Re: Lemmings Redux (new-formats): Coming soon!
« on: August 20, 2019, 12:07:40 am »
So... I could replace "Oh No! Squish" with "Where Lemmings Dare" and new-formats Redux would be ready to release right now. I also know it's urgent to release the pack so it can be included in the NeoLemmix installer. But I also think the community should have more time to give input on such a major change, especially as we had a philosophy all along of deciding on everything by group consensus.

It's really not that urgent. It would be nice to have it in there, but I can modify the list of "included" packs at any time - all that's needed is a reliable download link for the pack, and for it to be ZIP'd in the correct way (and there are several options here). Certianly, not having new-formats Redux released will not hold up the ability to release the installer and/or require an installer version update to be made - it's just a change to this text file hosted on

Regarding talismans - firstly, 36 seems just as "rough" as 34 to me. Pretty much, anything that doesn't end in a "5" or "0", or consist of the same digit repeated (eg. 33 or 44 etc), is going to feel like that. I also question if many players would even consciously take note of how many talismans there are. I think the ideal rule here is "unless you have to limit yourself to avoid having too many, just put a talisman wherever it feels right and don't worry about the exact quantity".

Pages: [1] 2 3 ... 635