I absolutely agree!:thumbsup:

Glad to have some agreement on this

The reason oh-noing is expected is because the lemming’s position marker is inside the wall, i.e. on terrain.
This is different from Swimmers and Shimmiers, for example, who have no terrain under / at their position marker.

Indeed. But, if anything that's what convinces me that it's moreso a by-product of the physics rather than a conscious decision or what makes good sense.

If it were the other way around (so, the lemming had to be moved 1px into the wall especially so that it entered the ohno phase), would this change be made, or would the ohno phase be left as a bypassed state?

I tend to take Amiga L1 as being the de facto "original", for which other ports/versions provide replacement or additional levels. In my own view, this isn't arbitrary; the game was designed for and on the Amiga, so I'll always tend to see that as the true original version (the fact I grew up with an A500+ has some bearing on this view as well, admittedly!). Some ports (DOS, Atari ST) reproduce the game level-for-level without replacing or adding anything, whilst others remove levels but don't replace them (Windows 95).

Here's how the current non-L1/OhNo/Holiday levels break down in terms of number of levels, and whether they are "replacement" levels (i.e. replacements for Amiga/DOS L1 levels), "additional" (i.e. provided in addition to Amiga/DOS L1 + replacements), or whether it's completely its own game (i.e. independent from Amiga/DOS L1 entirely).

"Bonus" groupss in L1 and OhNo:

(L1 "Bonus" - Taken from various ports including Mac and SNES) - 10 (replacement)
(Oh No! "Bonus" - a DOS replacement of a level from Holiday Lemmings) - 1 (replacement)

And then, in the "Extra" group:

Covox - 8 (additional)
NES - 25 (replacement)
PSP - 36 (additional)
PS3 - 45 (its own game)
Prima - 16 (additional)
Genesis - 45 (replacement) | Present - 30 (additional) | Sunsoft - 30 (additional)
SMS - 12 (replacement)
ZX Spectrum - 16 (replacement)

That's 274 levels altogether, probably too many to make into a single pack, but if we keep the PS3 levels as their own pack, we could potentially divide the remaining 229 levels into 2 packs.

"Yippee! Even More Lemmings" would be a good title, as it follows on from the idea of the "Oh No!" title and would technically be an expansion pack if we use only "additional" levels to build it (there just happens to be exactly 120 additional levels - perfect for a 4-grouper with 30 levels per-group!)

That leaves 109 "replacement" levels which are port-specific. Perhaps "Multiverse Lemmings" or "Parallel Lemmings" might be a good title for this, or if people don't like the idea of seeing non-Amiga/DOS levels as "alternatives", we could go with something else.

Thoughts?

Refactored the animations loading today. Moved incidentals such as countdown digits, highlight arrow and pickup/hatch/exit numbers to the "effects" folder in styles/default. This means that they can now be customised per-style. It also means that gfx/masks now contains only essential, non-customisable graphics for rendering skill actions in-game.

LemAnimationSet's ReadData is now renamed to PrepareAnimations, and has been refactored for readability.

This has come about in part due to the way that Exit Markers are handled (still a work in progress for now, but getting to a more settled place), but also because with grenades, spears, balloon pop, Freezer overlays, invincibility overlays, etc, this procedure is getting increasingly busy. Well, that's been improved now and the code is much more streamlined. I've also renamed some variables to make it clearer what's happening throughout, particularly where the sprites are loaded.

This post is really just to log the change publicly and make a note of the commit for future reference. (Simon showed me how to rebase commits recently, and it's been an absolute game changer for my natural workflow.)

Squashed all associated commits to 0b9c489b8.

Added a poll; I could do with some help making a decision if you have a moment.

At the moment, deleting the top row of pixels from the level seems like the best way to achieve the top-of-level behaviour that I'd most prefer for SLX; i.e. the top is open, and accessible, but lems must remain visible if/when they access it. This is infinitely preferable to the pseudo-forcefield behaviour in current SLX, which is messy, buggy and unreliable. A blank top row limits all top-of-level behaviour handling to a handful of edge cases (namely Ballooners, Swimmers, Builders, Freezers and Stackers), eliminating the need to also handle many other lemming actions and manually inhibit top-of-level skill assignments.

Namida has already suggested adding a blank row rather than subtracting an existing row; a good idea in principle, and one I considered at length before deciding on subtract. Reasons here.

If people don't like the idea of a blank pixel at the top of the level, it is actually possible to make the top pixel non-solid, but still render it. This preserves the appearance of the level whilst still making any lems at Y = 0 visible.

So, the question becomes: should we continue to render the top row of pixels, and only have it blank in-physics (CPM reveals this), or absolutely delete it so that it matches physics?


Verson A - pixel is removed in-physics and deleted in rendering


Verson B - pixel is removed in-physics, but rendered

Version A is visually consistent with what will happen when a lem reaches the top of the level, but modifies the level in order to achieve this. Version B is potentially misleading and involves essentially fake pixels, but preserves the level's aesthetic.

I've voted for "delete" because ultimately I don't want to mislead players, and the game should be visually clear. However, I can see a case for "render" in that it's top-of-level behaviour: the effect could be seen as the lem reaching a forcefield, and we generally don't want lems getting to this point anyway.

Please vote, discuss, etc. I have no strong preference either way at the moment, the poll will help me to decide what to do. Or, if you don't like either option and you have any other suggestions for top-of-level behaviour, please put them forward. Thanks!

I'd now name the option in the text file "ExitToPostview" (without the redundant "Option" at its end; everything in the file is an option)

Agreed, this is now done. Committed and pushed.

You still have 3 internal variables, which can be a similar source of bugs as the 3 exposed options from the text file.
...
Track the option internally with one variable ... Consider an enumeration

I tested the Exp 6-A. Everything looks good:
...
In the end, it's up to you how much of today's feedback ... you still want to implement.

This might be a case of "if it ain't broke, don't fix it!" The options all play nicely now, and I've tested thoroughly for nonsensical values, setting all three to true, etc. The codebase already has it built-in to ignore all but the first declaration of the option in settings; this should be sufficient for preventing the option from being set to two things at once.

And OK, there's some risk that it might be set elsewhere during gameplay, but tbh I can't see how that would happen. If the user changes the options between levels, for example, it's saved correctly. If they change the option via the text Editor, they must then re-load NL for it to acknowledge the option change (or at least keep using NL until the options are re-loaded, at which point it will be correctly set). AFAIK, default options are only ever explicitly set upon loading a brand new copy of NL, and never again after that.

I understand your desire for the singular option, but there are benefits to keeping them separate (and, identified by strings rather than numbers). My instinct on this one is, let's keep it as it is at least for now.

That's not to rush things, it's genuinely what I think is best.

Monday is fine for another Mumble sesh. I'll need help doing the PR anyway, and we can go over anything else that might need to be looked at first. Speak to you then if not before, W.

Revisiting this one again after a few top-of-level bugs have been found. Let's review what's going on with level-edge physics in SuperLemmix so far:

Bottom edge is a deadly void, as in all Lemmings games (if not most games in general). This is as expected and will not change in SLX.

Left and right sides are forcefields; a lemming encountering a side edge will respond to it the same way they would respond to a Blocker or a One-Way-Field. So far, I think this is working nicely and is actually the best of all possible behaviours, with horizontal wrap being a very close second. It's likely that SLX will keep "sides are forcefields" from now on.

So far so good. Only the top edge remains something of an issue:

Top edge is currently a pseudo-"forcefield", in that there isn't actually a horizontally-oriented forcefield in the game, and so SLX code must treat all lemming actions separately and decide what to do based on the action, the surrounding terrain layout, and various other factors. There are some inconsistencies (e.g. Jumpers can leap out of the top of the level, whereas Ballooners are nudged downwards by the "forcefield"), and despite my best efforts to nudge, turn and cancel any actions which result in a lemming accessing the topmost pixel of the level (and thus disappearing from view whilst remaining level-active), it is still possible to glitch one's way up there given enough skills and determination.

The code is also a mess; it's become necessary to factor in "Lem is at Y=0" when deciding whether or not to allow skill assignment, and the top-of-level checks are much more verbose than I'd like them to be.

So... I'd like to try the idea of always deleting the topmost row of pixels from the level. Effectively, the top of the level would then always be visible, and so it would be fine for lems to access it; we'd have no need for disallowing skill assignments (except Builders, Stackers and Freezers), and it would greatly simplify the "top is forcefield" behaviour generally. The aesthetic effect is also barely noticeable.

Let's give it a try in 2.8 and see what we think. Comments are welcome as always, and if people don't like the idea it's very easy to revert back to existing behaviour.

Wrong default out of box.

...

we agreed that the default should be to exit if we have won, and show the panel message when we lose. This is the most appropriate default.

Agreed, "End if Level Passed" should be the default - this has now been fixed, committed and pushed. I think I set it to something else during testing and forgot to switch it back. Good catch.

File contains three options, not one

...

Expected: One of the lines is for the end-of-level behavior.
Observed: Three of the lines are for the end-of-level behavior

...

I recommend to store one line

Yes, very good shout.

The option is now stored as "ExitToPostviewOption" with 3 possible strings, one for each option ['Always', 'IfLevelPassed', 'Never']. If the string in the config file is one of these 3, the correct option is loaded. If it's is anything other that these 3 (so, blank or nonsensical), we simply load the default. I believe this should also address the third of the concerns in Reply #113. Committed and pushed.

EDIT - Also, if the user writes multiple lines into the text file for the same option, existing behaviour is that only the first one is loaded & handled, and the rest are discarded on saving. Perfectly elegant, does the job.

Here's V6-A which implements these fixes (to Commit a2610dc). Meanwhile, it sounds as if the MRC is behaving as we'd like (apart from the bug you reported here, which I'll probably fix myself in SLX and can always port across to NL at a later date).

I'm thinking we're ready for the PR now. Do let me know if there's any other last-minute tweaks you'd like to get sorted before we next review.

These are just the sorts of styles we need - clear theme, beautifully crafted, high versatility. Excellent work, Dexter