So, similar to NeoLemmix, I haven't had so much interest in Loap lately. On top of that, unlike NeoLemmix, there's also relatively little community interest in Loap at the moment.

With this in mind, I don't see much point in further development of Loap. The current version, while it does have some minor issues, is completely usable and allows playing all existing L3D content, and is compatible with user-made content via L3DEdit. And it's open source, so if the interest is there, anyone can pick up and take over development of it - and I fully encourage anyone with the interest and skills, to do so.

Otherwise, if 0.0.28.0 remains the "final"version of Loap - then it still means we have a perfectly viable way to play Lemmings 3D on modern hardware and OS, with some modern NL-like features, in higher resolution than the DOS game. That's still a pretty good result.

Given that not much interest is coming with them simply being in an experimental phase, and that it's desirable to move towards a release, I'm going to go ahead with the objects in their current state (and rely on "hopefully users will create the objects later"). If bugs arise, they can be fixed later (and an RC phase will still happen, of course). It's simply going to be over to the community to establish the standard on how they should look etc. Sounds can be changed in a later update if desired.

If I remember correctly there were a few remaining matters I needed to look at before going RC, but I'll no longer delay that on the basis of wanting more feedback for the new objects.

Just to be very clear, this is NOT saying "the new objects are not going to happen". They are. It's just saying I'm not going to hold things up any longer on the grounds of that there's still room for more feedback - the RC phase and 12.14 will be the avenues for addressing this if necessary.

Was making a solution replay for Mayhem 20 of LP3D, encountered some cases where the alive lemming count went down after backwards framestepping (then come right after further steps). I suspect some of the "checkpoint" save states aren't being erased correctly but haven't looked into it yet.

Using the latest source at the time, which has a few changes from 0.0.25.0.

So while I've ruled out any possibility of a full VR mode for Loap due to the complexity that'd be involved, I am open to the idea of supporting stereoscopic 3D - basically, the kind of thing you'd get from a 3D TV or a Nintendo 3DS. I'm wondering how many people with interest in Loap would (a) be interested in such a feature, and (b) actually have a means of using it (a 3D TV / monitor or a VR headset).

This should be relatively simple to implement - a slight caveat being I don't have a 3D TV, so I can't actually test that option of using it; I do have a VR headset so can test that.

I've been thinking about this as an idea - instead of making a new editor for Loap, making a fork of L3DEdit that edits Loap levels rather than DOS L3D ones.

Many of the things Loap would need, would be fairly trivial to add to L3DEdit. (Many. Not all.)

Downside is this would mean having only an isometric view while level editing. There are a few things that would be hard to visualize in this view, in particular default camera angles. There's also the issue of what happens if Loap in the future supports 3D models for interactive / decorative objects; supporting these in L3DEdit would not be easy.

A bigger downside also is that L3DEdit is not as easily cross-platform. Although it can be (and has been) built for non-Windows OSes, it doesn't perform nearly as well on these platforms, due to using Lazarus rather than Delphi to compile on them. (The worse performance also occurs in Lazarus-built Windows builds, but on Windows the option of using Delphi is there.) I believe L3DEdit runs fine under WINE so this isn't too bad for Linux, but it will leave Mac out.

One reason for this is effort - there hasn't been much interest in making L3D custom content so far, so I'm not sure if it's worth the effort of a full new editor for Loap. Using L3DEdit as a base removes a lot of the required effort.

DireKrow mentioned a while back on Discord that a replay insert mode and a replay editor, similar to what NL has, would be good features.

A replay editor probably won't happen. Implementing this while in-game, without Windows forms as an option (due to Loap being at least theoretically cross-platform - I intend to make Linux builds once it goes stable, and it should also be possible to build for Mac), is going to be trickier than I think is worthwhile.

Replay insert mode is definitely something that can and should happen. To cover the main important functionality of the replay editor (removing actions without erasing later actions), I was considering a "replay suspend" mode - where you can press, or perhaps hold, a hotkey to ignore any replay actions temporarily (and thus remove them from the replay), while any actions that come after you switch back out of this mode would still replay as normal, at least to the extent they can.

So, I haven't really been getting much work done on NeoLemmix in the past year and a half or so. A bit here and there, but not nearly enough to really keep the project going.

NeoLemmix is, overall, in a good state. Sure, there are some UI bugs that would be nice to get rid of, some room for better QOL features, etc, but overall, it's the most popular engine for a reason - because it's in good shape, it does what's needed, it isn't overly bloated with features, etc.

I had already decided to work towards a final version as a vague goal, but I have made the decision that I'm going to move very quickly towards that now. Most proposed features / suggestions are not going to happen, and likewise for minor fixes.

I do intend to do one more major update in the traditional sense (ie: an update that brings significant new features), with possibly one more "major" version after that for bugfixing purposes, in particular for any bugs that are introduced in the next update. This is because of the new objects - they are very close to ready, and it doesn't make sense to throw that work away at this point when not much further effort is needed to get it ready for release.

However, other proposed features - such as an improved replay editor - are going to be discarded, so that things can be wrapped up. I am also going to discontinue any further work on the editor, except for what is necessary to properly support the new objects (most of which is already implemented in the codebase and released in experimental form alongside the new objects experimental player).

I realise this might not be the news some people wanted to hear, but it had pretty much de-facto become the situation anyway - all I'm really doing here is making it official.

To address this before anyone suggests it - no, I do not want to hand further development of the game over to someone else. With that being said, NeoLemmix is open source, and anyone who wants to do so is welcome to fork it to create a new engine - SuperLemmix is already a case of this, though it may be that someone wants to create a fork that retains the NeoLemmix philosophies but continues to add / improve new features within that. It would then be for content creators and players to decide whether to adopt the fork or stick with NL's final version. Likewise, anyone who wants to create their own editor (either using the existing one as a basis, or an entirely new one) is of course free to do so. NeoLemmix and its tools will remain open source and free for anyone who wishes to fork, to do so.

So yeah, it's probably time to start thinking about the visual side of things.

Normally, I'd come up with something, use it in one of my new styles, and see where things go from there. But, I don't have anything ready to release any time soon. I could add them to some existing styles, I guess... either way though, some discussion needs to be had about what these will look like.

Portals - the idea of swirling vortices seems popular. This could be in some kind of frame similar to teleporter designs, but with a constant vortex animation in the "doorway"; or could simply be a portal sitting out in the open.

Assigners, Deassigners - first I'll note, Assigners are capable of (and should be) using the same functionality as pickup skills do, in order to show the skill they assign. The rest of the design needs to be clearly different, though. Clear physics mode can reveal the skill in the case that a graphic doesn't, but this is a failsafe, not the intended way of telling the player the skill they give. Following on from this, I feel the standard for deassigners should be similar to the same style's assigner (same shape, possibly different colors or minor details), perhaps with a red X where the skill icon would go on an assigner?

Neutralizers, Deneutralizers - I don't really have any good starting points on these ones, aside from that again they should look similar to each other, and we should probably settle on some universal indication of which is which (similar to the "In" and "Out" on teleporters and receivers).