EDIT: Locked by namida as there's no useful info to go on, and no further reports of this happening. Please create a new topic or PM me if you have more info / it resurfaces / etc.

---

I figured I'd report that this happened, though I have yet to figure out why it happened.

When launching NeoLemmix Player, the following errors appear

Error 1:
Error loading level packs and/or progression. Progress will not be saved during this session.

Error 2:
Error during settings loading:
EAccessViolation: Access violation at address 00B43628 in module 'NeoLemmix.exe'. Read of address 0000000C
Default settings have been loaded. Customizations to settings during this session will not be saved.

Error 3:
An error occurred while trying to save data.

The menu will then load. No pack will be selected.

On attempting to select a pack:
Access violation at address 00B313D6 in module 'NeoLemmix.exe'. Read of address 0000000C.

F3 on menu for settings:
Loads properly.
When exiting this menu:
An error occurred while trying to save data.


On exit:
Error 1:
An error occurred while trying to save data.

Error 2:
An error occurred while trying to save data.

(not a copy/paste mistake - the error appears twice).

So far, it hasn't come back after creating a fresh installation and copying over settings, levels, replays, styles, music, and pretty much all the data you'd actually care to preserve between installations. I did attempt replacing the .exe in the original installation with a fresh one, which did not fix the problem.

The first attempted launch which exhibited this behavior was when testing an in-development style through the editor, but that might have been a coincidence.

From the components present in a NL style, it is often possible to build up much more complex pieces using combinations of blocks and erasers, such as the numerous vertical/horizontal to diagonal bar transitions in this level:
_{(yes, I keep re-using the same level images I have lying around if they happen to demonstrate my point)}

Now that we have terrain grouping, I can see that it has useful properties when working on these sorts of combinations: not only do they become easier to select, any erasers that are included to make up the piece are absorbed completely into the group and essentially become a private member of sorts: it exists to the pieces inside the group, but the surrounding pieces only see the net result of the combination of pieces and don't have to worry about implementation details like what erasers were necessary to make the block possible. In that sense, the terrain block thus functions exactly as a piece provided by the style. You can even use it as an eraser or as part of another terrain group - that's right, nesting terrain groups works exactly how you would expect, and they ungroup cleanly one nesting level at a time.

So, what's the suggestion?

---

These are two closely related but also mostly independent suggestions, though if both are implemented the implementation of 1) may have implications for the best way to implement 2).

1) Allow user to save commonly used terrain groups. They could then be lumped in with a style's terrain or as an additional groups tab to go with objects and terrain... well, most of the time. But sometimes styles get mixed, and then how should that be handled? Should the piece be shown in the groups tab for each contributing style?

2) Allow style developers to provide pre-built terrain groups. To simplify dependencies, it might be best to require all pieces come from the style the group is defined in. These could then be displayed either as regular terrain, or in a separate groups tab as described in 1). Many styles already feature distinct terrain pieces that are essentially just concatenations of smaller components (e.g. pillars and longer pillars in orig_pillar; bars and longer bars in orig_marble); while this wouldn't necessarily replace that for backwards compatibility reasons, it would be an option for new styles going forward.

---

Since terrain groups are simply groups of other terrain, levels wouldn't need to be aware of whether the user used a saved/pre-built group or built one from scratch like you can do currently, since it would all look the same in the level file. Therefore, in addition to convenience, it would allow more flexibility in updating styles without introducing breaking changes, as pieces provided as terrain groups can safely be modified or even completely removed from the style without breaking levels that use them as long as the underlying component pieces are left unchanged.

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.

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.

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.

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.

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

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.