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 4 ... 636
Things are looking really good now. There's currently only two remaining levels that keep getting re-backrouted - one of which the backroutes are getting more and more complex, to the point that it's almost a case of "time to stop fixing them, because the backroutes are more obscure than the intended solution". Both of these levels are in Mayhem. (EDIT: And down to one now!)

It shouldn't be much longer until release time, now. :)

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 :D . 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.

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... :evil: 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... :D

Spoiler (click to show/hide)

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

...some of my own levels (click to show/hide)

...or even older...

*Not* one of my levels (click to show/hide)

When this happens, can you scroll by holding the right mouse button and dragging?

I'll try and look into this at some point, though I'm not entirely sure what I'll be able to do about it.

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.

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.

Pages: 1 [2] 3 4 ... 636