As usual, we're not going to be ridiculously strict. I'll leave it open to Simon and the other admins to decide if they want to revise these, but for now, as a starting point:

1. A maximum of two topics per project - one as an "in development" topic, one as a release topic, and please close the development topic if/when you make a separate release topic.
2. If you are not otherwise active in the community (we'll be fairly lenient on this, but not eg. accounts that sign up, post their project, and are never seen again), please do not post any commercial products here.
3. Just in case, Lemmings Forums takes no responsibility in any way for any projects shared here. This includes that if a forum staff member shares a project here, Lemmings Forums and the staff (other than the staff member sharing the project, of course) take no responsibility. Any issues are between you and the project's creators only. Buy / download / use / observe / eat at your own risk.

So, you all have seen (and if you're interested, most likely played) my RPG Maker VX Ace project, Legends of an Otherworld. As a quick recap, I started developing that game in 2011, completed about 60% of it, then it sat abandoned for years until I resumed work on it in 2017, ultimately releasing the first "complete" version near the end of 2017, with the last bugfix update bang-on new years' day 2018.

During the time the original project sat abandoned, as well as after its completion, I've spoken of making a remake of it in either a custom engine or the newer (and cross-platform) RPG Maker MV. On one occasion, I actually made enough progress on a remake engine that I had some screenshots to show off, but I eventually ended up getting frustrated with and abandoning this attempt for two reasons - firstly, that I was being way too ambitious in regards to how the engine worked, and secondly, that I was putting too high a standard on the placeholder graphics. This particular attempt was using Lazarus + FreePascal, together with the cross-platform GL-based Castle Game Engine library (which on a side note, seems like an excellent library for anyone wanting to do game design using Pascal - from what I could see, no other Pascal-based engine even came close).

Then, recently, I started to learn MonoGame and C#, and have put this new learning (which is still ongoing - I'm often finding better ways to do stuff and thus reworking older code to use it, for example, I only recently replaced a whole bunch of complex code with much simpler code using the Linq library) towards yet another remake attempt. Or at least, that's how it started off.

With this one, I deliberately put some limits on myself regarding graphics - any graphics I design, I must limit myself (except where there's specifically technical reasons not to - so far, the only case of this is the font) to a 16-color palette (the "16 colors" here does not include "transparent", so it's 17 if you include that). I've also made literal placeholders for cases where I haven't even made these graphics yet - so you might see in some WIP screenshots / videos that some NPCs, enemies or battle animations just show a graphic that says "Placeholder", or a blacked-out sprite resembling a human shape in the case of NPCs. I've also toned back the ambition a bit - while the battle system is still very complex, stuff outside of battles is not so fancy.

In what should have been completely predictable for me, knowing myself, the "Lemmings Plus DOS Project" effect quickly surfaced - you may remember that LPDOS (now known as Lemmings Plus I) started off as an effort to remake many of my Cheapo levels in the DOS game (or technically, rather, Lemmix), but I quickly ended up feeling more like making original content rather than remakes. Well, the same has more or less happened here - I've felt more like creating an entirely new game, rather than an improved remake of my original one.

So, what does that mean this project will be? It's going to be a new game, but in a sense, also a spiritual successor to my first one. While the gameplay will be fairly similar (of course, there will be many entirely new boss designs - though some general concepts will likely be reused, if maybe not exactly the same specific enemies), the setting, characters, story, etc will be completely new. At this stage, I'm not ready to reveal details about this beyond what's seen in preview content, but I'll say more in time.

---

(This is the original post where I split the topic off.

So, regarding the "remake" - I realised that I was being far too ambitious with it, especially with regards to having the pixel-perfect map movement combined with my somewhat limited graphical abilities, so I figured I was better off ditching much of this.

Another thing I've realised is that using an obscure framework like Pascal + CGE could come back to bite me later, so I've decided to start again (and indeed, I've made some good progress already) using something a bit more mainstream - specifically, MonoGame. While doing so, I'm of course taking into account things I learnt from previous test code - especially what things I was doing that might be complicating things more than necessary. (MonoGame also does a little bit better in regards to cross-platform. In particular, should I actually get this finished, MonoGame offers the possibility of publishing the game to console rather than just PC and smartphones.)

The new codebase, while not having all the behind-the-scenes stuff (support for attack data, enemy data, etc) that the old codebase had so far, already has some more-prominent features the old one never got around to, like warp points between maps (or within the same map). Probably because no more unnessecary fancy stuff this time - only putting in what's actually needed to make the game work; it doesn't have to be overly fancy.

As I do more of the planning (and coding, to some extent), I'm also getting more sure of my decision that this won't be a direct-but-improved remake, but more likely just an RPG with similar gameplay mechanics, perhaps re-using some ideas from this one (especially with regard to boss attack patterns / etc). I don't plan for the battle system (even outside of specific formulas) to be a one-to-one copy either; though it will be very similar. (One of the notable changes is that I intend to implement some form of summons, most likely an FF8 / FFX hybrid system.)

1. Playtest a level that has a preview and/or postview text
2. Get to the preview / postview text screen
3. Press Esc

You are now on the main menu screen.

This does not happen if you press Esc on the main preview or postview screens; they exit correctly. The code that detects playtest mode and terminates rather than returning to main menu simply needs to be copied to GameTextScreen.

Or, even better: When in playtest mode, change all attempts to load the menu screen to instead exit.

Steps to reproduce:
1. Start any level that has a window, wait for the direction arrows on the windows to disappear
2. Enter clear physics mode
3. Move the mouse over the window; arrow disappears
4. Move the mouse back off the window; arrow reappears

Expected:
Arrow is either always visible, or only appears on mouseover.

Untested:
Does this also apply to preassigned skill / zombie indicators? What happens in levels with multiple windows? Are there similar effects on other object types?

There's no reason to set the limit at 32 characters anymore. Older versions had no room to display more than that (and even that, the last character would get cut off if the level number was two digits). And even ignoring that, the old file format didn't support more than 32 characters in a title.

New-formats, however, has no reason to continue this restriction. A title of up to 40 characters can fit on the screen (potentially longer by making it multi-line, but let's not go there for now - multi line would require adding code to handle multi-line; but NL already has no problem with >32 chars titles and for the editor it should be as simple as changing a single max-length field), and the file format has no limitation at all. Thus, the editor should either allow up to 40 characters (or arguably, 39, to leave a little bit of space on the sides) based on the player; or no limit at all based on the file format.

On a side note, this appears to only affect attempts by the user to enter a new title / modify an existing one. The editor will not truncate a title that's already >32 chars when loading/saving a level, so modifying the level files by hand is a feasible workaround.

DOS Lemmings (possibly via blank lines in the source text rather than any position adjustment) and NeoLemmix pre-new-formats would vertically center the pre / postview texts if they didn't use up the entire available screen space, by padding it with blank lines before and after the actual text.

This appears to be broken in new-formats releases, including the current one. I have a feeling I mentioned this before, but only in passing rather than a dedicated bug report topic.

Looking at the source code, TGameTextScreen.GetScreenText (in GameTextScreen.pas) still adds the correct padding lines. Not sure if my repo is 100% up to date, but it's newer than the latest stable release. Either something is stripping them out later, or this function is no longer used at all; I have not looked into it any deeper than that. Did consider the possibility that code elsewhere is no longer recognizing #13 as linebreak (and instead wanting #10 only), but I notice that non-padding lines - even blank ones - are also terminated with #13 only and they linebreak fine.

Source code repo for the NL player contains, in a subfolder of "data", a copy of the NeoLemmix Introduction Pack.

Except that this copy is pretty corrupt. I suspect it was converted at an early point in new-formats development, in particular, a point at which there were attempts to trim empty space from terrain pieces, as well as merge duplicates that are just rotated / flipped / etc versions of each other. Because the eventual new-formats releases used untrimmed pieces (this idea was ditched because it was too buggy and, quite honestly, I was just too lazy to fix it), this version of NLI doesn't work on it.

Should either be removed, or replaced with a non-corrupt copy. I have absolutely no preference either way as to which approach is taken.