(CP Mode = Clear Physics Mode)

Clear physics mode defaults to a black background. However, the objects and lemmings in the Silhouette style are pure black, meaning they become invisible (aside from trigger areas / positioning dots, where applicable) in clear physics mode. Terrain is fine, because it changes to the checkerboard grey.

Lemmings could perhaps be fixed by always using the default sprites in clear physics mode. Though this would require a bit of revision of the code to always keep the default sprites in memory in addition to any custom ones, and switch between them when using clear physics mode.

Objects could perhaps have a flag added to their metainfo, that if active, inverts the object's colors in clear physics mode. This would resolve the issue, but would rely on honesty (and more significantly, awareness) by any style designers.

An alternative option could be to, similar to what's done with terrain and trigger areas, ignore the normal colors and draw objects / lemmings in a single fixed color when in clear physics mode. This way they could even combine colors with other important details.

I don't think "rely on people not to do this" is a valid approach here, because the Silhouette style was - as far as I know - not created with the intention of making clear physics mode difficult to use, but simply with the intention of producing a neat artistic effect (which it does very well IMO). Furthermore, an approach like the ones above both prevent intentional abuse and deal with any cases where this happens as an unintended side effect, as well as perhaps helping with a few less-clear cases even in "normal" styles.

I noticed a recent discussion, and a few other historical cases, where creators have carelessly released impossible levels. On the flipside, there have been cases where levels have been suspected of being impossible, but the creator insists they're not - and they in fact are possible.

I'm thinking - could we implement a way to verify the solvability of a pack, without requiring an end-user to run a replay manually (which may spoil the solution, and even if done via the mass-replay checker can interfere with the completion ticks; not to mention a creator may want to be able to prove their levels are solvable without actually releasing replays)?

My thoughts here is to have some kind of formula that creates a level hash from the details that are relevant to solving it - the physics map, skillset, save requirement, etc. This hash would be accessible at any time. Then, some kind of other value derived from this hash, via a formula that's nontrivial to follow by hand, is provided only upon solving the level. The website would in turn have a calculator that someone can enter the hash and derived value into, and the site will confirm "yes, the hash is valid, someone has managed to solve this level". Maybe rather than doing this on a per-level basis, just do it on the scale of the entire pack.

Of course, this wouldn't be foolproof - someone who really wanted to create impossible levels just to troll could simply compile the code or figure out how to calculate the derived value themself - but it might serve as a line of defence against people who don't do proper testing, as well as a reassurance if someone suspects an impossible level - they can use this calculator to confirm the levels are indeed solvable.

Perhaps the site doesn't need to be involved at all - the derived value could be inserted into the pack's info.nxmi or levels.nxmi file and NeoLemmix itself confirms "yes, this pack has been proven solvable". If the pack is modified in a way that affects solvability - ie: not just a change in titles or ordering etc, or even adding decorative items that don't affect the physics in any way - the code would no longer be valid, so it would also catch cases where an initially-possible level was rendered impossible via an untested backroute fix.

Maybe some detail should also be included in these values of which NeoLemmix version was used. Ideally, versions that have identical physics (and simply differ in UI / etc) would pass each other's tests.

Maybe this is unneccessary, and simply reminding people "always test your packs" is the better solution here. This is just an idea I got and figured it wouldn't hurt to write down.

Just a default NeoLemmix installation contains something like 150 music files in the base "music" folder. The only default packs (and as far as I'm aware, the only packs full stop) that make use of the subfolders feature are the Lemmings Plus packs.

NeoLemmix player has supported the use of subfolders for music since new-formats came out. The editor didn't play nicely with it at first, but as of the latest version it works. I'm not sure if it displays them in the list yet (or if this feature is planned), but you can type it in and it works fine. For example: "Lemmings_Plus_V\abstract1". (It doesn't matter which way around the slash is, either will work.)

Packs and styles get sorted properly because NeoLemmix enforces it. I don't think it's practical to enforce this in the same way for music, given that some tracks are very much not pack-specific (like those from the official games, which are used across many fanmade packs), but it's still something content creators should take into account and make use of IMO - it keeps the music folder tidier, and also reduces the risk of ending up in a situation where two different packs conflict because they used the same filename for a music track.

(Side question: Does the same apply to sound effects? I don't know if NeoLemmix handles this correctly or not. Even if it does, perhaps there's less of an argument for sound effects - there's going to be far less custom sounds than custom music, and a much higher likelihood of reuse of a custom sound in another user's content.)

The screen start rectangle currently covers a 320x160 region, but that's not particularly accurate for most setups using a modern screen.

We'll assume a default of that most levels are still 160px tall - I believe this is still by far the most common height. (EDIT: Actually, this doesn't matter IIRC. As long as they're not tall, narrow levels, the same result would still hold.) Under such circumstances, and default NeoLemmix settings, the initial viewable area will be, on various common screen resolutions:

1366x768: 455x216
1600x900: 400x185
1920x1080: 384x176
2560x1440: 365x165
3840x2160: 384x176

EDIT: These figures might not be accurate, as I got different results when I calculated similar stuff for another topic (which I paid closer attention while doing). I'll re-calculate at some point.

X x Y, assuming X is a fair bit larger than Y, and a fairly normal level size:
let Z = floor(Y / 200)
startWidth = screenWidth / Z
startHeight = (screenHeight - (Z * 40)) / Z

From this, 384 x 176 seems like the most obvious option, due to it being used on two of the common screen sizes. 455x216 seems like the most obvious alternative, since I believe 1366x768 is still the most common of these options (especially for laptops). (EDIT: Or maybe not. A Steam survey on display resolutions suggests 1920x1080 is the most common, and while 1366x768 is second, there's a huge gap. While the nature of Steam would likely mean a bias towards higher resolutions, given how big the gap is I'd suspect 1920x1080 is still the most common ultimately.)

Or, if we want to keep one dimension as-is, then at least the other should be changed to reflect that 16:9, not 4:3, is the standard screen resolution these days. In such a case, either 355x160 or 320x140 should be used. (These are not 16:9 ratios themself; because the 16:9 area of the actual screen includes the skill panel, whereas the initial viewable area region does not.)

In old-formats there was a "sketches" style containing objects which do not show up during gameplay, but can be used to measure various things, eg. the length of a bridge, the destruction area of a bomber, etc.

New formats has no equivalent. The images from the sketches style are attached to the third post in this topic, though the blocker one needs fixing.

Note that this bug is for the experimental version with the Shimmier, not the stable version.

In the stable version, when you mouseover a lemming in clear physics mode, a dot indicating the lemming's physics position appears below it. In the Shimmier experimental version, this dot is absent.

Whether using the installer or the styles ZIP, many files from the Lemmings Plus VI styles are missing.

Basement: Folders are present, but are all empty. Theme.nxmi is missing.
Bridge: Folders are present. Objects and backgrounds are empty; most terrain pieces are present but a few are missing. Theme.nxmi is missing.
Garden: At a quick glance, does not appear to have any problems. I did not fully check if every file is present, though.

I've attached a copy of the styles to this post, both to assist with fixing this bug and as a workaround for anyone affected by it (as the styles are no longer included with the LPVI download).