Second, as you can see, I'm using several tilesets revolving around the same theme to get as close as possible to the graphic sets used in Lemmings 3D. They don't really seem to have universally agreed-upon names, but I'm going to call them:

1. Army
2. Classic
3. Candy
4. Medieval
5. Circus
6. Outdoor
7. Digital
8. Egyptian
9. Space
10. Sports

There's official names for them that can be easily gotten from L3D's data (just by looking at filenames, nothing super fancy needed). The catch is that some styles have two possible names - three styles have only a single definitive name, three have full vs abbreviated names, and four outright have two potential names.

In the "BMPS" folder, we have BMP files of the pre-level wallpapers. Each one of these has a name for the style. The names from here are "Army", "Castle", "Circus", "Computer", "Egypt", "Golf", "Lemgo", "Maze", "Space", "Sweets". I will note in particular here - I believe "Egypt", not "Egyptian", was intended, as "Egyptian" could still fit in to the DOS character limit.

In the "SOUND" folder, we have a slight different set of names. One consideration here is that these files are limited to 5 letters for the style names, as DOS filenames are limited to 8 characters altogether, and these use a two-letter prefix for the soundcard the files correspond to plus a one-digit suffix to identify the three variations for each style. "Army", "Egypt" and "Golf" are the same. "Circus", "Computer" and "Sweets" are abbreviated as "Circ", "Comp" and "Sweet" respectively. The remaining four, "Castle", "Lemgo", "Maze" and "Space" have completely different names in the sound files - "Medi" (presumably short for "Medieval"), "Lego", "Gard" (presumably, "Garden") and "Alien" respectively.

Which set of names is the "authentic" one? I'd personally believe the ones from "BMPS" for several reasons. Firstly, I believe it's a known fact that "Lego" was the original name for the relevant style but it was changed to "Lemgo" for trademark reasons. The BMPS names use "Lemgo", the SOUND names use "Lego". Secondly, names changing during development in general is very plausible, and the BMPS files have newer modified dates. Finally, the game does not actually use the files in BMPS - they're in a much higher resolution than the game uses, and happen to exactly match common Windows screen resolutions at the time; thus, the logical conclusion is they're intended as desktop wallpapers, and the intent is that the user might see the filenames; thus, I'd believe more care went into using accurate style names here.

But ultimately, there's no official word on which possible official style name is the true official one for any given style.

On a side note, I believe L3DEdit doesn't quite use either official names for a few styles. I'm fairly sure I used "Candy" and "Pyramid" rather than "Sweets" and "Egypt". Those who are bothered by this can simply modify the L3DEditPresets.ini file (after running L3D once).

---

Speaking of L3DEdit, it's quite easy to use it to extract the graphics from L3D. You could even use the actual L3D tilesets, though some work would be needed to convert the raw graphics into something that works well in NL.

And finally, I just want to mention that I'm really excited to hear your renditions of the musics!

---

EDIT: Actually, I noticed another thing:

00. Virgin
01. Sober
02. Drunk
03. Stoned
04. Delirious

I'll just say, anyone who's been both (and is familiar with Lemmings rank naming in general) would very much expect Stoned to be easier than Drunk.

That is 100% possible, if a bit CPU intensive, from a technical point of view. I don't know how well it would work in practice though.

Would a restart be required to toggle between high-res and low-res?

I'm currently thinking that you would not be able to change mid-level, but you could change without restarting NeoLemmix itself. Of course, I can't say for sure until I actually work on implementing it, but I think what I've described here should be acheivable. Changing on-the-fly while in-game probably isn't; the only way I could see that being feasible is if NL always rendered both resolutions and the option simply chose which one to display, which would likely have an extreme performance impact for minimal gain. (EDIT: Alternatively, NL keeps a history of every modification to the visual terrain map, and replays these upon resolution switching. While this wouldn't have the performance hit of the previous suggestion, it would instead be very code-intensive, again just for the gain of "you can switch mid-level" which I don't see as a huge deal.)

And to clarify, the non-1:1 re-imagining would be a separate style, which is why I thought of it as an example of when you might have high-res graphics, but no low-res graphics to accompany them.

Ah, gotcha.

For clarification, is the support beam example the same size as the original object horizontally? If so, I think it's a good solution.

You can literally see how it looks a few posts up. It's two little vertical supports at each end, not a horizontal beam.

- Graphic sets are required to either provide high or low res physics (or both). I think there could be sets that would work best in a higher res.

I'm not sure what you mean by this - "graphic sets must provide at least one resolution", that's pretty much implied; or "we should choose one resolution that all styles are required to have, but the other is optional", if we go this route then of course low-res would be the required one as that's what physics are based on and what all styles already have.

If we don't have upscaling / downscaling and use a "you can provide either resolution", this means low-res-only and high-res-only styles cannot be mixed together. It would also more or less mean that providing a high-res version of any given style is on an all-or-nothing basis.

Most of all - if physics remain low-res-only (and they will be, this is not up for debate), we cannot have high-res-only styles without downscaling. Thus, if we don't have downscaling, all styles are either "low-res only" or "both resolutions".

In regards to whether a zombie was originally neutral or normal, I think the colour is enough of an indicator.  Speaking of colour, is there a consensus on the colour theme that we're going for?  One thing to note is that there's currently no clear distinction between neutrals that have permanent skills and those that don't (my level, "Last Lemming Standing", is a good indicator of this, as it has both zombies and neutrals with a mixture of permanent skills and those without).

Ah, I interpreted your suggestion as "if a neutral gets infected, he's now only a zombie (not also a neutral)", not just "the help text only displays Zombie, not N-Zombie, but he retains neutral appearance features".

There hasn't been any further discussion on appearance since the RC build dropped. If there's another RC update, I should put one of the alternate proposals in it. Or, you can try it yourself by modifying styles/default/lemmings/scheme.nxmi - not the "LEMMING_NEUTRAL_xxxx" lines at the start (those relate to the recoloring for different styles), the $NEUTRAL sections a bit further down, and specifically the "TO" lines in these.

Uploaded V12.7.0-RC3. Changes:
- Main menu actually displays the RC build number now (ie: "RC3", not just "RC").
- A different graphic for orig_fire:firepit and orig_fire:firepit_blue. This is still not considered finalized; this is just a different proposal from the one in previous builds (which is not ruled out either; this is more just a "try a few out" thing).
- When mouse-overing a neutral lemming, the permanent skill icons for it will always be shown, even outside of clear physics mode (this is the same as what already happens with zombies).
- Fixed the bugs relating to the coloring of the alive lemming count.

The update link in the first post can be used to update from either previous V12.7.0-RC build.

Here's a possible animation I came up with. This moves the fire pit up 2 pixels, and puts small support beams under it so existing levels don't have gaps. (Attached image can be dropped in to replace the existing PNG in either stable or V12.7.0-RC NeoLemmix; no NXMO change needed.)

I don't know how I feel about the trigger area re: the top of the object, though... Honestly, personally, I prefer the current (shrunken) one. I feel the sides are less critical; I'm okay with keeping the full width here.


IchoTolot suggested on Discord combining this with Dullstar's glowing frame idea. I like the concept, I'm not sure how well I feel it fits the style (especially in regard to limited colors), but maybe it can be done. I do feel that, unless the object still gets shrunken inwards horizontally, only the bottom part of the frame should be glowing; this would clearly distinguish the deadly bottom from the non-deadly sides.