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).

Edit Simon: I've split this off Fork: SuperLemmix.

---

I'd probably want to try and find a way to make it so it's the same speed regardless of what computer you run it on, and at this point I have no clue how this would even be approached. "if Superlemming=true, enable fast-forward" is relatively simple, whereas dealing with frame rates directly I can imagine will be much more difficult.

NeoLemmix sets a frame rate cap and runs as fast as it can subject to that cap. If the hardware can't manage the full fast forward speed, it'll just run as fast as it can. In extreme cases (slow hardware and/or large levels or with a lot of objects), it might not even manage the 17FPS of normal playback - again, in such a case it'll just run as fast as it can. Superlemming mode, back when it existed, just altered the frame rate caps.

Unless you can find a way to replicate the exact physics (or something you deem close enough and bug-free enough, if you're okay with breaking exact physics) with more efficient code, the only way you're getting around that is by frameskipping (ie: not actually rendering every frame if the hardware can't keep up).