I was testing a level out and I wanted to see how many stackers, hypothetically, would be required to make this fall safe, if that's the route I decided to go to get the shimmier down. With three stackers, the shimmier will survive the fall, but the climber dies. I don't know if the shimmier gets an extra pixel of safe fall distance or if the climber gets one less pixel of safe fall distance.



I'm guessing it's probably a bit too ingrained to fix, even if it is a bug, but I figured I'd at least report it.

At the very least, the splat ruler doesn't really lead me to identify this as the expected result.

Fairly self-explanatory, really.

Right now, when you look at an exit in clear physics mode, it tells you it's an exit.
If the exit is locked, it also tells you it's an exit.

It does not tell you it is a locked exit; this must be inferred either by interpreting the graphic outside clear physics mode or by finding buttons in the level.

So I found out you can do a thing. I don't think it's intended, but technically it could be used as a feature. I'm not endorsing this technique, but I think it's best to go public about this discovery, and let the community and namida decide what, if any, response should be made to prevent it, rather than relying on obscurity to make sure people don't do it. Of course, if you know relative file paths, it's pretty trivial, but on the other hand you might simply not have thought to try this, because, well, you probably shouldn't actually do this.

Maybe this should have gone in the Bugs and Suggestions subforum instead, but I wasn't comfortable calling it a bug and also wasn't comfortable calling it a suggestion either. I guess I'm intending a discussion here? Still, mods: I won't be upset if you decide it should be moved there.

---

This is almost certainly bad practice and you probably shouldn't do it.

A recent post by WillLem led me to believe he'd encountered an issue with a music pack masking the default music and got me thinking about the way music filenames are handled and how name collisions can occur because of it. I wanted to think about ways the engine could help prevent these collisions (beyond just hoping pack authors adopt their own unique subfolders or naming conventions), and this made me think about whether we could allow level packs to store their music in their own fully self-contained music folders inside the pack, instead of part of a separate directory. I wrote up a huge post about it (along with some other methods of alleviating some of the issues) and then second-guessed if it was worth posting, but I then thought about this:

What if it's already possible for level packs to have their own music folders stored with the pack and not in the music folder?

It turns out, it is! Suppose your pack is located in levels\My_Pack and you want to put the music in My_Pack\Music (as opposed to a My_Pack subfolder in the main music folder). We're already allowed to have our music in a subfolder of the main Music folder, and this is the feature we can abuse to accomplish this nonstandard music location.

The music selection box lets us type the filename in. This is useful because otherwise subfolders wouldn't work, and subfolders are useful since they mean we can store the music for a particular pack or author together to try to reduce the chance of name collisions. It would also be a pain to find the file you want if your music folder is filled with the music from several level packs, so typing it in lets us find it faster. Plus, even if we weren't allowed to type it in, we could just fill in the relevant information in a text editor. There is also nothing that stops us from nesting these subdirectories, which is still useful for something like Music\Author_Name\Pack_Name\[songs go here]. If we are in a command prompt and a certain subdirectory of some arbitrary directory, and we want out of that subdirectory, all we need to do is type cd ..Now we have everything we need to put the music wherever we want: to put the music for the pack in levels\My_Pack\Music, all we need to do is type the following into the music selection box:
..\levels\My_Pack\Music\[song]

I'm not sure if this should be allowed, but the engine won't stop you.

---

It'd be pretty stupid to step outside the NeoLemmix base directory because from that point on who knows what the directory and filesystem might possibly look like, but it is allowed by the engine. Absolute paths, however, are not (which is a sensible design choice since there's absolutely no reason to use an absolute path since it likely won't work on anyone but the original creator's machine, unless by coincidence someone else uses the exact same folder structure).

---

I'd say that \..\ in the relative path probably shouldn't be allowed, but perhaps packs should be allowed their own internal music folder since this does have some utility for avoiding name collisions by keeping the pack entirely self-contained - though if we decide to go that route, we'd definitely want to discuss the exact rules for it, since it would probably be a useful feature to allow a structure that allows multiple packs by the same author to share music.

Found in latest stable; did not test in latest experimental.

Updated OP with more accurate steps.

To replicate:

1) Load or create any level.
2) Load a level that is the same size as the current level, but has a different background.

Result: The background from the first level will be shown. This is purely visual and only affects the editor: the correct background will be shown in the player, and if the second level is re-saved, it will keep its original background (unless you change it yourself, of course). This only happens the second level is loaded; a new level will not be affected, even if the first level is the default size.

This size requirement means that in a fresh editor session, you can't properly display the background of a default-sized level with a background other than the default solid black without first taking other actions, such as resizing the default blank level, loading another level (of different size) first, or manually selecting the correct background.

The earlier report had some incorrect observations as a result of the at-the-time unknown size requirement.

Old report

To replicate:

1) Load or create a level that has a background.
2) Load a level that does not have a background (i.e. the default solid black).

Effect: The background from the first level will remain displayed in the editor. This appears to be a rendering bug in the editor: if the level is played or saved, the level will not contain the background. This will only happen if the first level has an image for a background, not a solid color provided by the level theme (e.g. the solid blue from L2 Sports). However, a solid color provided by the level theme does count as a background for the second level, and will be displayed properly. EDIT: This observation on my part was due to another requirement, found by namida - the level must be the same size for the bug to occur. I tested with a solid color background level I already had lying around, which was a different size than the level I found the bug with, which led to the expected behavior rather than the bug behavior, and when I tested new levels, I didn't run into the issue because none of my recent levels use the default size, and I didn't think to try changing it in the test levels.

This also does not appear to happen when creating a new level instead of loading an existing one. EDIT: Retested this with the new knowledge about the size requirement; this observation holds.

I think that should be understandable, but I'll provide more concrete examples just in case:
For all examples, when I say "using [style]" assume the level theme is set to this style.

Example 1:
1) Create or load a level using orig_marble and the style's included background image. You do not need to save this level.
2) Load a level that uses orig_marble or orig_crystal (it probably happens with the other orig sets too, but I can personally confirm it happens with these two), but does not use the included background.
Result: the loaded level will show the orig marble background in the editor.
3) Save and/or play the level
Result: the level will have no background

Example 2:
1) Create or load a level using L2 Sports. Make sure to set the level theme so you get the solid blue background!
2) Load a level that uses orig marble or orig crystal, but not the included background images (again, this just happens to be what I tested with).
Result: the expected solid black background will be displayed.

Example 3:
1) Create or load a level using orig_marble and its included background image.
2) Load a level that uses L2 sports (and its solid color blue background).
Result: the expected solid blue background will be displayed.
EDIT: These observation is a result of the level size difference.

Under certain conditions (the exact details of which I haven't quite worked out yet) the talisman conditions for some levels cannot be edited.

I'll update with more details if I can figure out exactly what's going on, but I've attached the level I found this on.

The talisman "Optimization Lv. 2" was intended to have a limit of 3 bashers, but was saved with no requirements. I didn't notice this when the v9 update was first released (it was a contest level). When I noticed, I tried to fix it through the editor, assuming it was an oversight on my part, only to find that I couldn't change it. I thought that it might be due to its similarity to the talisman "Optimization Lv. 1" (limit 4 bashers), so I tried removing one of them, and the delete button didn't do anything.

Manually editing the talismans in a text editor worked as expected.

Some custom content exists featuring custom lemmings sprites and recolors. While many of these are fair and well-designed, there are a few that lack colors for neutrals, athletes, and zombies.

Ultimately, it might be difficult to prevent such content from being created. Even if you were to require unique colors, someone could always try to make one with the minimum allowed differences.

I think a good solution to this on the player's end of things would be to include an option to force the player to use the default sprites, even if custom sprites or recolors have been provided.

The topic title can probably be improved.

No-Effect objects do not interact with the No Overwrite checkbox in the same manner as other objects.

Suppose I were decorating a level using a water object. The water object is, by default, no overwrite, so it only appears behind other objects. But, if I want to draw it in front of an object, I simply have to disable the No Overwrite checkbox. However, No-Effect Objects do not respect this checkbox; they can be drawn where there is no terrain, or you can turn on Only On Terrain to draw the object on top of terrain, but you can't have a single No-Effect Object that is drawn in front of terrain the same way you can with a water object. I imagine this was most likely done to prevent troll levels from being made, but in this case it 1) interferes with non-troll decoration and 2) doesn't actually even help because a workaround exists: you are allowed to perfectly overlap a No Overwrite No-Effect Object on top of an Only On Terrain No-Effect Object, which will look and function exactly as it would if No-Effect Objects respected disabling the No Overwrite textbox.

---

Suggested discussion questions:
Should this restriction be kept? If so, should the workaround be removed (this would likely require a reworking of Only on Terrain to be tied to object types instead of object instances)?

Suggested changes:
Considering that users who want to make troll levels can still do so by making a custom style, I'm not sure I think removing legitimate decorative features that can potentially be abused to make troll levels is the way to go about it - after all, such users can be punished simply by leaving bad reviews on their packs . However, contrast this with Fake or Invisible Objects: these features are really only usable for troll levels, so culling them was a wise decision. For that reason, I'd suggest making No-Effect Objects respect the No Overwrite checkbox being off (for compatibility, the checkbox should probably be applied to non-Only On Terrain No-Effect Objects when loading levels predating this change, if implemented).

That said, I do think it's important that whatever choice is made here is done consistently. Thus, if we decide the existing restriction to require No Overwrite for No-Effect Objects should be kept, the checkbox in the editor should be grayed out to match, and the workaround should be patched by reworking Only On Terrain to not allow it to be applied to specific instances of arbitrary objects.

Couldn't find anything about this online. Attempting to run on actual hardware.

Error Handler : Error Number 8001
457712 bytes Main memory used
1443168 bytes Expanded memory used
27136 bytes Main memory free
32111264 bytes Expanded memory free
1432 bytes of Data Space free
MEM Error : 1 : No Memory Available of required type

Figured I'd see if I can figure out why it's not working. Don't know what the hardware requirements are or if the computer in question meets them - I think I've had it running on that computer before, but maybe I've always only had it working on DOSBox and forgot about it.

I was working on an unrelated practice project earlier today, and some of what I was thinking about while working on it made me curious to see if the lemming indexes would get messed up if you used cloners with replay insert mode.

Sure enough, this causes assignments to get shifted to different lemmings.

I created a fairly generic level layout where lemmings would be trapped on either side of the level, remaining capable of receiving assignments. Lemmings spawning from the trapdoor would head to the right, while lemmings created by cloners assigned to newly spawned lemmings would head left. Lemmings had access to being a cloner or a builder.

Test Case 1:
- Assign a builder to the second lemming some time after spawn.
- Restart the level, and turn on Replay Insert Mode (the blue R thing)
- Assign a cloner to the first lemming before the second lemming spawns
Expectation: The builder assignment should be unaltered (assigned to the second lemming from the hatch).
Result: The clone will use the builder.

Test Case 2:
- Assign a cloner to the first lemming as soon as it spawns.
- After the second lemming spawns from the hatch, assign a builder to the clone
- Restart the level
- Bring up the replay edit mode and delete the cloner assignment.
Expectation: The clone's builder assignment shouldn't happen because the lemming no longer exists.
Result: The second lemming from the hatch will use the builder.

Test Case 3:
- Assign a builder to the third lemming.
- Restart the level and turn on Replay Insert Mode
- Assign a cloner to the first lemming as soon as it spawns
Expectation: The builder assignment should be unaltered (assigned to the third lemming from the hatch).
Result: The second lemming from the hatch will use the builder

Because of the behavior here, a cloner assignment can cause problems to skill assignments that should have been independent of the cloner; for example, in a multitasking level.

This is likely caused by the lemming indexes: Lemming 0 is the first to spawn, Lemming 1 is the second; if a cloner is used when N lemmings are in the level, the spawned lemming will have the index N (not N+1, because the count starts at 0). Normally, lemming N would have been the next lemming to spawn from the hatch. When a cloner is inserted or removed, indexes at or above the clone's index get shifted around to different lemmings than they would have otherwise been, so the skills get assigned to the wrong lemming.

But if you altered the resulting lemming index for the clone, it would break replays. Maybe it would be possible to adjust the assignments such that they will still correspond to the same lemming (probably deleting them if they would have corresponded to the clone)?

We seem to have several reasonably experienced programmers on these forums, so I thought I might put this question here.

I'm still trying to learn how classes work and when to use them. From what I've read about them, they sound like they'd help me with organization on larger projects. I might just be having some sort of misconception about how to use classes, but I've come up with the following illustrative example (the actual project has nothing to do with barnyard animals, but I think it's a simple way to illustrate why I want to organize things this way that I suspect the language doesn't want me organizing them):

Suppose we have barns filled with animals and food. In this example, the food supplies in each barn are shared between animals in the same barn, but not between individual animals. Each animal has a daily routine that involves eating if there is enough food in the barn (else, the animal starves). So I'd like to organize things like this:

Note that this isn't intended to be partial code in any language. It's just pseudocode.
class Barn:
    contains animals and food

    method have_animals_do_stuff:
        for each animal in animals:


My first instinct would be to try nesting classes, which the interpreter does seem to allow, but it seems like this doesn't actually accomplish anything since from what I could find it sounds like Python doesn't let inner classes access outer class variables.

It's not really a big deal, since it can be fixed just by adding or subtracting a few pixels from the height such that the height is divisible by 4 (I think that seems to be the pattern, at least), but updrafts do not tile correctly in the y direction when their height is not a multiple of 4. It looks correct at all sizes in the x direction.

It also looks correct to me in the editor, but of course it's not animated in the editor.

To reproduce:

1) Select an entrance or an exit that has a lemming limit. Alternatively, assign a lemming limit to an entrance or an exit that does not have one.
2) Attempt to place a new/select an existing object for which a lemming limit is not supported.

The editor will then display two error messages one after the other. The display order is first "Set lemming limit, but first selected piece is not able to have this value!", then "Lemming limit set for incompatible object." You can click through the error messages and continue editing as if nothing happened. I didn't notice anything off about the new objects but I also didn't inspect the file output for any garbage data.

Note that this does not happen if you attempt to add terrain. If you attempt to add a new object that supports a limit, the object will still be created with the default value of 0 as expected (i.e. it doesn't appear to be trying to assign the selected object's lemming limit to the new object). Unselecting the entrance/exit first does not prevent the error from appearing, nor does selecting terrain before selecting the object. However, selecting an entrance/exit without a limit before selecting the next object will prevent the error.

---

What if there are multiple objects in the selection? I noticed some inconsistent behavior. If I have time later, I can try recording a video of this if it would help with investigating the bug. I spoiler tagged it because I'm not as confident in the accuracy of the description.

Spoiler

If you have a multiple object selection, it will not produce an error if you add new objects to an existing selection, or if the new selection contains multiple objects. If the selection contains at least one entrance/exit with no limit, it will not produce an error. If it contains only entrance/exit hatches with lemming limits, sometimes selecting a new object gives an error, and sometimes it doesn't.

When thinking about the Validate Level functionality due to it being mentioned in another thread regarding the skill count, I remembered that it warned about missing hatches/exits and thought to see what would happen if I put a single preplaced lemming in a level with an exit and no hatch in a level whose stats were not changed from the default save 20 out of 40 lemmings. I expected I'd have an unbeatable level and maybe Validate Level would complain about it. I definitely didn't expect what behavior this actually caused:

The player recognizes the level is only capable of dispensing one lemming, so it shows level stats of 1 lemming, 1 to be saved. However, when it checks the results at the end of the level (assuming the player solves the level successfully according to the displayed stats), it disagrees with itself as to whether or not you beat the level: the displayed stats are consistent with beating the level (1 lemming, 1 saved), but it provides a message consistent with failure: "A little more practice on this level is definitely recommended!" Internally the game appears to treat this as a successful solve: the autosave successful replays feature will save the replay, and if the level is run through the player and not the editor, you will receive a checkmark for completing the level.

The attached level demonstrates that the player will adjust the level's obviously bad stats in an attempt to make it beatable. I suspect the mismatch between the result and the end of level message is due to the message being based off of the level's original stats rather than these adjusted stats.

The Validate Level functionality only mentions that the level is missing a hatch, which is true, but maybe a little vague. On the other hand that is the root cause. So while the Validate Level could probably be modified to detect this particular issue more specifically, it's probably fine as is for this particular scenario.

EDIT: This is specific to levels with the ability to dispense 0 or 1 lemmings (including preplaced). I was also able to replicate the behavior using a hatch set to spawn only 1 lemming. Validate Level will display an error that the level's save requirement is too high in this case rather than that the level is missing a hatch.

Currently the player allows displaying either the release rate or the spawn interval, spawn interval is saved internally into the editor's output, but the editor requires release rate. This means that players who use spawn interval have to convert to release rate when using the editor, or manually modify the spawn interval in the output file.

The editor clearly already knows how to interpret spawn interval, since it's what gets saved into the file. Would it be possible to allow users to use spawn intervals as well if desired?

Currently, the editor allows you to create a level with 11+ skills despite the 10 skill limit. It will warn about it when validating the level, but it still lets you save it with the excess skills assigned.

The player handles this gracefully by truncating the excess skills. But this creates a potential problem: In addition to resulting in some strange behavior when trying to modify skill allocations without exercising caution to ensure you don't exceed the limit (why is this skill I'm trying to add not showing?), if an eleventh skill is accidentally left in during development and hidden by the truncation behavior, these hidden skills could reappear if the limit is ever changed again.

I'd suggest graying out the fields for unused skills when the maximum number of skills have already been selected (by graying out only unused skills, this should prevent levels which have been manually edited to contain more than the maximum allowed number of skills from causing strange behaviors when loaded in the editor). To show that the editor does in fact save all the skills, rather than deleting the excess, a demonstration 1-of-everything level is attached.

Shift-space toggles between objects and terrain, which certainly has its uses. That said, sometimes I want to make a level title in all caps for stylistic reasons - and I usually end up holding shift to do that rather than pressing caps lock. This causes the shift-space function to trigger and prevents me from finishing typing the level title.

If a textbox has focus, and shift-space is pressed, the textbox should keep its focus. (As far as whether terrain/objects get toggled, I don't really care, as long as I can keep typing text in the box).

Currently, the level theme (main tileset) and the working tileset are completely independent of each other. This makes sense when you're just grabbing a piece from another set, but it's a little inconvenient whenever you're starting a new level (because you have to choose your tileset twice).

I suggest making it as follows:

• If the level is blank: Change both
• If the level contains objects and/or terrain: Keep current behavior.

Not sure if there's anything that can be done about this, but...

I tried to post something with an attachment, but it was too large. Rather than throwing an error, and allowing me to edit the post/attachments, everything was cleared, and I had to start entirely over (hence why I just posted a topic with the first post pretty much saying nothing but "placeholder").

Tested with starting a new topic, using Firefox as the browser. I haven't tested what happens if you're replying to an existing topic, but will attempt this and see if it gives the same result.

EDIT: I tested it by attempting to post a reply with a large attachment to this thread. It seems that it takes you to the "Start New Topic" page for some reason if the attachment is too large.

I made some covers of the original lemmings soundtrack (mostly the Amiga version, but drawing from a few other versions as well) using Famitracker. I made these over the course of about two or three years, or something like that. It's been quite a while since I started these - but it's a complete set, including the intro song and the special graphics levels. I then sat on them for a few months after finishing them. Seeing those VRC6 covers reminded me that I'd never gotten around to releasing these, so... I decided I might as well post them.

The project was first started as a way to one-up the really, really low quality music of the NES port of this game. As such, I chose to maintain similar limitations/restrictions - specifically, no expansion chips were used, and the DPCM channel (low-quality sample playback) was not used.

Doggie and cancan have two versions of them - both have one based on their Genesis/Megadrive version; Cancan has another based off of the Amiga version; Doggie has another that mixes some aspects of the Amiga and the Genesis version. I felt a straight-up port would not work particularly well for Doggie, so the introduction section present in the Amiga version is not present, instead skipping directly to the actual song. Some songs have had other edits. Lemming2 has a percussion line added based on the Lemmings 2 version. Lemming3 has had some slight modifications to the notes in an accompaniment part, simply because something that sounded fine on the Amiga came across very dissonant when ported note for note to pulse waves (this change is quite subtle, and would probably only be noticed with a side-by-side comparison). The bassline in Mountain was filled in a little, as it sometimes cuts out for chords for what appeared to be limitations in the Amiga version that were for some reason carried over to just about every port.

To open the FTM file, you'll need this. http://famitracker.com/
The .ogg conversion was too large to upload as one post, so I had to split it into multiple .zips. Sorry.

Playing the Lemmings Redux pack currently on the experimental since a feature I use a lot in stable is bugged and doesn't work.

Found this... interesting bug on Lemmings in the Attic after accidentally splatting a lemming and trying to start over.

Upon pressing the hotkey to restart the level:

- Sometimes the replay fails to play at all.
- Sometimes the replay plays some, but not all of the skill assignments back
- Sometimes it works normally
- Bringing up the edit replay menu sets the game state to where it should be in the replay.

I haven't been able to reliably predict which behavior will occur, but there seems to be a decent spread.
My setup was, during replication tests, to assign climbers and floaters to lemmings 2, 3, 4, and 5 for crowd control purposes, and a builder to lemming 1 when it reaches the gap (counting the first lemming as 1, in case the game considers the first lemming to be 0).
'
EDIT: Upon further testing the only thing I've really noticed is that it seems most likely that, if you play a level, perform a few skills, then restart, repeatedly, allowing the replay to play through, the most likely result, starting on the second attempt, is whatever happened on the previous attempt, though the other alternatives can certainly still occur. But whenever I think I figured out how to influence the result I usually end up being wrong. For example, I was able to cancel it at one point by pausing the game, but this didn't end up being a consistent way to replicate this bug, and it can happen without any pausing.