Steps to reproduce:
1. Place a pickup skill, entrance or exit
2. Edit the skill count or lemming count by typing in a value (not by using the up/down clickable buttons or arrow keys)
3. Click in the level area such that the pickup skill / entrance / exit is de-selected

The change does not get applied, and an error message pops up.

Workaround: Click somewhere that doesn't deselect the object first. This could be another edit field (like the skill checkboxes), or clicking in the level area somewhere that doesn't deselect the object.

NL 12.6.0 shipped with secondary animations for all objects in the L1 and ONML styles (and my own styles, but that's outside the scope of this topic).

However, there are two matters here:
- Firstly, some of these secondary animations aren't the best.
- And secondly, the L2 and L3 styles still lack secondary animations.

So - this topic is for proposals / discussions around these. If you'd like to submit a candidate for an improved secondary animation, or one for an object that currently lacks secondary animations, post it here. If you've got ideas but aren't quite sure how to make them happen, discuss that here too.

Please note: No one on the NeoLemmix development team is saying "we'll take your ideas and make them happen". We'll give advice / support, and integrate good ones into NeoLemmix, but actual changes will need to be created and submitted by community members.

So, as I promised, I'm going to look into implementing official support for custom pickup skill objects for V12.7.0, in a way that will not require manual updates every time the skill order changes and/or a new skill is added.

Does anyone have input on how these should work? I'm thinking that - the actual graphic would simply present two states. Using the default pickup skill object as an example, the main graphic would have a "picked up" graphic and a "not picked up" graphic - the grey background vs the colored one.

The skill icon would then be added automatically. Similar to how the skill panel graphics are handled, the actual image would simply come from the lemming sprites. To allow for circle shapes, an eraser mask could be provided that would partially erase the skill graphic. Additionally, the NXMO file would be able to define the positioning of the skill graphic, and possibly the Z index of it in relation to secondary animations, so that there can be overlays on it if needed.

To those of you who use custom pickup skill graphics - does this sound acceptable? Is there any effect (outside of "I want the graphics to look completely different from the lemming sprites") that you feel wouldn't be achievable with this?

Please be reminded that in the meantime, no new custom pickup skill objects will be accepted into the NeoLemmix styles download. Existing ones may be updated, and they will need to be to account for the shimmier.

Alright - it's been a long time, but it's finally here - the stable release of V12.6.0, with some exciting new features!

First, let's get the negative stuff out of the way.

Firstly, until further notice (ie: if either Nepster returns, or someone else takes over maintanence of them), the graphic set tool and pack toolkit will no longer be updated. Instead, these files will need to be modified by hand, or where suitable, with older versions of the tools. There are explanations of the file formats - which are quite simple and can be modified with a text editor such as Notepad - over in the NeoLemmix Tutorials boards; these guides have been written to account for V12.6.0 changes.

Secondly, no new custom pickup skill objects will be accepted in custom styles for now. Existing ones may be updated - and they will need to be, to account for the shimmier. Nepster has updated some of these, but not all, and even these will have the shimmier in the wrong position in the order. The reason for this is precisely because of the situation where existing objects lack some skills or have them in the wrong order - in the near future, as in, ideally for V12.7.0, I intend to implement proper, official support, in a way that averts this problem (by automatically adding the skill graphic, instead of relying on a pre-made graphic that includes it), but until that happens, no new ones will be accepted.



Now, let's get a neutral - but important - change out of the way:

Starting with the V12.6.0 release, sounds are no longer included with the main NeoLemmix download. Instead, sounds will be provided in the styles download. This is because sounds are closely tied to styles; and it doesn't make sense to ship new sounds only when there's an NL update, and leave new styles waiting for them. For the same reason, if you're submitting custom styles that use custom sound effects, please include those with your submission. WAV is preferred if it doesn't give a file that's too big; otherwise OGG is the preferred format.



And with that out of the way, let's talk about the new features!

We've got a new skill, the "Shimmier". Those of you who are familiar with L2 will already have a fair idea of what this skill does.
Entrances and exits can now have a limited number of lemmings that are able to use them.
Objects can have multiple animations - no longer do you need two separate objects to make a locked exit that also has animating flames.
Object graphics can also be nine-sliced, giving them nice borders. You no longer need to have separate edge pieces for resizable objects.
Alpha blending is now officially supported for terrain.
And, a single level can now use up to 10 different skills, instead of only 8!

Also, terrain grouping, similar to Lix. However, we don't have editor support for this yet - but when a future editor update adds it, V12.6.0 is ready to handle it!



I'm not sure exactly what Git commit corresponds to the last release of the editor, so I can't provide an accurate changelog for V1.11 -> V1.12. However - most new V12.6.0 features are supported, moving background properties are now preserved (but not editable) if I remember correctly, and the bug where you wouldn't get the "Do you want to save?" prompt if you haven't already saved the level at least once is fixed.


Download: https://www.neolemmix.com/download.php?id=315 (Permalink to V12.6.2)
Styles / Sounds: https://www.neolemmix.com/download.php?program=52 (Links to latest version; click here for styles as at V12.6.1's release - there is no change for V12.6.2)
Editor: https://www.neolemmix.com/download.php?id=314 (Permalink to V1.13)

The styles download is required in full if updating from V12.4.1 or earlier. If updating from V12.6.0, you only need a small update to styles posted later in this topic. If updating from V12.6.1, the styles are unchanged.

As usual - please report any bugs you find, with the new features or otherwise, in the Bugs & Suggestions board.

(For those of you wondering about neutral lemmings or antisplat pads, V12.7.0 will likely bring those. I can't say when to expect the Jumper at this stage.)

This guide assumes you have read and are familiar with the basics of text-based files in NeoLemmix.

Please note: This guide is written with the upcoming V12.6.0 release in mind. Some parts may not be applicable to V12.4.1 or earlier.

A custom style in NeoLemmix can consist of several components - terrain pieces, interactive objects, backgrounds, custom lemming sprites, and a "theme".

Each style exists inside its own folder in "styles". Please note - it is a VERY strong convention, that you should start your style's names with your own username, eg. "namida_bridge". The only exceptions that exist and have been accepted into the NeoLemmix styles are those from the official games (most of which are instead prefixed with the game they're from), and "default". Within a style's folder, there will usually be a "theme.nxmi" file, and subfolders for each type of content.

All images should be PNG files. No other formats are supported.

---

theme.nxmi

The theme.nxmi file defines a color scheme, as well as which lemming sprites to use, for levels that use this style as their theme. The theme.nxmi file is placed in the base folder of the style.

LEMMINGS - Specifies the style name to use the lemming sprites of. If the style has its own lemming sprites, usually, you'd use this style's name. Eg. LEMMINGS xmas would use the sprites from the "xmas" style.

---

Backgrounds

Backgrounds are very simple - place image files in a "backgrounds" folder, and they're good to go. That's really it.

---

Terrain pieces

Terrain pieces aren't much more complicated - get the images, put them in a "terrain" folder.

However - each terrain piece may (but does not have to) have a corresponding .nxmt file. For example, a terrain piece "steel_01.png" might have a corresponding "steel_01.nxmt" file.

The .nxmt file has only two lines it can contain:

STEEL - No value needed; marks the piece as steel.
DEPRECATED - No value needed; marks the piece as deprecated. This means that, by default, the piece will not be visible in the editor (though there is an option to reveal deprecated pieces); it has no effect in-game.

---

Interactive objects

Objects are a fair bit more complicated than terrains and backgrounds. Objects exist in the "objects" folder.

Each object consists of one or more PNG files, as well as a single NXMO file. Separate PNG files are used for separate animations; for multiple frames in a single animation, these are instead stored as a sprite strip - ie: a horizontal or vertical strip of equal-sized graphics, containing each animation frame.

The base name of the object comes from the NXMO file's name. Animation graphic files are named after this, with the animation name seperated from the piece name by an underscore. For example, a file "trap.nxmo" might have a corresponding animation graphic "trap_constant.png". Animations without a name - this is often the case for the primary animation - will simply match the NXMO's name, so in a file "trap.nxmo", an animation with no name specified would come from "trap.png" (not "trap_.png"!).

For the primary animations, if an object type has a single "idle" frame (for example, a triggered trap), this will be the first frame, with the rest being the animation sequence. If an object type has two idle frames (for example, a locked exit - it has the "closed" idle frame and the "open" idle frame), the one it will generally start as, is the second frame; while the one it will generally remain as once used / activated / etc, is the first frame. In the case of a locked exit for example, the first frame is the exit when open, the second frame is the exit when closed, and the remaining frames are the opening sequence.

In the case of a splitter, the first frame is pointing right, and the second frame is pointing left.

In the case of pickup skills, the first frame is the graphic after the skill has been picked up, and after that, the skills follow the same order they do on the skill panel: Walker, Shimmier, Climber, Swimmer, Floater, Glider, Disarmer, Bomber, Stoner, Blocker, Platformer, Builder, Stacker, Basher, Fencer, Miner, Digger, Cloner.

The NXMO file consists of the following lines:

General properties

TRIGGER_X, TRIGGER_Y - Specifies either the top-left corner of the trigger area (for objects that have an area), or the coordinates of the trigger point (for objects that just have a single point, eg. entrances, receivers).
TRIGGER_WIDTH, TRIGGER_HEIGHT - Specifies the size of the trigger area, for objects that have areas.
SOUND - Specifies the sound file to play when the object is activated.
KEY_FRAME - Specifies the "key frame". Currently, this only does anything for teleporters and receivers - it specifies the frame number at which the corresponding receiver will begin its animation, or at which the lemming will be released, respectively.
RESIZE_HORIZONTAL, RESIZE_VERTICAL, RESIZE_BOTH - No value needed. Specifies the direction(s) in which the object can be resized. It is valid to have both "RESIZE_HORIZONTAL" and "RESIZE_VERTICAL" as separate lines, instead of using "RESIZE_BOTH".
DEPRECATED - No value needed; marks the object as deprecated. This means that, by default, the object will not be visible in the editor (though there is an option to reveal deprecated pieces); it has no effect in-game.

For objects that have digits displayed, such as windows and exits (when the lemming count is limited) or pickup skills, the positioning of the digits can be specified as follows:

DIGIT_X and DIGIT_Y - Specifies the position digits are displayed at. For the Y coordinate, this is the top of the digit graphic always; for the X coordinate, it may be either the left, right or middle depending on alignment.
DIGIT_ALIGN - Specifies whether to align the digits to the left (-1), middle (0) or right (+1).
DIGIT_LENGTH - Specifies the minimum number of digits to be displayed. If this is zero, digits will not be displayed at all if the value is equal to zero. For pickup skills, digits will also not be displayed if the minimum length is zero and the skill count is 1.

You can also define custom digit graphics. This is done by adding a 10-frame secondary animation, that's always hidden, called "DIGITS".

Deprecated general properties

These define certain properties of the primary animation. For new styles, a $PRIMARY_ANIMATION section should be used instead.

FRAMES - Specifies the number of frames in the primary animation.
HORIZONTAL_STRIP - No value needed. Specifies that the primary animation's spritestrip is arranged horizontally. If this is absent, it's assumed to be vertical.
INITIAL_FRAME - Specifies the initially displayed frame of the primary animation. Ignored on objects that have non-constant animation (eg. triggered traps). As well as numeric inputs, "RANDOM" (without quotes) is also a valid value.
NINE_SLICE_XXX - (Where XXX is "TOP", "LEFT", "RIGHT" or "BOTTOM") Sets the nine-slicing margin - basically, a border region that's only drawn at the edges of the object even when resized, instead of being tiled with the rest of the object - on each side of the primary animation. Has no effect if the object is not resizable in the relevant direction.

Animations

An object can have one or more animations, which are semi-independent of each other, and can play, stop, or even disappear based on certain conditions. The primary animation of the object is defined in a $PRIMARY_ANIMATION section, and all others are defined in an $ANIMATION section. These are identical, except for some keys not being useable in the primary animation.

As mentioned above, each animation should be a separate PNG file - although if there are two animations with the same graphic (differing, perhaps, by their position), it is perfectly acceptable to only have one copy, and have multiple animations refer to it (just give them the same NAME value).

FRAMES - Specifies the number of frames in the animation.
NAME - Specifies the name of the animation. See the above explanation about filenames.
COLOR - Specifies the name of a color (from the level's theme) that will be used to recolor the animation. This is not likely to be useful outside of a few objects in the "default" style.
HORIZONTAL_STRIP - Specifies that the animation's frames are arranged horizontally. If this is absent, they're assumed to be vertical.
Z_INDEX - Specifies the front-to-back order of animations. Lower values are drawn first; ties are broken by "primary first, then in-file order after that". The Z index, if not specified, defaults to 1 for the primary animation and 0 for all other animations.
INITIAL_FRAME - Specifies the initial frame of the animation. This has no effect for the primary animation if the object is a triggered object, but it does work for the primary animation on objects that have constant animation (eg. water, fire, etc). As well as numeric inputs, "RANDOM" is a valid value.
OFFSET_X and OFFSET_Y - Specifies the offset from the object's position at which this animation is displayed. Can be used on the primary animation, although it seems a bit silly to do so (but maybe there's a good use case I haven't thought of).
NINE_SLICE_XXX - (Where XXX is "TOP", "LEFT", "RIGHT" or "BOTTOM") Sets the nine-slicing margin - basically, a border region that's only drawn at the edges of the object even when resized, instead of being tiled with the rest of the object - on each side of the animation. Has no effect if the object is not resizable in the relevant direction.

The remainder of this section does not apply to the primary animation, only to secondary animations.

HIDE - No value needed. If present, the animation will initially be marked as "Hidden". Note that this does NOT automatically mean it won't be visible - see note below.
STATE - Specifies the initial state of the animation. Valid options are explained below. If absent, the default is either "PAUSE" (if "HIDE" is present) or "PLAY" (if not).

You can then define conditions under which the animation will change state, by using $TRIGGER sections. When no trigger section's conditions are fulfilled, the animation reverts to its default visibility and state. When multiple sections' conditions are fulfilled, the last one in the file order has priority. The contents of these sections are:

CONDITION - Specifies the condition for the trigger. Explained below.
HIDE - No value needed. If present, the animation will be marked as "Hidden" when the trigger condition is met. Note that this does NOT automatically mean it won't be visible - see note below.
STATE - Specifies the state of the animation when the trigger condition is met. Valid options are explained below. If absent, the default is either "PAUSE" (if "HIDE" is present) or "PLAY" (if not).

---

Custom lemming sprites

Todo

This guide assumes you have read and are familiar with the basics of text-based files in NeoLemmix.

In NeoLemmix, the concept of a "pack" or a "rank" mostly does not exist on a technical level (there are still remnants from when it did). There's just groups of levels, which can themself contain groups of levels (which in turn, can contain more groups). What we think of as a "pack" when playing, is generally a group that itself contains no levels, but contains several groups ("ranks"); these groups contain levels, but don't contain further sub-groups. (Exceptions do exist. For example, many demos of packs have the levels directly in the main group, with no sub-groups. The NeoLemmix test levels go one level deeper with nesting.) The "levels" folder itself is the lowest group. Every folder in it is a sub-group of it - so from NeoLemmix's point of view, each pack you have installed is really just a sub-group of the "levels" folder.

---

In the simplest form, a group's folder will just contain level files and/or subfolders (representing sub-groups). For example, we could have the following structure:

levels
>> BlahLems
>>>> Easy
>>>>> JustDigAgain.nxlv
>>>>> JustDigSomeMore.nxlv
>>>> Medium
>>>>>> DoMoreThanDig.nxlv
...etc

From a technical point of view, we now have a subgroup of levels called "BlahLems". This in turn has subgroups "Easy", "Medium", etc. The group "Easy" contains the levels "Just Dig Again" and "Just Dig Some More", and so on.

Of course - in this case, we don't have a custom logo, nothing exists to tell NeoLemmix what order to put the subgroups / levels into (NeoLemmix's behaviour in this situation is to sort them alphabetically), and so on. We can add extra files to the groups for these things, as well as some other customization options.

---

levels.nxmi

Every group must contain its own "levels.nxmi" file; if there isn't one, the subgroups / levels simply get sorted into alphabetical order. So - in the main folder (the one for your "pack"), you'd have one that lists the order of the ranks. In each sub-group's folder (the folders for each "rank"), you'd have one that lists the order of levels. In a situation where a group contains both levels and sub-groups (this is perfectly valid!), the levels.nxmi file in that group would have listings for both ranks and levels.

Important: Once a group has a "levels.nxmi" file, all sub-groups or levels in that group will only show up in NeoLemmix if they're listed in the levels.nxmi file - others will be hidden.

Specifying an order for levels is simple. For each level, add a line with the "LEVEL" keyword, with the value being the level's filename. For example:

LEVEL Just_Dig.nxlv
LEVEL Only_Floaters_Can_Survive_This.nxlv
LEVEL Tailor_Made_For_Blockers.nxlv
...

Specifying an order for sub-groups is a bit trickier, this is because you specify both a name and a folder for them. As such, they need to be in a group rather than single lines:

$RANK
  NAME Fun
  FOLDER 01 Fun
$END

This would specify a rank that's in the folder "01 Fun", and named "Fun".

(I know - "$RANK" is a horrible choice of keyword given the flexible nesting system. It was chosen before the system was properly finalized, and I'm probably going to deprecate it in favor of "$SUBGROUP" in the future.)

One last thing - one of the few ways that NeoLemmix DOES recognize packs, is that a "levels.nxmi" file may also contain a line with the keyword "BASE" (no value). This will cause NeoLemmix to simulate treating that group as a standalone pack - for example, upon completing the last level of it, you'll wrap around to the first level, instead of going on to a different pack. It will also prevent anything that uses the rule of "copy what the parent group does" from going any higher than this group. As a general rule, include the keyword "BASE" in any levels.nxmi file that corresponds to what you'd consider a "pack" (rather than a "rank").

info.nxmi

The info.nxmi contains general properties of the group. Generally, only the group representing a "pack" will have an info.nxmi file, while "ranks" will not.

info.nxmi contains the following lines and segments:

TITLE - Specifies the title of the group. Eg: TITLE Oh No! More Lemmings!
AUTHOR - Specifies the author of the group. Eg: AUTHOR DMA Design
PANEL - If this line is present, it indicates that the group contains custom skill panel graphics. (Todo: Check why this even exists? Seems easy enough to autodetect.)


music.nxmi

This file specifies the music rotation that's used for any level that doesn't specify a music file. This is a simple format - each line contains the keyword "TRACK" and a music file name. Just like when specifying music files inside a level, you can include folder names, and you should not include an extension. For example:
TRACK orig_03
TRACK orig_04
TRACK ohno_01
TRACK Lemmings_Plus_V/abstract1
This would mean levels in the group - assuming they don't specify a music file - will follow the rotation orig_03, orig_04, ohno_01, Lemmings_Plus_V/abstract1, repeat. The last one refers to a track called "abstract1", inside a "Lemmings_Plus_V" subfolder of the music folder.

The music rotation, if absent, will be inherited from the parent group.

postview.nxmi

This file customizes the messages that appear on the postview screen.

This file consists of multiple $RESULT sections, each of which contains:
CONDITION - This specifies the condition to trigger the message.
LINE - This specifies the actual line of text. There can be up to two lines per result.

The condition can either be:
- An absolute number of lemmings. To specify this, CONDITION's value should be the number. Eg. CONDITION 40 would trigger if the player saves at least 40 lemmings.
- A number of lemmings relative to the save requirement. To specify this, CONDITION's value should be the number prefixed with + or -. Eg. CONDITION -5 would trigger if the player saves at least <save requirement, minus 5> lemmings.
- An absolute percentage. To specify this, CONDITION's value should be the percentage, suffixed with a % sign. Eg. CONDITION 50% would trigger if the player saves at least 50% of the lemmings on the level.
- A relative percentage. To specify this, CONDITION's value should be the percentage, prefixed with + or - and suffixed with a % sign. Note that this is treated as a percentage of the save requirement. Eg. CONDITION -30% would trigger if the player saves at least <save requirement, minus 30% of the save requirement>.

The postview texts, if absent, will be inherited from the parent group.

---

Groups can also contain graphic files. Note that most graphic files relating to the main menu will not change when switching up and down between ranks using the Up / Down arrows; they will only change when switching between groups via the level select menu, or when leaving and re-entering the title screen (the obvious exception is rank_graphic.png). To see how these graphic files should look, find the corresponding default ones, and work from there:

logo.png
sign_play.png
sign_code.png (outdated name - it's for the Level Select panel on the main menu screen)
sign_config.png
sign_rank.png
sign_quit.png
sign_talisman.png
scroller_segment.png
scroller_lemmings.png
rank_graphic.png

In addition to the above, if the "PANEL" keyword is present in info.nxmi, custom graphics for the skill panel may be present. These use the same filenames as they do in the standard skill panel graphics.

Generally speaking, every group will have a "rank_graphic.png" except the base "pack" group; while only the base pack group will have the others.

Custom graphics will be inherited from the parent pack where applicable.

---

I hope this has been useful! Feel free to reply if you have any questions, and I hope this helps you with putting together your packs - no toolkit needed!

Alright, here's the first experimental build for the update. It was proposed to name this "V13.0.0" since it introduces a lot of new features, but I decided against this, as usually, a change to the first number has been used to indicate a significant overhaul of file formats - since adopting the current version numbering, it's only been changed twice, and V11.xx.xx was never released outside of a few experimental builds, so keeping in line with that suggests this should be a new V12.X.X. At the same time, I feel the changes are significant enough that we should at least skip a number - so, V12.6.0 it is.



The editor support is a bit less; there's no editor support for piece grouping in particular. At this stage, please only report editor bugs if they either result in (a) crashes, (b) significant difficulty with using the editor, or (c) data loss. If it's just "something isn't supported", that is a low priority at the moment.

I've tested this a fair bit, but there's still plenty of room for more testing.

Download, including an experimental editor: (Removed, as we now have a V12.6.0 stable release)
This download includes styles that have had modifications for the new version, but not styles that haven't had adjustments yet. (Or in simpler terms - it has the official styles and my styles.) You'll need to get the rest from the usual download or from an existing copy of V12.4.X.

For the avoidance of doubt, I will not be making updates to the graphic set tool or the pack toolkit. I recommend learning how to modify these files by hand with a text editor; this is not particularly difficult to do, and you are welcome to ask for help on the forums. With this being said - if anyone else is willing to take over these projects, they are welcome to do so.

If you need help on managing your styles / packs manually, please see these topics:
Guide to styles formats (Includes explanations on using secondary animations!)
Guide to pack / rank structure

---

Regarding further improvements: As far as the engine goes; major features that are in there now, is what will be in the final release. Further improvements before release will be minor features or bugfixes only. In particular, this means we will not be getting neutral lemmings in V12.6.0 - but the feature has been implemented so it's coming eventually, it's more just not wanting to put out too many things all at once.

---

You can use the attached tool to quickly add your username to a lot of replays. To use it, put it in your NeoLemmix V12.6.0 (or any future release after this) folder, put the replays you want to fix into a folder called "ReplayFix" (you can have subfolders inside ReplayFix, they don't all have to be directly in the base ReplayFix folder), then run the EXE. Source code is also included in the ZIP, use Lazarus to compile, it'll probably compile in Delphi too if you copy/paste the code into a blank command-line project as (as far as I'm aware) it doesn't use any language or library features that differ between the two.