The custom lemmings for those styles are not included in the NL download.

Are they actual sprites from L2 (with additions for the NL-specific skills, of course) - or at least close to their color scheme - or are they just "here's some lemming sprites that work well with that style"? If it's the former, I suggest we look at integrating them into the NL download. Otherwise, they should be made part of a custom style (at which point they could, in that form, be added to the download). I can say now that I do not want custom lemming sprites for my styles, so the Machine ones would need to be added to a custom style if they're to make it in.

We have six sets of lemmings sprites in the default styles download:
- default
- xmas
- plom_halayangube
- plom_festiveshangtu
- arty_underwater
- arty_silhouette

Of these, "default" and "xmas" have Shimmier sprites (I've just done the latter), the other four do not. Arty's styles' sprites appear to just be recolors of the default sprites, but plom's look like they'll need a bit more work.

Email issue should be fixed now. The git repo had my old personal email address configured as the FROM for emails; I updated it to my up-to-date one. However - it should actually be coming from some kind of noreply@lemmingsforums.net (the domain being the critical part) email address, to work with the SMTP provider we're using (SparkPost).

I've fixed this now.

In regards to logging in issues, I haven't had any issues with that (unless he means that he needed to activate his account or reset his password, and wasn't receiving the email, therefore couldn't log in). I quickly popped onto IRC, but it seems he isn't online now.

Again I point out that many games nowadays features so-called hotkeys and no buttons. Pressing keys without any kind of visual button the screen is very common.

Most games nowdays also have gameplay not even remotely comparable to Lemmings. Probably the closest would be RTS games; I'm not familiar with the super-modern ones, but I recall every game in the Age of Empires series would have on-screen buttons for everything - albeit with some of the more advanced features hidden if you don't enable an "advanced mode".

another idea on 'removing' a button is to place the release rate change function up to overtop of entrances (this is how Revolution worked--you left or right clicked the entrances and the number appeared temporarily above it). That would free up one more space.

This might give the impression that each entrance's release rate can be adjusted independently.

---

I just took a look at what the compact panel looks like - I haven't used it in so long, that I didn't remember off-hand. I know the DOS L1 skill panel (which is also 320px wide) would have room for two more skills, by removing some of the filler between the panels and the minimap / to the right of the minimap - but NL's compact panel has made use of this space for a fast forward button and an increase to the minimap width.

Perhaps this can be reversed - shrink the minimap a tiny bit and remove the fast-forward button. This makes room for two more skills on the compact panel. On the full-size panel, we've got 8 utility buttons that aren't stacked - Pause, Nuke, Fast Forward, Restart, Framestep Back, Framestep Forward, Clear Physics, and Load Replay. (We also have two buttons for directional select, but these are stacked.) Maybe we can stack some of these - I would definitely be okay with stacking the framestep ones in the same way as the directional select. Maybe Fast Forward and Restart can also be stacked - and then, viola, we've got room for two more skills. Perhaps we could stack even more aggressively, to also give a slightly wider minimap - I think this is more beneficial than these buttons being full-height.

It wouldn't be too much extra work to implement a feature that allows shortcuts to a specific pack. On a technical level - the shortcut would just need to include command line arguments something like "-pack [name of pack's folder]". NeoLemmix can probably even be made to generate these shortcuts, perhaps a "Create shortcut to this pack" button in the level select menu that creates such a shortcut in NeoLemmix's folder, and you can then copy / move that shortcut to wherever you like.

In such a case, you wouldn't need to display the scroll buttons unless there's 9 or more skills - indeed, I would say we shouldn't display them unless there's 9 or more; this way more attention is drawn to that there's extra ones to scroll to.

But overall, page-flipping is essentially just a variation of scrolling, which seems very unpopular as an approach to deal with this. If we do increase the limit, it's most likely going to be one of the following ways:
a) Shrink the minimap
b) Increase the total width of the skill panel
c) Remove or shrink some of the existing buttons

There is of course a limit on how many extra skills we can squeeze in with this - 9 total is definitely doable, 10 should be possible, if we want more than that we'd probably have to use a combination of those approaches. But this is okay - the strongest preference seems to be for just a slight increase.

I would definitely say - regardless of decisions (other than a decision of "don't change anything", which seems extremely unlikely), we should approach this in a way that, the behind-the-scenes code can handle unlimited skill types, and only the UI limits things. This way, it'll make things easier if there's ever a decision in the future to accomodate an even higher limit.

Sorry for being obnoxious here, but I still don't understand why we need either a $PRIMARY-ANIMATION or a PRIMARY keyword? What would turn impossible if we just had the usual .png, that we already had in all previous versions, and then only the secondary animations? In other word: What would be impossible to do, if I never used either $PRIMARY-ANIMATION or the PRIMARY keyword?

I'm not quite getting what part of this doesn't make sense, so I'll try to cover everything. Also because this way, I'm thinking through it again myself.

The primary animation, in this system, is equivalent to the only animation under the old system. As such - it is tied to physics. Physics control which frame it's on, and which frame it's on can affect physics.
Could this be changed, so that the primary animation is just like any other? It's not impossible. But let's take for example, a DOM_TRAP. The frame count of the primary animation affects physics - if it has 20 frames, it can't kill another lemming for 20 physics updates. But if it has 10, it can kill another lemming 10 physics updates later. Also, the primary animation remains stopped until the trap is triggered, at which point it animates once. We do have "LOOP_TO_ZERO", but this will do nothing if set while the animation is already on frame zero; its purpose is to allow the animation to complete gracefully (then not repeat), rather than abruptly terminate, when we want the animation to stop. Thus, some kind of "RUN_ONCE" state (which presumably, advances the frame to 1 then changes to LOOP_TO_ZERO) - which would also need extra code to differentiate between eg. "the trap is still triggered" vs "the trap has been triggered again" - would have to be introduced. The object would still need to define how many physics updates the object is triggered for anyway. To me, it sounds like this would just complicate things.

The primary animation can be defined in either a $PRIMARY_ANIMATION segment (or as an alternate proposal: an $ANIMATION segment with a "PRIMARY" keyword), or in the main segment of the NXMO file.
Could this be changed, to only one or the other? Changing it to the sub-segment only would require modifying all existing NXMO files, and break forwards / backwards compatibility completely (by comparison, under the current experimental, new objects using the main segment are backwards compatible physics-wise though might look weird, while old objects are 100% forwards-compatible). On the other hand, changing it to the main segment only - that's feasible, yeah. Maybe that makes more sense than having the A or B options. The downside here is - either loading code needs to be duplicated, or the main segment has to be parsed a second time (as an $ANIMATION segment), or it just ends up getting translated internally to an $ANIMATION segment with special handling (which is pretty much what already happens). Also, I don't really know how I'd feel about having a "NAME" parameter for an animation, in the main segment - though perhaps NAME could just be disallowed altogether for the primary.

Or is it, the primary animation shouldn't need to be explicitly defined?
For this, I'd assume the rule is that either the first or last $ANIMATION, becomes the primary one. If so - this works only if we keep Z_INDEX, otherwise it's not possible to choose whether secondaries are drawn above or below the primary. This is a feasible - if maybe a bit counter-intuitive - approach if Z_INDEX is kept.

I could've sworn I replied to this. Maybe it got lost during the upgrade. Anyway, this should be easy enough to implement and it's a good idea, so I'll look into it next time I'm working on NL code.