[SUG][PLAYER] Remove support for fully custom lemming sprites, allow recolors.

[namida]

I've implemented support for automatically generating recolored sprites. This can be used out of the box with both the standard and Xmas sprites. It will also be possible to make custom spritesets recolorable as well, with a little bit of extra work.

Existing custom sprites will need a slight change - the "_mask.png" files will need to be replaced with use of the recoloring system. This change will not be required right away - I'll keep some backwards-compatibility code in there for a while, but consider it a deprecated feature and do not use it for any new content created after V12.7.0's release (continue to use it as need be during V12.6.X's life). It will be very easy to change over. Except for this, custom sprites will continue to work exactly as they do now.

I have already made modifications in the NL repository to use recoloring instead of custom spritesheets for both of Arty's styles and the three L2 styles that have custom sprites. Does anyone have screenshots of the other tribes' lemmings handy (all except Highland, Beach, Shadow and Classic)? I may as well set up their recoloring data as well.

[Crane]

Personally I think it's a bit of a shame to fully remove custom sprites.  I remember I once tried to have Lemmings wear space suits for Cheapo Copycat (using things like a jetpack to replace the Floater and bringing their arm up to activate a Predator-style self-destruct system for the Bomber), and as mentioned before, some of the Lemmings 2 styles have custom exit animations.

I suppose if anything I would say that if a particular custom animation doesn't exist, then to use the default one.  If anything, the sudden switch to a default style of Lemming should be jarring enough that the creator should consider filling in the blanks.

There is also the Christmas-style lemmings that are, in effect, custom sprites due to their bobble hat and most of their green hair being hidden by it.

P.S. I don't have a screenshot of it, but the Space lemmings of Lemmings 2 had a custom exit animation where they tumble head over heels and disappear into the background... you know, the classic display of weightlessness.

[ccexplore]

Each tribe (and therefore each style) has unique exit animations from each other, although the Classic Tribe exit animation is pretty much the same as the one in L1.

Aren't they also all different in length (ie. how long it takes before lemming finishes animating and actually gets counted as exited)?  Does NeoLemmix support customizing that as well?  This could actually have game physics implications.

[ccexplore]

Does anyone have screenshots of the other tribes' lemmings handy (all except Highland, Beach, Shadow and Classic)?

Well, the trusty old Lemmings Encyclopedia is still around after all this years:  https://tle.vaarties.nl/lemmings2/solutions/

(Look on the left to select the tribe to view screenshots for.)

[ccexplore]

I suppose if anything I would say that if a particular custom animation doesn't exist, then to use the default one.  If anything, the sudden switch to a default style of Lemming should be jarring enough that the creator should consider filling in the blanks.

We talked about the various options at length in the earlier posts.  Due to code complexity it would only be an "all or nothing" kind of fallback, it would be too complex to, say, use the sprites for the skills that has them and then use the default sprites for other skills that don't.

Currently, it will automatically fall back to all default sprites, which admittedly is the best option for the player (there's no risk of seeing anything strange).  Namida did bring up an alternate idea which I expanded upon (though doesn't sound like people are leaning towards this), that instead of falling back to all default sprites, the game could just still use the custom sprites but use a blank/placeholder (that is visually obviously wrong) whenever it needs to use one that is missing.  This would allow custom sprites to remain fully usable on the levels that won't do anything resulting in having to use missing sprites, particularly any existing old levels that were created using the custom sprites (older than whatever new skill or feature started introducing new sprites, that now automatically become "missing" for existing styles).  Depending on the kind of mix-and-match allowed, new levels that needs the missing sprites would either be created to only use the style for its terrain/object graphics and use default sprites for the lemmings, or the style would not be usable if such a setup is not possible in NeoLemmix (unless they are okay with players seeing the "missing sprite" placeholders during play).

[namida]

Personally I think it's a bit of a shame to fully remove custom sprites.  I remember I once tried to have Lemmings wear space suits for Cheapo Copycat (using things like a jetpack to replace the Floater and bringing their arm up to activate a Predator-style self-destruct system for the Bomber), and as mentioned before, some of the Lemmings 2 styles have custom exit animations.

I suppose if anything I would say that if a particular custom animation doesn't exist, then to use the default one.  If anything, the sudden switch to a default style of Lemming should be jarring enough that the creator should consider filling in the blanks.

There is also the Christmas-style lemmings that are, in effect, custom sprites due to their bobble hat and most of their green hair being hidden by it.

P.S. I don't have a screenshot of it, but the Space lemmings of Lemmings 2 had a custom exit animation where they tumble head over heels and disappear into the background... you know, the classic display of weightlessness.

It's already been decided that NeoLemmix will keep support for custom sprites, but also implement the recoloring so it can be used where a simple palette swap type effect is sufficient - which is the majority of cases.

Each tribe (and therefore each style) has unique exit animations from each other, although the Classic Tribe exit animation is pretty much the same as the one in L1.

Aren't they also all different in length (ie. how long it takes before lemming finishes animating and actually gets counted as exited)?  Does NeoLemmix support customizing that as well?  This could actually have game physics implications.

NeoLemmix definitely supports arbitrary frame counts for lemming animations that don't have any effect on physics, but I'm not 100% sure off-hand if that extends to those that do affect physics as well. I definitely remember that I intended to modify NL so that such animations can have different lengths (without any change to physics), but I'm not sure if that ever happened.

[namida]

Does anyone have screenshots of the other tribes' lemmings handy (all except Highland, Beach, Shadow and Classic)?

Well, the trusty old Lemmings Encyclopedia is still around after all this years:  https://tle.vaarties.nl/lemmings2/solutions/

(Look on the left to select the tribe to view screenshots for.)

That's useful! Implemented nearly* correct coloring for all L2 styles.

* I made a deliberate decision to deviate slightly for the athlete colors in the Shadow tribe, as the usual athlete coloring is not easily distinguished from non-athlete colors.)

I suppose if anything I would say that if a particular custom animation doesn't exist, then to use the default one.  If anything, the sudden switch to a default style of Lemming should be jarring enough that the creator should consider filling in the blanks.

We talked about the various options at length in the earlier posts.  Due to code complexity it would only be an "all or nothing" kind of fallback, it would be too complex to, say, use the sprites for the skills that has them and then use the default sprites for other skills that don't.

Currently, it will automatically fall back to all default sprites, which admittedly is the best option for the player (there's no risk of seeing anything strange).  Namida did bring up an alternate idea which I expanded upon (though doesn't sound like people are leaning towards this), that instead of falling back to all default sprites, the game could just still use the custom sprites but use a blank/placeholder (that is visually obviously wrong) whenever it needs to use one that is missing.  This would allow custom sprites to remain fully usable on the levels that won't do anything resulting in having to use missing sprites, particularly any existing old levels that were created using the custom sprites (older than whatever new skill or feature started introducing new sprites, that now automatically become "missing" for existing styles).  Depending on the kind of mix-and-match allowed, new levels that needs the missing sprites would either be created to only use the style for its terrain/object graphics and use default sprites for the lemmings, or the style would not be usable if such a setup is not possible in NeoLemmix (unless they are okay with players seeing the "missing sprite" placeholders during play).

Basically - one style is selected as the "theme" for a level. This determines lemming colors, as well as a few other visual aspects, like builder brick colors. Which set of lemming sprites to use is also determined by the theme - it could point to the same style, to "default", or to a third style. (As of the next update, and if the lemming sprites it points to support it, it can then also specify recoloring info for the lemming sprites. I've added this support for "default" and "xmas"; it will be up to custom sprite creators to add it, if they wish, to their custom sets.)

The theme has no bearing on which terrains or objects may or may not be used. Conventionally, you would primarily (or even solely) use terrain / objects from the style selected as the level's theme, but this is not required, and in some cases cannot be done - for example, the Xmas style has no terrain pieces, only a theme, lemming sprites and objects; you'd have to use terrain from another style (generally, the Snow style would be used here). For a long time now it has been possible to mix terrain pieces / objects from different styles in a single level; this could be done even before new-formats.

[Strato Incendus]

My custom Egyptian lemmings are also just recolours - a screenshot can be found in the custom sprites thread .

The question is how to handle these if all L2 styles have their original sprites now. Should I simply turn this sprite type into strato_egyptian, in analogy to nessy_machine? Meaning a style that only contains sprites and nothing else?

[namida]

The question is how to handle these if all L2 styles have their original sprites now. Should I simply turn this sprite type into strato_egyptian, in analogy to nessy_machine? Meaning a style that only contains sprites and nothing else?

If it's just a recolor, why does it need to exist as a separate style at all?

If you're meaning what to do until a version with this feature is released; just leave things as-is for now.

[Strato Incendus]

Ah, I thought we're supposed to put the recolouring scheme file for each style into the matching style folder? Because if every L2 style has its own recoloured sprites, I figured that was how it was going to work.

[namida]

Maybe we're thinking along different lines here. Let me explain in full how the new system works, then if your question isn't answered by this, please try rewording it as I'm not sure what else you might be asking?

Firstly - as mentioned above, if you have existing custom sprites, they will continue to work almost as-is. The only thing that you will need to change - and this will not need to be changed right away, I will leave backwards compatibility code in place for a few versions - is that if you make use of the "xxxxxx_mask.png" files (often used for destruction particles in particular), you'll need to replace this with acheiving the same effect via the recoloring feature. Likewise, new ones can be created in the same way, minus the change to how masking is done.

Lemming sprites can have (and in the case of "default" and "xmas", do have; for custom spritesets, it's up to creators if they want to add support) extra metadata in the scheme.nxmi file that allows them to be recolored. This data specifies a list of source colors, and their associated names. For example, a lemming's hair in the default sprites, without any recoloring, is (RGB hex) 00B000. So there'd be a line in styles/default/lemmings/scheme.nxmi: LEMMING_HAIR x00B000. (Note that the name "LEMMING_HAIR" is arbitrary here, I could have just as easily written "FLAPPY_BIRD x00B000" and it would work, as long as theme files trying to recolor it used the same name; but of course, meaningful and relevant names are a good idea.) These lines go inside a "$COLOR_SWAPS" section. (The name "$RECOLORING" was already in use for the conditional recolors, eg. athlete, zombie, etc colors.)

Entire $COLOR_SWAPS section of default style's scheme.nxmi (click to show/hide)

$COLOR_SWAPS
  LEMMING_HAIR x00B000
  LEMMING_CLOTHES x4040E0
  LEMMING_SKIN xF0D0D0
  LEMMING_BUILDER_SACK xF02020
  LEMMING_UMBRELLA xB0B000
  LEMMING_ZOMBIE_SKIN x808080
  LEMMING_ATHLETE_HAIR x4040DF
  LEMMING_ATHLETE_CLOTHES x00AF00
  LEMMING_SELECTED_CLOTHES xEF2020
$END

Note: This has been combined with actually changing the athlete / etc colors to the above. The difference is not visually noticable from the former setting, but it allows the athlete (/etc) and regular colors to be picked individually.

If a style's theme.nxtm points to "default" for lemming sprites, and doesn't specify any recoloring animation, it will still get the default sprites, as-is. But, style creators will likely already be familiar with specifying a few other colors in the "theme.nxtm" file, such as MASK, MINIMAP, etc. You simply specify lemming recoloring colors in exactly the same way.

For example - whereas currently l2_highland points to its own custom lemming sprites, in the next update it can have the following theme.nxmi file, which points to "default" for the actual sprites, but contains recoloring information:

L2_Highland's theme.nxmi (click to show/hide)

LEMMINGS default

$COLORS
  MASK xD08020
  MINIMAP xD08020
  BACKGROUND x000000
  ONE_WAYS x4040E0
  PICKUP_BORDER x60C0FC
  PICKUP_INSIDE x0080FC
 
  LEMMING_SKIN xFFFFFF
  LEMMING_HAIR xFF6500
  LEMMING_CLOTHES x0000CE
  LEMMING_BUILDER_SACK x732000
  LEMMING_UMBRELLA xEFAA00
  LEMMING_ATHLETE_HAIR x0000CE
  LEMMING_ATHLETE_CLOTHES xFF6500
$END

Remember, once again - the actual color names are arbitrary. If you're setting up recoloring with custom sprites, you can use any names you want; all that matters is that the same name is used in the source style's "scheme.nxmi" and the target style's "theme.nxtm". I could have instead used the name "BIG_DUCK" instead of "LEMMING_HAIR", and as long as that name was used on both sides (default's scheme.nxmi "$COLOR_SWAPS" section, and l2_highland's theme.nxtm "$COLORS" section), it would work.

In terms of replacing the "xxxxxx_mask.png" files - you'd copy/paste them onto the main graphic, in a unique color (perhaps death magenta, FF00FF). You'd then define a $COLOR_SWAPS entry for this color, using the name "MASK" - yes, you can use "standard" color names as part of this too, although MASK is probably the only one you should do so with (but maybe there's a creative idea I haven't thought of for doing this - at any rate, it would have been extra work to forbid it, so the option's there if anyone finds it to be useful).

So -
If you want a custom set that's just a recolor of default (or xmas) - for example, the L2 sets as they currently are in NL, or Arty's "underwater" or "silhouette" styles - you nuke your "lemmings" folder with the custom sprites, and use the above system instead. You don't need to change anything when a new skill (like the Jumper) gets introduced, because it's just based on recoloring the default ones - and it can easily recolor any new ones that get introduced too.
If you want a custom set that's actually custom - for example, GigaLem's Millas sets - you do things exactly the same way they're done now. The only difference would be that you get rid of the "_mask.png" files, and use recoloring to "MASK" in their place, as described above. Again, support for _mask.png files will be kept (but considered deprecated; so don't use it for any new content after V12.7.0's release) for a few versions to give people time to switch over - it doesn't cause much mess to the code to keep this in place, so it's no problem to do so for a little while.
If you want a base custom set with unique shapes, that's then recolored for several of your styles - my suggestion here would be to create a base style that just has lemming sprites, for example (if we were creating sprites that replaced the lemmings with ducks) you might call this "author_ducks_sprites". This would likely be a style consisting only of lemming sprites; it might not even have a theme file. You'd set up the $COLOR_SWAPS section as above for this style's sprites. Then in your other sets - "author_shadowducks", "author_egyptducks", etc, you'd point to "author_ducks_sprites" for lemming sprites, and specify recoloring in pretty much the same way you would when recoloring from default.

[Strato Incendus]

Thanks a lot for the detailed explanation, namida! My question was simply about where to put that file - in this case, the L2_Highland.nxmi. That would still go into the l2_highland styles folder, wouldn't it?

Meaning l2_egyptian would contain an nxmi file for the official recolouring of the default sprites for Egyptian - meaning slightly darker green hair and slightly more teal clothes. So the special issue here is that my custom Egyptian sprites were introduced as an alternative to an official style that apparently is using slightly custom colours already.

I could of course replace that l2_egyptian.nxmi with my recolouring scheme, but what if I want to have both available for quick selection? Then I'd need to create a separate style folder containing just, for example, a strato_egyptian.nxmi file, so that it can be selected in the editor without replacing the l2_egyptian.nxmi entirely.

[namida]

My question was simply about where to put that file - in this case, the L2_Highland.nxmi. That would still go into the l2_highland styles folder, wouldn't it?

Are you talking about the source colors, ie: the ones that identify "these are the colors to change from"? That goes in the scheme.nxmi file of the lemming sprites that are being recolored, in a new $COLOR_SWAPS section.

Are you talking about the target colors, ie: the ones that are changed to? That goes in the theme.nxtm file of the respective style, in the existing $COLORS section (just with new color names).

So, using the Highland example:

styles/default/lemmings/scheme.nxmi contains the $COLOR_SWAPS section from the above post
styles/l2_highland/theme.nxtm contains the $COLORS section from the above post - it already contains a $COLORS section in current versions (for eg. minimap, background, etc colors), but the new one has even more colors listed in it

[namida]

I'd also like to clarify, because it seems there's still some doubt around it:

1. The only differences in custom lemming sprites in V12.6.X, compared to V12.4.X, is:
- "Jumper" (the state when a walker steps up 3 to 6 pixels) has been renamed "Ascender"
- There are two new animations, "Reacher" and "Shimmier", both of which are part of the Shimmier skill

2. If your custom sprites work in V12.6.X, they will work, without any changes, in V12.7.X. The recoloring is a new feature - you do not have to use it, and sprites that don't use it will still work as-is.

3. The "xxxx_mask.png" files are being deprecated, not culled, in V12.7.X. This means that, once V12.7.X is released, they should not be used for new content, and the recoloring system should be used instead. It also means that eventually existing custom sprites need to be adjusted, as the feature will eventually be culled - but not until at least a couple of versions later. As in, V12.8.X or V12.9.X or V12.10.X; it won't be culled in eg. V12.7.1 or V12.7.2 etc. But existing spritesets that use them will work, without modification, in V12.7.0. I will create a tutorial explaining exactly what needs to be done to future-proof them, and how to do it, once V12.7.X is in the release candidate phase. There's no point in me explaining this any sooner, because the recoloring system does not exist in V12.6.X.

4. And if it's still not clear from the above - if you're doing an entirely custom spriteset, go ahead and do it exactly as you normally would. If you're doing a spriteset that's just a recolor, it's up to you to decide if you'd rather do it the classic way now and change to using the recoloring system later, or if you'd rather just wait for V12.7.0 and use the recoloring system. But you can do things the current way, it will work in V12.6.X, it will work in V12.7.X.

[Strato Incendus]

@namida: Thanks for the explanation! I guess the rest will be easiest to understand once I see it in action.