Okay so, I've often mentioned the reason terrain grouping is missing in NL is because the editor's file parsing code is written in a way that could lead to it being unable to load perfectly-valid level files that use terrain grouping, depending on how they're structured.

I've finally gotten around to writing new file parsing code for it that averts this, and as such, been able to enable terrain grouping (the underlying functionality of which has been there for ages - it's just loading and saving that was missing).

However, as this is a very major change - and I don't know how well-tested the grouping feature is (although it's Nepster's code, so I'd guess probably pretty well tested) - I feel an experimental build is a must here.

So - here you go. If you want to try out piece grouping, or just help test in general, download this editor. Save often, and be prepared for the risk of data loss. If a file does seem to have data loss when you load it, try loading it in the old editor or in NL - if it works fine there, it could be a bug in the new version's loading code.

Download: https://www.neolemmix.com/download.php?id=429

If an existing level isn't loading properly, run it through Cleanse Levels. When writing the new level parsing code, I have not bothered to maintain backwards compatibility for pre-V12.7 NXLV keywords. So, any levels that predate this won't open.

And to be clear - you do NOT need a new version of NeoLemmix to go with this. NeoLemmix itself has supported piece grouping for a while now - it just never had the corresponding editor support. Use this experimental editor together with the current stable version of NeoLemmix.

Many of you will already know about this from Discord, but I've been working on a new side project - one that, for once, is actually going somewhere.

Introducing Tiel Attack.




This basically started as my "quarantine project", and while work has slowed since then due to, well, being back to actual work; it's still progressing, just slower than before.

Tiel Attack is a 2D sidescrolling platformer, with the notable feature of being a single huge map rather than many smaller ones. The game is semi-open-ended; there's an intended linear progression (with slight flexibility) of the bosses to fight, but some freedom in exploration rather than being railroaded towards each boss.

You can also, for the most part, choose to play as Don or Nod. There's some limits on this - Nod can't get out of the starting area until a little bit later in the game, and there are some areas that require both tiels working together. But the rest of the time you can choose - Don's higher jumps, or Nod's stronger attacks?

And yes, it features my cockatiels Don birb and Nod brib as the playable characters.

Download Demo (V6): https://www.tielattack.com/TielAttack_Demo_V6.zip
Requires a 64-bit Windows OS with .NET Core 3.1 (which in turn requires Windows 7 or higher, I believe). May or may not work on WINE, feel free to try and let me know. CPU is more important than GPU, and RAM requirements appear to be quite low (it uses less than 128MB of RAM while running, in my experience).

This demo allows you to play up to and including the first boss. It also allows some very limited exploring of side areas.

Okay so, it didn't take long for this to get out of control - to the point where the SAME person posted three different L1 conversions, simply to reflect the slight differences between three official ports. So, while I'm sticking to that I don't want to maintain any official conversion (and indeed that I don't think there's a need for one), I'm also going to take steps to ensure there isn't a ridiculous proliferation of them either.

There's three options I'm open to here:
1. Declaring one person to be in charge of conversions.
2. Declaring one particular conversion of each pack (or in some cases, collections of packs) to be "official".
3. Prohibiting such packs altogether, with a special exemption for Redux.

It goes without saying that my favorite is #3, but I'm guessing that won't go down well, so let's talk about whether approach #1 or #2 is the better one to take.

There are some standards I expect in either case, for any conversion:
1. The most critical NL community standards will be respected. By this I mean - I don't care what decision you make around time limits or lemming counts, but unhide the traps (special cases can apply to the hidden exits in the few official levels that have them. That is the ONLY special case I will accept), don't have weird overlaps of steel and non-steel, etc.
2. All levels should be confirmed possible to solve. For cases where a direct conversion is not possible to solve, it is up to the author how they address this.
3. Consistency. If moss-on-steel is handled by total removal in one level, it shouldn't be handled by moving-away-from-the-edges in another. A level and its repeat should retain identical layouts, unless they already had differences. This also means that as far as possible all levels should originate from the same port. Of course, if a level is exclusive to certain ports, that's another matter, but if you're eg. mostly taking levels from Amiga, there shouldn't be one or two that are taken from DOS instead.

Okay so, these existed in the past, but were culled during the move to new-formats.

These of course would be purely a thematic thing, with no gameplay effect. They animate when a lemming walks past (presumably, both a "once" and a "infinite" version could exist), but otherwise do nothing.

The common argument against them is that if an object looks like it gets triggered when a lemming walks past, it should do something, and that it's misleading if it's not.

I'm not convinced by this. I do understand where it's coming from but, "nothing" is just another possibility to a list of things it could do. Without any context beyond "it animated when a lemming walked past", you don't know exactly what it does. You have to either look closer, or use CPM, to find out regardless - or, use context, like "what does the object look like?", at which point these are no different to anything else in regards to "don't make them look like things they aren't". (Even if you look at "did the lemming disappear?" - if it does, that could be a trap or a teleporter. If it doesn't, that could be an unlock button, a pickup skill, or a splitter that's pointing the direction the lemming is already facing.)

The benefit of course is purely an aesthetic one; but the effort to do this is relatively low - almost all the code could simply be copied from traps, with the "kill the lemming" lines removed.

One other reason is - some people have expressed interest in trying to do this anyway; one even trying to figure out a workaround to emulate this with features that do exist (it's possible - but I'm not going to explain how, and I don't believe that person figured it out). This may be a case where it's better to implement it properly, at which point CPM can hide or appropriately label it, or even potentially an option can be added user-side to hide them (or make them not function).

What's other people's thoughts here? Does anyone feel I'm underestimating how significant the "it should do something" factor is, or that there are other reasons against this?

Doesn't always happen, but in some cases, the shadow will imply that the shimmier won't succeed, but when used it works fine. This seems to be purely a bug with the shadows.

This happens at the height of the jump when the gap between the floor and ceiling is 26px. It also happens at most, but not all, gap sizes lower than 26px on the last frame before the jumper hits his head and becomes a faller. It doesn't seem to happen when the gap is larger than that.

Three things to discuss in relation to these:

1. Whether they should be kept at all.
2. If so - would you use the ability to provide custom ones for your packs, if it were supported?
3. Does anyone enable the success jingle but not the failure one, or vice versa?

Let me be very clear - I'm not very strongly on the side of making this work again. And I want to stress this: Please do not create packs that "require V12.8 exactly". V12.8 isn't a "notable" version in the same way V1.43 (last stable version before some major culls) or V10.13.18 (last old-formats version) is; making packs that will in the future require people to dig it up is very, very messy; and it's very arguable you'd be doing so not because of a culled feature, but because V12.8 has a bug that later versions don't (see below for the logic behind this claim), which is extremely contrary to NL's philosophy as bugs shouldn't exist, let alone be intentionally used by content. Affected levels can very likely be adjusted to use jumpers instead, or some other workaround. (It's different if you put a "this isn't yet tested for V12.9" note on an existing pack; I'm talking about new releases here, especially in the more distant future as opposed to something you've just finished and were ready to release but got hit by this issue.)

As background - there was a bug in older versions where the timing of the faller -> glider transition would depend on what the lemming was doing before becoming a faller. This is now fixed in V12.9 to be consistent, but one side effect is that the Stacker-Shimmier-Glider trick (where you assign a shimmier to a glider right in front of a stacker's stack, so they jump and land on top of it) no longer works.

There are basically three ways this can be handled. In order from my strongest preference to least preferred.
a) Accept this. The logic here - while the trick itself might seem fine, and indeed was accepted by some users who generally speaking have very low tolerance for weird or glitchy physics cases, it only worked due to an underlying bug. Therefore, it would make sense that, like any physics bug, it should be fixed. However, a counter-argument is that at this stage, NL is accepting some very minor ones (such as the floater equivalent of this very bug, which rather than actually seperating lemmings, might just cause a difference of 1 frame in how quickly they hit the ground).

b) Introduce a special edge case where a faller who transitions from a reacher, pulls out the glider slightly earlier than he normally would. This has minimal side effects but does mean there's another special case, just to preserve a behaviour that originated as a bug. Still, perhaps there's some argument as to why this makes sense (that doesn't rely solely on "we could do it before, so we want to still do it now").

c) Revert the fix, and accept the pre-bug situation. The original bug, while very specific, lends itself to creating very trollish levels once a designer is aware of it. It could also in less-dodgy situations, lead to weird unexpected outcomes in challenge runs or when trying things on particularly tricky levels. Not to mention, I kind of feel that "side effects are too much" is the kind of thing that doesn't get decided retroactively; if it wasn't so bad that people were complaining during the RC phase (during which the only complaints related to window sizing / positioning), it's not bad enough to warrant reverting a bugfix. So, option C is pretty much "theoretically, this could be done, but it won't happen".