@geoo

Thanks for the info, I’ll take a look at the assets later.

Conversion via script is a good idea. It would only have to be done once, assuming it works and all goes according to plan, so doesn’t need to be too pretty. Thereafter, the levels would exist in NL format and can be edited as necessary.

I wonder whether the levels could be saved as bitmaps somehow. These could then be used as backgrounds in the Editor, so at least if something went wrong in the script conversion it would be somewhat easier to make corrections as necessary.

OK, this is still happening in v2.7.3 (screenshot attached).  I have been able to replicate this numerous times now.  It seems to occur when I browse through the different level pack/groups, expanding and then contracting different levels in the tree structure on the left.

OK, I've added this to the list of known bugs and will try to find a fix at some point.

It will work fine to start with, then will temporarily freeze/lock up, and the level select window will get the "...(Not Responding)" message in the title bar.

I've noticed this as well, it's been happening for quite a while. I've also added this to the list of known bugs; the level select menu in general could do with some debugging and bottleneck fixing. I'll take a look at it and see what can be done.

would having a level set in SuperLemmix, divided into groups named for each of the L2 tribes, that visually resembled the L2 levels, had the same music/sfx, etc but just using the closest equivalent skills that are already available in SLX - thus avoiding extensive new skill coding/interaction coding/testing - be a feasible option?

Yes, absolutely.

This has previously been suggested by Strato as a project for NeoLemmix, but that was back in 2020 and not much has happened towards it since then, as far as I'm aware.

Given the scope of SuperLemmix to introduce more L2-like skills, features and mechanics, such a project may be better suited to SuperLemmix anyway.

The bulk of the work then would be recreating the levels themselves and SLX-tweaking them as required.

This is indeed the rub. It would require a lot of manual conversion work, since there doesn't yet exist a way to rip the level maps directly from any version of L2 (that we know of).

Ideally, we'd have a team of as many people as there are tribes, and each person would recreate all levels from just that tribe. Even then, it's a lot of manual effort, quality control, testing, etc. It would be an enormous project, and so far there simply hasn't been enough sustained interest to get it off the ground.

With that said, I'll keep nudging the idea forward now and again, and might begin work on the Beach levels at some point if I have enough time. That should help to get things moving if it ever happens, and it isn't a promise by any means.

I don't know if a similar plan would work for L3 as I have hardly ever played that, and not for many years.

I imagine it would involve essentially the same process: manually recreate the levels, assign suitable skillsets to make them playable.

---

Just going to throw this out there one last time: does anyone know of a way to rip the maps directly from one of the many L2 source disks?

DOS, in particular, seems promising, and we can rip .lvl files from L1's Amiga .adf so I wonder if the same thing can be done for L2 and L3?

NL 12.13 Exp V8 (commit a9709ba)

EDIT: Attachment removed due to release of NL 12.13-RC

Yes, Wednesday, 15th ... 18:00 UTC it is, i.e., 19:00 English daylight savings.

See you tomorrow!

Confirmed, see you then!

Wednesday, 16th, from 16:00 UTC is good. I'll have time until 21:00 UTC. Please choose a definite starting time beforehand, and I'll confirm it.

I assume you mean Weds 15th? I should be able to make 1900 GMT (so, 1800 UTC?) that day, possibly even earlier. I've added it to the calendar. W

OK, after giving this a few days' background thought, I think it would probably be best to just keep the top of the level as a forcefield, same as the sides.

However, I'd like to implement it as concisely as possible. At present, the side forcefields are only 3 lines of code each, and deleting the top row of pixels is a small block of code comprising only 4 lines. The top forcefield should be similarly non-verbose.

I've found a much simpler way of disallowing skill assignments at Y = 0: simply add the lemming to the existing list of non-assignable lems (i.e. Zombies, Neutrals, etc) whilst at this position. Much better than handling it per-skill.

Meanwhile, the forcefield turns Walkers, and nudges all other movement actions (Swimmers, Gliders-in-Updrafts, Ballooners, even Jumpers!) downwards into the visible frame. Climbers are cancelled around 7px from the top to prevent them from entering the Hoisting state.

Freezers at the top-edge and bottom-edge have also been considerably bugfixed and refactored. I've removed some fiddly Freezer code which previously prevented them from falling out of the bottom of the ice cube when assigned off the bottom edge of the level, and fixed a bug which caused them to ascend out of the cube when assigned too close to the top for enough of the ice cube to exist; in these cases, the assignment is now simply disallowed. This might seem a bit heavy-handed, but it eliminates a lot of fiddly code and fixes the associated bugs.

So far so good; it's still not quite as concise as just deleting the top pixel, but it feels much more consistent with what's happening at the level edges.

All of the above implemented/re-implemented in commit c0433cf6b

---

Question: What should we do about lemmings with countdown timers?

It is still possible to reach the top of the level if this particular setup is achieved:



Note that the purple bar along the top has been destroyed enough from the bottom in order to create a 6px ascendable step from the Builder bridge, but remains intact along the top so that when lems accessing the top are turned around, they simply walk along the still-complete bar.

Since skills are not assignable to any lemmings at this position, getting them here isn't necessarily particularly useful. However, since we now have Timebombers, Slowfreeze and Radiation, it is theoretically possible to send a lemming with a timer above the level, to have them later detonate.

Slowfreeze is, again, not much use here: any terrain above the level is always automatically destroyed, so detonating a Slowfreeze lem here is a waste.

Timebombers and Radiators, on the other hand, are much more potentially problematic: they can destroy the terrain from above. Whether or not this is a problem depends entirely on the layout of the level, of course, but it does raise the question of whether or not we want to allow this.

I would tend towards not allowing it, for the simple reason that the lems are not visible from the top of the level. Whilst I'm all for encouraging the skill of judging a countdown timer to get a "just right" Bomber assignment, once the player can't see the timer digit or the lemming, it verges on the unfair.

The question then becomes what to do about it. We can do one of 3 things:

1) Set the timer to 0 immediately, so that the lem detonates instantly on contact with the top of the level.

2) Suspend the timer until the lem re-enters the visible area.

3) Cancel the timer altogether, so the lem is no longer a Timebomber/Radiator.

The first of these options is more or less what would happen if we remove the currently-implemented "LemHasTurned" flag, which tracks that a lem has already been turned by the forcefield, so shouldn't turn again. This would result in a lem infinitely turning on the same pixel point, and eventually detonating.

The second of these options is elegant, and keeps everything visible, but could potentially result in some very questionable level design. Levels that make use of this could be interesting, but would ultimately feel too much like "glitch levels", i.e. relying on some obscure mechanic for the level's solution - not really what we're aiming for here.

The third of these options would likely be very confusing to the player and feel like an unintended bug, and so is very unlikely to be chosen above one of the other two options. I've mentioned it simply for completeness.

The first option seems, then, to be the best. Let's sit with it for a day or two and see if it feels right.

Suggestions and feedback very welcome.

Let’s go with “Multiverse Lemmings” for the 109 port replacement levels. We can fashion the logo using letters from the various ports.

Rather than just have 109 levels though, which obviously doesn’t split nicely into groups without remainders, we should add 11 levels to make it 120 and have 4 groups of 30 levels.

To achieve this, we can do one (or a mix) of the following:

1) Choose our favourite 11 levels from L1 and remake them using OhNo! styles.
2) Choose 11 levels which are interesting in their Mac/SNES versions due to different RR, different numbers of lemmings, etc, and include those versions (only modifying the alternative elements, otherwise keeping the maps the same).
3) Include 11 L1 levels with different skillsets (but identical maps).

Suggestions welcome.