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

Version 6

All commits squashed to Exit-To-Postview Behaviour Parts I, II and III, which will feature in the Pull Request.

This version is correct to commit 00a392b on origin/master, which includes the GR32v3 update - note that this update will NOT feature in the PR as it will mismatch with NL 12.12.5 codebase

Improved icon graphics, plus they're now centred over the object:



Very happy with this, and now I can concentrate on the Player-side implementation of the Rivals feature.

Implemented in Commit 0d857fb