Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - namida

Pages: [1] 2 3 ... 40
1
Bugs & Suggestions / [BUG][PLAYER] Swimmer-Drowner-Bomber physics bugs.
« on: August 20, 2019, 07:44:04 pm »
The general setup for these cases: Assign a bomber such that (a) the lemming ohno'es, and (b) the lemming falls into water before exploding.

As far as I'm aware, the bomber can be substituted with a stoner. I haven't tested this, but can't think of any reason why it wouldn't work. I have confirmed that the nuke can be used for this, it doesn't need to be an actual bomber skill.

First, see what happens when the above is done with no further steps. The ohno'er becomes a drowner, and drowns.

Now, try assigning a swimmer to the ohno'er before they hit the water (you can't do this during the ohno, it must be done before assigning the bomber). Notice how instead of drowning (since swimmers can't drown), they continue falling to the bottom of the water, exploding when appropriate. This part, IMO, is fine.

The bug - in general (and this part itself isn't a bug), you can assign a swimmer to a mid-drowning lemming to save him. However, you can do this even when the above bomber hits the water. Becuase the lemming was no longer going to explode, you've now got a fully functional lemming again. Given that a non-drowning but has-swimmer ohnoer will not start swimming, and cannot be saved by water, I feel this is a bug.

I'm not entirely sure what the best resolution for it is, though. Possibilities are:
a) Ohnoers always ignore water, instead of just if they're swimmers.
b) Ohnoers always drown, even if they're swimmers.
c) Specifically prevent the above case - either the swimmer can't be assigned to the drowner in this case, or upon making the assignment the lemming immediately explodes.

I think B might be the most logical course of action here. A feels less natural, while C means we're introducing a specific new rule for an edge case instead of slightly tweaking an existing one - in a way that should have very little if any side effects - to cover the edge case better.

Related thing to check: Do ohnoer-disarmers falling onto traps also avoid exploding? I suspect not - my first prediction is that they'll get eaten by the trap; though "they ignore the trap and explode" is also possible. That's a much more obvious case and I think Nepster would have thought of this one - if I didn't think of it myself when initially implementing the disarmer, which itself is fairly likely.

Here's a level and a replay that illustrates this bug (and cannot be solved without it - activated via the nuke, rather than a bomber skill, in this case).

2
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.

3
NeoLemmix Main / Planning a schedule for future releases
« on: August 18, 2019, 10:04:08 pm »
Okay so - I'd like to get into a system of having a more structured release schedule, so content creators can have a better idea of whether it's worth waiting for a certain feature or whether it's better off to just go ahead without it for now, as well as plan for when they might need to make modifications to their content, and so on.

My initial proposal here, is that:
- Minor updates, eg. V12.6.0 to V12.6.1, are made as needed. These will generally only be for bugfixes, or to implement things that were really obvious oversights (such as the shimmier skill shadow).
- Experimentals for specific features are made and released as needed. These should generally be treated as "for testing / debug purposes; physics / etc may change, be very careful about creating content that relies on specific details". They'll also more often than not be closer to the previous stable release than they are to the upcoming new release, except that they include the specific experimental feature.
- Major updates, eg. V12.6.0 to V12.7.0, are made roughly three months apart from each other.
- Release candidates for each major update will be released about a month beforehand. This release candidate can be treated as "almost stable" - basically, no intention exists to make further significant changes, but it still might need more testing and bugfixes. You can use it for preparing your content for the update; just make sure to double-check the content when the stable release arrives. Basically - it's expected and intended, but not guaranteed, that anything that works in the release candidate will also work in the stable release. I will be using the name "release candidate" here to better distinguish it from the typical experimentals (as described above).
- Additionally, the even-numbered updates (V12.8.0, V12.10.0, etc) may only introduce new (or significantly changed) cosmetic or UI features. The same rule will apply to any changes to physics, except where it's fixing bugs or edge cases in recently-introduced physics - these may come in the even-numbered updates (or if they're particularly urgent, even in a minor update). The odd-numbered updates (V12.7.0, V12.9.0, etc) may introduce / significantly change both cosmetic and physics features. (Of course, I'm not going to change things just for the sake of doing so - they "may" have changes, not they "will" have changes.)

This means that cosmetic or UI additions / changes may occur every 3 months, while physics additions / changes will only occur every 6 months. Of course, these will be guidelines - if there's a really good reason to get a major release out more urgently, I'll do so. Or if there isn't enough new stuff to justify one, it might be longer until one occurs.

What do people think about the above ideas? (Maybe 3 months is too frequent...?)

4
NeoLemmix Graphic Sets / Secondary animations for official styles
« on: August 17, 2019, 09:31:32 pm »
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.

5
NeoLemmix Levels / Packs downloadable by NeoLemmix Installer
« on: August 17, 2019, 09:04:40 pm »
So - you probably saw that I made a new NeoLemmix installer lately. Even prior to this, Nepster's one also installed some packs along with NL itself.

Currently, I've chosen the packs based mostly on Nepster's existing list from the old installer, with a few additions that were suggested by other forum members. But going forward - I would like for this to be on an opt-in system. So - if you would like your pack to be listed in the NeoLemmix installer, please request it here.

There are some rules:
1. Your pack must be of decent quality. This doesn't mean every level has to be a Level Of The Year candidate; just that the levels should be amateurish, or troll levels, etc.
2. Your pack must have a reliable download link. Ideally, this will be a link that remains valid when you update the pack, but if not, please make sure to let us know when you've made updates so we can update the download link. Forum attachments can count if you don't expect your pack to still be getting regular updates.
3. Your pack must be available as a ZIP file (not RAR, or 7Zip, or any other archive), or a group of ZIP files. Ideally, these ZIPs should be designed to be extracted to the base NeoLemmix folder (see any downloads of my packs for an example of this), but they can also extract to the "music" folder, the "levels" folder, or a folder named after the pack inside the "levels" folder. Every ZIP file for your pack must be extracted, in full, to one of these four destinations.
4. Your pack must work correctly with, and be solvable in, the latest stable version of NeoLemmix at the time of your submission. Additionally, it must not use any features for which culls are confirmed to be coming, or any features which are not officially supported*.

* An exception to this: Packs that make use of custom pickup skills will be accepted even prior to them getting official support, provided the custom pickup skill object they use is in the NeoLemmix styles download and has been updated to include the Shimmier in the correct position. However, those that rely on a new custom pickup skill object made specifically for the pack, will need to wait until official support for such is implemented.

6
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.

7
EDIT: The decision has been made - custom lemming sprites will continue to be supported, but a recoloring system will also be implemented that can be used where only a recolor is desired. This will mean that sprites that are just recolors need no updates for new features - the same recoloring just gets applied to the new sprites automatically.

The whole debacle with shimmier sprites shows that custom lemming sprites are going to be a problem whenever anything new is introduced. We've had some styles where the shimmier graphic is present but the associated metadata is missing; and custom styles are giving error messages due to lack of shimmier sprites. At least in this latter case, V12.6.0 no longer crashes - it instead shows an error (only once per session, after this it's silent) and falls back to default sprites.

I'm thinking the easiest way to avoid this - remove the support for custom lemming sprites altogether. Instead, allow custom style creators to specify recoloring data only. Almost all existing custom sprites are just recolors of the default ones. The Xmas sprites aren't quite, but they're similar enough that a recolor would achieve the needed effect. Alternatively, the Xmas sprites - as official content rather than custom - could be kept, and styles can select one or the other and recolor from there.

A third option is of course a hybrid approach - leave support for custom sprites in, but also implement the recoloring option. Styles that only need to recolor can then use this (which I believe is all styles aside from Xmas, some of GigaLem's styles, and some of Plom's styles - even Arty's silhouette style could be done with a recolor-only setup), and won't need any further work for future updates; while those who wish to use custom sprites can still do so - at their own responsibility for keeping their sprites updated. With that being said, if we're going to go this route, I would need to see that people actually using this feature are in fact willing to maintain their sprites - so how quickly we get the shimmier graphics for the relevant styles may affect how willing I am to consider this option.

8
NeoLemmix Main / NeoLemmix V12.6.2, Editor 1.13 Release
« on: August 15, 2019, 01:35:52 am »
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!

Full changelog (click to show/hide)

Changelog: V12.6.1 to V12.6.2 (click to show/hide)

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.)

9
Bugs & Suggestions / [SUG][PLAYER] Re-add antisplat pads.
« on: August 12, 2019, 11:34:17 pm »
EDIT: Very clear support for "yes", so this will be happening. The topic will be closed when I've actually done the implementation.

During the changeover to new-formats, antisplat pads were culled along with some other objects. The others made sense - radiation and slowfreeze were annoying and very execution-focused, against NeoLemmix's general philosophy of focusing on the puzzle and minimizing execution difficulty as far as practical.

However, I feel - and I know several other people do too - that the culling of antisplat pads was not justified. The logic behind this was their similarity to updrafts, but I feel they have enough important differences that they should remain as separate objects. They do not create execution difficulty, and they require very little code so they don't have the "code becomes complicated" issue that many culls were justified by.

Therefore - I want to see, does anyone feel they should remain culled? If not, I will re-implement them for V12.7.0 (or maybe even V12.6.0, depending on how quickly a decision is made, but V12.7.0 is more likely).

Just to be clear now - this re-implementing will not be extended to radiation and slowfreeze. Those are not coming back. This one is a special case where I feel the culling was really unjustified so am prepared to revert it. (I'm open to considering the same thing for triggered animations at some point, but let's decide on this one first.)

For those who were not around when antisplat pads existed: They're basically the opposite of splatpads. Whereas a splatpad will mean any lemming landing in the splatpad's trigger area (unless they're floating / gliding) will splat, an antisplat pad means that lemmings landing in the area will not splat no matter what. The differences from updrafts are (a) they don't slow the lemmings' fall, (b) they have no special interaction with gliders, and (c) they have no effect on a lemming that merely falls through them, the lemming must be inside the trigger area when it lands.

10
NeoLemmix Tutorials / NeoLemmix Formats - Styles
« on: August 12, 2019, 09:13:02 am »
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

(A trigger effect) (click to show/hide)
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).

Explanation of animation states (click to show/hide)




Custom lemming sprites

Todo

11
NeoLemmix Tutorials / NeoLemmix Formats - Level file format
« on: August 12, 2019, 01:23:33 am »
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.

General Level Info

The level file usually begins with (although - keep in mind the rule about order-insensitivity, so technically this can come anywhere in the file) the general stats - title, skillset, etc.

TITLE - The level's title. To properly fit on the preview screen, this should be no more than 40 characters in length.
AUTHOR - The level's author. Optional.
THEME - The style from which the level takes its theme. This will usually reflect the style the level is mostly / entirely made using.
MUSIC - Specifies the music used on the level. May contain / as a path delimiter, so you can place music in subfolders of the main "music" folder. If not specified, the corresponding track from the default music rotation will be used.
ID - Specifies the level ID. This is a number in the range of 1 to (2^64)-1, or 0x0000000000000001 to 0xFFFFFFFFFFFFFFFF. This should theoretically be unique for every level, and should in practice be unique for every level in a pack, unless the two levels are literally identical duplicates of each other (not just "similar"!).
LEMMINGS - Specifies the number of lemmings on the level. This can be left out if the level only has preplaced lemmings, or if all windows on the level have specified lemming counts.
REQUIREMENT - Specifies how many lemmings must be saved to pass the level.
TIME_LIMIT - Specifies a time limit for the level, in seconds. The level will have infinite time if no time limit is specified, or this can be explicitly stated by writing TIME_LIMIT INFINITE.
MAX_SPAWN_INTERVAL - Specifies the highest value the spawn interval can be raised to on the level. To convert a release rate to a spawn interval, or vice versa, the formula is (103 - RR).
SPAWN_INTERVAL_LOCKED - No value needed; if this is present, the max spawn interval is instead a fixed spawn interval that cannot be changed.
RELEASE_RATE - DEPRECATED, DO NOT USE! Specifies the initial release rate. Note that this is interpreted as an old-formats style release rate (ie: a value of 1 here, is equivalent to RR 50 under the current system), so use MAX_SPAWN_INTERVAL instead.
RELEASE_RATE_LOCKED - DEPRECATED, DO NOT USE! Identical to SPAWN_INTERVAL_LOCKED.

WIDTH - Specifies the width of the level.
HEIGHT - Specifies the height of the level.
START_X - Specifies the X coordinate for the center of the screen at the start of gameplay.
START_Y - Ditto, for the Y coordinate.

AUTOSTEEL - Specifying AUTOSTEEL SIMPLE will use simple autosteel. Note that simple autosteel is no longer officially supported, so do not use it - it's there on a basis of "it can stay in NL until it stops working due to other changes, then it will be removed".
BACKGROUND - Specifies the background graphic to use for the level. The format is <style>:<file>, so for example, to use the background "colors" from the style "namida_abstract", you'd write BACKGROUND namida_abstract:colors.



Skillset

The skillset is specified inside a $SKILLSET section. Skill names are used as keywords, with the skill counts as values. For example, BUILDER 3 would give the player 3 builders.

You may give infinite uses of a skill by specifying INFINITE as the value.



Talismans

Talismans are defined by adding a $TALISMAN section. You may have multiple talisman sections in a single level - there's no practical limit as to how many you can have.

Each talisman must have a name, an ID number, and a color. These are specified with the following keywords:

TITLE - Specifies the talisman's name.
COLOR - Specifies the talisman's color. Valid values are BRONZE, SILVER or GOLD.
ID - Specifies the talisman's ID number. This must be different for each talisman in the same level, and must be numeric, but beyond this has no rules. I do suggest that, if you remove one talisman from a level then add an entirely new one, don't give the new one the same ID the old one had.

With these alone, though, the talisman will be awarded simply for completing the level, no added requirements. To specify additional requirements, add the following lines:

SAVE - Specifies a save requirement.
TIME_LIMIT - Specifies a time limit. This is measured in frames. 1 second = 17 frames, so for eg. 1 minute (60 seconds, or (60 x 17 =) 1020 frames), you'd write TIME_LIMIT 1020.
SKILL_LIMIT - Specifies a limit on the total number of skills the player may use.
XXXX_LIMIT - Specifies a limit on the number of a specific skill the player may use. Replace XXXX with the skill name. Eg. BUILDER_LIMIT 4 sets a requirement of no more than 4 builders being used.
SKILL_EACH_LIMIT - Specifies a limit on the number of uses of each individual skill a player may use. Eg. SKILL_EACH_LIMIT 3 sets a requirement of no more than 3 of each skill being used. This is just a shorthand for having one XXXX_LIMIT line for each skill.
USE_ONLY_SKILL - Specifies one skill that must be the only one used. Eg. USE_ONLY_SKILL BUILDER results in a talisman that is obtained by solving the level using only builders. This is just a shorthand for having XXXX_LIMIT 0 for every skill except the specified one.



Pre-level and post-level texts

You can specify texts to show before and after the level respectively using $PRETEXT and $POSTTEXT sections.

Either one of these contains lines with the keyword "LINE", with the value being one line of text. If you wish to include a blank line, have a LINE with no value specified. Each line of text can be up to 40 characters long.



Objects

Object instances are specified with an $OBJECT section.

The following keys are common to all types of objects:

COLLECTION - Specifies the style the object is from.
PIECE - Specifies which object to use.
X and Y - Specify the position of the object.
ROTATE / FLIP_HORIZONTAL / FLIP_VERTICAL - No value needed, specifies to apply the corresponding transformation to the object. Remember that files are not order-sensitive; and thus, Rotate is always applied first.

These keys apply to most types of objects, though moving backgrounds and one-way arrows cannot use them:

NO_OVERWRITE - The object will be drawn behind other objects.
ONLY_ON_TERRAIN - The object will only be drawn where it overlaps terrain.

For objects that are resizable:

WIDTH and HEIGHT - Specify the corresponding dimension. If either is absent (or if one is provided for a direction the object cannot be resized in), the size of the actual raw object data is used.

Some types of objects have additional fields specific to those types:

Exits (click to show/hide)
Entrances (click to show/hide)
Teleporters, Receivers (click to show/hide)
Splitters (click to show/hide)
Moving backgrounds (click to show/hide)
Pickup skills (click to show/hide)



Terrain pieces

A terrain instance is placed in a $TERRAIN section, and has the following lines:

COLLECTION - Specifies the style the terrain piece is from. To reference a terrain group, specify the style as *GROUP.
PIECE - Specifies the piece.
X and Y - Specify the piece's location.
ONE_WAY - Allows one-way arrows to be applied to the piece. Does nothing for steel pieces.
ROTATE / FLIP_HORIZONTAL / FLIP_VERTICAL - No value needed, specifies to apply the corresponding transformation to the terrain piece. Remember that files are not order-sensitive; and thus, Rotate is always applied first.
NO_OVERWRITE - The piece will be drawn behind other pieces instead of on top of them.
ERASE - The piece will function as an eraser.



Terrain groups

Terrain groups - basically, collections of terrain pieces that can be used as if the resulting formation was itself a terrain piece - can be defined with a $TERRAINGROUP section.

The group consists of a NAME line which gives the group a name; after this, it consists of simply one or more $TERRAIN sections, which work exactly the same way as the $TERRAIN sections for the level itself, except that the ONE_WAY flag is ignored.

However, there is a rule about the pieces used in a terrain group - inside a single group, you cannot have a mixture of steel and non-steel pieces; they must either all be steel, or none are. The group as a whole will have the same steel / non-steel nature as the pieces inside it. Eraser pieces are exempt from this rule.



Preplaced lemmings

Preplaced lemmings are defined with a $LEMMING section, containing the following fields:

X and Y - Specifies the starting position of the lemming. Note that this is the physics coordinate of the lemming; ie: the point where the dot appears if you mouseover the lemming in clear physics mode.
DIRECTION - Specifies the starting direction, "LEFT" or "RIGHT". Defaults to right if not specified.
SHIMMIER / CLIMBER / SWIMMER / FLOATER / GLIDER / DISARMER / BLOCKER / ZOMBIE - Gives the lemming the corresponding state or permanent skill.

12
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!

13
NeoLemmix Tutorials / NeoLemmix Formats - Basics of text-based files
« on: August 11, 2019, 08:16:17 pm »
Aside from audio and graphics, NeoLemmix data files are generally text-based. This includes levels, replays, object metainfo - pretty much everything. This means you can open them in a text editor, such as Notepad, and examine or even modify the data in a relatively human-friendly form.

NeoLemmix uses the same basic structure for all such files, except for "settings.ini" and "hotkeys.ini". Compared to some text-based formats like XML or JSON, NeoLemmix's format is fairly simple. As a general rule - if a file's extension is four letters and starts with "NX", it's a text-based data file that this applies to.

Each line of the file consists of a keyword, and optionally, a value. These are separated by a single space; and any number of spaces may be used at the start of a line (but NOT at the end of a line) for formatting purposes - these extra spaces have no effect on the actual data.

For example:

Code: (A line with the keyword "EXAMPLE", and no value) [Select]
EXAMPLE
Code: (A line with the keyword "EXAMPLE", and the value "Hello") [Select]
EXAMPLE Hello
Values are never enclosed in quotation marks, even if they contain spaces or any other special characters. Keywords are never case-sensitive, although convention is to write them in uppercase. Values generally aren't case-sensitive either, although there can be cases where case is important (for example, a level title) and will be preserved. Convention is less clear here, and either all-uppercase or all-lowercase is considered acceptable.

Numeric values can either be in decimal or hexidecimal. In the case of hexidecimal, they should be prefixed with an x. Eg: COLOR xFFFFFF.

Lines are not order-sensitive, except in regard to other lines with the same keyword. For example, in a file that lists levels for a pack, there would be multiple lines with the "LEVEL" keyword, and the order of these determine the order of the levels in the pack. But in a level file itself, there would be a "LEMMINGS" line (for the lemming count) and a "REQUIREMENT" line (for the save requirement), and it does not matter which one comes first, because they have different keywords.



In more-complex files, there is a need for grouping data into sections. As an example, a level file would have a section for each terrain piece, a section for each object, etc.

A section is started with a line consisting of a keyword, prefixed with a $ sign. The group is then ended with "$END". It is convention - but not a requirement of the format - to indent the lines inside a group with two spaces. Here's an actual example taken from a level file in Doomsday Lemmings:

Code: (A terrain piece) [Select]
$TERRAIN
  COLLECTION namida_horror
  PIECE clump_04
  X 45
  Y 128
$END

As with lines, groups are order-sensitive with regard to other groups that have the same keyword, but are not order-sensitive with regard to other groups that have a different keyword.



As some last notes, you can include comments in a NeoLemmix text file by putting them on a line beginning with # - as usual, this can have any number of spaces before it. You cannot start a comment mid-line - comments must be on their own line. It is also perfectly acceptable to have some blank lines to break things up - these are simply ignored by NeoLemmix.

14
NeoLemmix Main / NeoLemmix V12.6.0 experimental [Updated 19-08-12]
« on: August 08, 2019, 01:48:28 am »
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.

Changelog from V12.4.1 (click to show/hide)


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.

15
NeoLemmix Main / Any issues with recent experimental features?
« on: August 04, 2019, 08:06:57 pm »
You can get an experimental including secondary-anims and shimmier here:
https://www.lemmingsforums.net/index.php?topic=4188.0

I'm wondering if anyone has encountered issues with these, or has any last-minute input to give about them? Since Nepster has been inactive for a while, I'm going to try over the next week or so to get an update containing these features ready. I intend for this update to contain the following major features:
- Shimmier
- Secondary animations
- 10 skill types per level
- Limited-count exits / entrances
- Replay user-matching
- Remembering the last-played level

The update may or may not contain (we'll see how it goes):
- Neutral lemmings
- Piece grouping - player support will be implemented but I cannot promise anything editor-side

This update won't yet bring:
- Restoring the online features
- Resizable terrain

Pages: [1] 2 3 ... 40