Also posted on Github as on one hand it seems like the most appropriate place to report bugs, but I thought it would be useful to post here too as I imagine people will be more active here than on the Github issues page.

Observed during 1/27/2024 lemforum session on central server.

A player dropped and rejoined. The other players in the lobby remained visibly readied up, but when all players were shown as ready, the game did not start. Appears there was a desync at some point. My client version is 0.10.18, compiled from source (I know I wasn't the only one affected, but I'm not sure what version everyone's client was or exactly how many players were affected; I want to say one or two people may have still been on 0.10.17).

I tried to reproduce this with a locally hosted server; the observed behavior was that a player leaving and rejoining would unready all players in the lobby. I need to do some further testing e,g. if the client crashes somehow. I don't know what version of the server is running on the central one; I'd assume it's probably up-to-date but have no way to confirm. The locally hosted one I used to test should be 0.10.18.

---

Edit Simon: Solved in Lix 0.10.19 with a client-side bugfix. This 0.10.19 and newer can still play with older 0.10s: If the game starts at all, it starts for everybody at the same time.

MOD: Split from this topic.

---

Something to think about:

SL is still a relatively new engine, so if you're going to break existing content, this is the time to do it.

That said: the reality is by forking NL and not starting from scratch, you've inherited lots of design choices from NL. You should decide exactly which inherited NL features are up for potential changes and which ones are being kept as-is, even if you don't know exactly what changes you're planning. Currently, at least from an observer perspective, it looks like SL's existing features are still making many breaking changes and I certainly wouldn't feel confident making any levels that aren't boxed in (so you can't use the sides) and Classic 8 skills because anything else might change behaviors. Seems like every time I look at the SL board there's some other established feature being completely overhauled in a way that would break existing content -- which is fine for NeoLemmix content, since that's not designed for SuperLemmix, but also consider that you may be applying an expiration date to early SuperLemmix content because it's too difficult to predict how things will behave in SuperLemmix 3 months from now, let alone a year from now.

If a climber or a slider is facing left and passes through a permanent skill remover, they will be embedded in the wall.

(For clarity, since Sliders turn: the slider would have been traveling right before transitioning to slider: that is, this always occurs when the skill is interacting with a right-facing wall, thus lemmings interacting with the wall are facing left).

The object works as expected when lemmings are facing to the right.

For what it's worth, when NL redefined Release Rate in order to remove the duplicated values in the original, I switched my config to Spawn Interval because I figured if I was going to have to relearn the values, I may as well use Spawn Interval because the definition is very unambiguous about what you get when you use it: the spawn interval is the number of frames between spawns, whereas release rate is an entirely arbitrary scale.

Having cleanse levels available from the player makes sense when you're updating a pack's worth of levels in bulk, but if you load an outdated level in the editor, presumably you want it updated to the latest format, and I've definitely seen a few instances of editor bugs where the problem was "user failed to cleanse level prior to attempting to load it." While this is easy to workaround, it's not really readily apparent that failure to cleanse the level is causing the issues (essentially, "Did you try cleansing the level first" has become the NL editor equivalent to "Did you try rebooting?"), and it's kind of annoying. Why would the user want to load the level without cleansing it first, when this can cause problems? Of course, there's one major technical problem: the level doesn't appear to store any information that would indicate that it needs cleansed. But that's fixable: we could add a field tracking this, and if this field doesn't exist, we know the level predates it and therefore should probably be cleansed just in case, so go ahead and cleanse it.

This has definitely been brought up before, but I'm not sure it's ever been made its own thread, so I'm going ahead and creating a thread for it.

---

Problem: A pack might want to have certain items provided by theme.nxmt consistent for the whole pack, e.g. Lemming sprites. To do this, currently one must set all levels in the pack to the same theme. However, theme.nxmt also affects things such as one-way-walls, pickup skills, builder colors, the background color, which we would probably still want dependent on the level's information, and not the pack's. So if we want to have custom lemming sprites for the pack, but retain other style properties given by theme.nxmt, we must create a theme for every combination of custom lemmings and styles that we might want!

Proposed Solution: A pack could provide a theme.nxmt file that isn't required to be complete. Anything present in the pack's theme.nxmt replaces the equivalent fields provided by the level's. Ranks could also provide these, too, although this would raise the question of what happens if the pack and the rank both provide one. More on that later. This still leaves individual levels out (I still might want the custom lemmings in an individual level, after all!). Theme.nxmt is a pretty small file, though - if we really want to override it in an individual level, we could simply embed one within the level (alternatively, a file with the same filename as the level but different extension). Of course, this would result, as implied earlier, at least 4 potential sources of theme to go through, so how would we decide what gets priority?

I'd suggest going in the following order, where the first item is the one that's processed first, and then each subsequent item overrides the result of the previous operations:

Level's specified theme.nxmt -> Level's embedded theme.nxmt -> Rank's theme.nxmt -> Pack's theme.nxmt

I haven't actually checked if subranks are a thing or not, but if they are, we'd just work our way out starting with the level's subrank to its parent, continuing until eventually reaching the theme.nxmt of the parent pack.

Finally, if we really wanted to be able to stop overriding at a certain point (perhaps we want a specific level's embedded theme to take priority over the pack's), we could mark fields as "FINAL" which would block that field from further overrides.

Ever since the introducing of style mixing back in whenever-that-was, the theme (which affects things like colors, lemming types, etc.) has to be tracked separately from pieces. For this reason, when building a level, it can be easy to forget to change this, leading to orig_dirt's color schemes basically becoming the default since "oops, I forgot to change it to match the primary style!"

I'd suggest creating an "auto" setting for theme, and making it the default for new levels. When auto is selected, the theme will be taken from the style from which the most terrain pieces and objects are taken. This might not always get it right - for example, if you have a primary style with a few really big pieces decorated by many smaller pieces from a different style - but you'd still be able to explicitly specify.

A possible edge case would be if there are any ties. If this happens, use something like alphabetical order to determine the result. If the result is determined during player runtime, I wouldn't suggest using something like styles.ini - the final result should have an objectively correct answer that's not dependent on the player's settings. However, the editor could bake it into the level (in which case the player would not need to know about it) - though this has the disadvantage of losing auto when the level is saved for the first time. This could be countered by having the editor save the result of auto in the level, but also store the fact that the theme was set to auto; the editor would then load auto, while the player would load the result.

Objects with default size are loaded/created with the size of the graphic, not the default size of the object. This affects adding new objects to a level, as well as loading levels predating the vertically resizable water.

The player loads these levels fine.

There isn't much about this port out there (I've seen several lists of ports that are unaware of its existence), so I've been messing with it a bit.

These are my somewhat disorganized notes on it:

It doesn't use either the Amiga or DOS music ordering. I have not yet determined if music is tied to the level or to an order like in DOS.

The level format is largely shared with DOS, and the PC-98 levels can be loaded and saved by vanilla Lemmix without issue. Repeat levels appear to be stored differently somehow - I didn't see an ODDTABLE.DAT. I assume it's probably still there somewhere, though - but I don't know where. Passwords are shared with DOS as well, and the special graphics levels are included. I have not noticed any level differences between DOS and PC-98 so far. However, the UI is based off the Amiga version rather than the DOS version.

I don't have much experience with the DOS version glitches to test them in this version, However, I was able to confirm that direct drop works in this version of the game. I would not be surprised from what I've seen so far if most of the DOS glitches still work here.

This information is largely adapted from this guide intended for Touhou.

Disclaimer: While I haven't noticed any issues with them, follow the download links at your own risk.

Note that a copy of Lemmings is not provided here. You will have to find that yourself.
The emulator: The Touhou guide recommends using the unofficial fmgen build, available here (scroll down until you find a file called "np2fmgen.7z" - 7zip is required to extract it): . Lemmings doesn't appear to use any features that benefit from this build over the official one, but relevant to Lemmings, there is a speedup function in the fmgen build. The audio emulation is noticeably better for some games in the fmgen build, but Lemmings seems to emulate plausibly well in both versions (I don't have real hardware to compare to at this time). The rest of the guide will assume the fmgen build, though much of it will work in the official build.

Configuring the emulator: There's multiple executable files in the fmgen build download. Multiple of them will probably work, but I'd suggest using np21nt.exe. The colors will look super wrong by default. You can improve this considerably by turning on Real Palettes (under the Screen menu). It doesn't seem to be perfect, though - I don't know if it's an emulation problem or if that's just how the PC-98 port is. Also, go to Emulate -> Configure, and set the multiplier next to the CPU selection. 32 should work okay, but if the performance seems bad, experiment with it a bit. I got bad performance when this was too low as well as when it was too high. Unlike DOSBox CPU cycles, however, I didn't seem to notice any immediate changes when messing with this - you'll probably need to reset to apply the changes.

Launching the game: You'll need to mount the disk image. If you've got a harddisk image, mount it as one of those (Harddisk -> IDE #0 or SASI #0 depending on build); if you've got a floppy disk image, you'll want to go to FDD1 -> Open (no guarantees they both exist). Then, go to Emulate -> Reset and it should start up. F12 should activate the mouse. If it doesn't, go to Device -> Mouse.

Edit Simon: This thread arose from NeoLemmix, SuperLemmini and Lix, Feature Comparison by WillLem.

---

Quote from: SimonThe Java Runtime is beh as a dependency, can't just ship the game binary and DLLs, always have to tell people to install Java.

This is another topic I could go on a very long rant about. As a user, I hate Java (I've also heard things about the language itself, but I can't really speak for that because the fact that any Java code I'd write would have to be run on the JRE is honestly kind of a dealbreaker for me). I hate Java so much.  And it's not just the fact that you have to download a runtime environment that makes this annoying, because you need to download the Python interpreter to run Python code, and that language isn't nearly as irritating about it.

Quote from: WillLem
For what reason? This strikes me very much as a "hating for the sake of it" kind of thing. Java is fine: the vast majority of applications require you to install something, Java RE is something you only install once and then you can run any Java app natively. And, it's multi-platform compatible. I'd say that's relatively convenient, as computer-stuff goes.

What I will say is that Java runs very slowly on my Mac, for some reason, and that is a bit disappointing, but not annoying. It's a 2012 MBP, so it's probably just not been able to keep up with the updates.

Well, since you asked:

Dullstar's Java Rant

A lot of this is based on some... adventures... with modded Minecraft, so I suppose it's possible that I'm directing blame to the wrong place, but...

The JRE has two major issues (or at least, had - I've had the updater silenced for quite some time since I only use it for Minecraft now). First, it has my least favorite type of updater: the one that simply tells you that an update exists, but you have to do all the work yourself. This would always lead to a lot of fun adventures back in the day related to making sure Minecraft had all the memory it needed: the downloads page would (I seriously hope they've fixed this by now) always want to take you to the 32 bit version, so then you'd have to track down the 64 bit version instead, which of course was not on the same page because of course it wasn't. Okay, so you found the 64 bit version, let's try to install it, aaaaand oh it wants to install some other junk we don't want. Untick those boxes for like some McAffee trial or Ask toolbar or whatever it was they were peddling... okay, finally, it's installed! A few days later - there's a Java update! Click here to start updating. You wanted the 32 bit version, right? No? Well, then, find the 64 bit version again... download... start the installer... untick the boxes...

For comparison, the Python interpreter:
Go to the website, click downloads, it's easy to find the other builds if it doesn't default to the one you wanted, run the installer, and you're done. No wild goose chase to track down the 64 bit version, no extra junk to opt-out of during the installation. You only need to do a bit of manual work with the installation if you want to change some of the settings, but the defaults are all reasonable.

The second issue is that the JRE is terrible at memory management. For many applications, this doesn't matter because the memory usage never gets that high, but that's not the case for every application out there. Instead, you must tell it how much memory it should allocate ahead of time. Now sure, there's defaults, but they're not suitable for all applications, and when you have to mess with them, that's when things get pretty nasty. Don't allocate enough, and the program will keep pausing to run the garbage collector. You can give it a bit more breathing room by expanding the amount of memory it has to work with, but be careful if you're running other applications in the background! Allocate too much and the JRE will crash when it needs to use that memory - it can't cleanly handle the system running out of memory. Granted, many applications can't - but Java is garbage collected, so if you run out of memory, there is something it should be able to do: run the garbage collector to free all the junk. So if you've got an application that requires a lot of memory, such as a modded version of Minecraft, you'd better make sure there's no memory hogs running in the background like web browsers can sometimes. Being able to limit the memory usage of an application that's holding onto unneeded stuff in memory simply for performance isn't a terrible idea - that'd be great for making my web browser play nicer with other applications since it likes to hold some stuff in memory to speed up loads and overtime can lead to the browser consuming like half of the available memory even though it doesn't actually need that memory to function. But if you're running something like a game, you probably want the computer to give the game everything it's got (well, if it would benefit from it anyway), and this is where the weaknesses of Java's memory management show through the most. That's because the maximum memory allocation size isn't just a cap: it's also a promise to the JRE that it will receive up to that much memory if it requests it. This means I can't give it free reign to use as much memory as it needs, because I have to choose a maximum memory allocation such that I expect it to always be available. And of course it doesn't allocate this right away (I mean, it really shouldn't, but if it's going to behave the way it does at least this would make it a start-up error instead of a runtime error) - it waits until the application needs that memory, but it also adjusts the behavior of the garbage collection based on this, so you'll have a lot of situations where it decides to allocate more memory instead of running the garbage collector. And then if that memory isn't available, the program crashes! Frustrating!

I'm guessing this probably didn't get a lot of attention during the testing of the release candidates, because many (most?) of us have automatic saving on, but I recently wanted to save a best-attempt replay of a level I wasn't able to solve, and that has to be done by saving manually. So, on the post-view screen, I clicked the save replay button.

Expected: Preferably a file dialog, but at least some sort of feedback indicating that the replay was, in fact, saved
Actual: Replay saved silently, with absolutely no feedback. At first I thought my click didn't register until I tried it again and it still appeared to do nothing

I think a file save dialog is the best option here, because if I'm choosing to save a replay manually, there's probably something special about it that would make it desirable to explicitly choose a filename rather than relying on the automatically generated filename.

I'd like to suggest adding an optional version field to the level format. This information, if present in a level, would also be saved into replays made for that level.

The main use of this, in my opinion, would be for replay management. Currently, other than trying to load it and see if it works, there's no way to tell what version of a level was made from unless it's been baked into the filename. You could alter the level ID, but then a replay is recognized as being for a completely different level, and depending on what changes were made, there is a chance the replay might still pass - so it is still potentially useful to load a replay from an old version in a later version of the level - certainly, the chance the replay passes is a lot higher than the chance a replay from a completely different level passes. I believe you can still load the replay anyway, but it would be useful to have a different warning for "This replay is for a completely different level" and "This replay is for a different version of this level."

Sometimes, people have an outdated version of your level (and don't realize it) and they submit a replay they think may be a backroute. It may still be useful to watch the replay, even if it fails the current version of the level: is it an old backroute that you've already fixed? Or is it a new backroute that could still be made to work in the current version even if the changes to the level were enough to break the replay? But which old version of the level does the replay go with?

If a replay from an old version passes a new version, it might be beneficial to have it automatically resaved with the new version as well, either as a separate file, or by allowing the replay to store a list of versions that it's known to work against.

There could also be some potential for discussion of what, if anything, the editor should do to help manage this, but I think that might be best saved for after we decide whether or not this feature should be added at all.

Sometimes, orig_pillar can be a bit of a pain to use: it has a lot of blocks that really seem like they should follow a grid, but they're off by a few pixels, making it difficult to combine differently-sized pieces to build larger structures. L2, however, follows an extremely strict grid, and as it turns out, a lot of changes had to be made to the style to compensate for this (I've documented most of them in another topic). I proposed adding the pieces to orig_pillar, but there was more support for making a completely separate L2 classic style, so that's what I've done here using some .pngs containing the tiles and objects provided by Icho.

I certainly find this set a lot easier to use than orig_pillar, and hopefully I'm not the only one who will find it useful.



Trigger areas for objects are based off of the trigger areas of the sets they originated from. The traps currently don't have any constant animations despite being closely related to objects from other sets (of course, they also don't blend in very well...) - still, it might be better if it had them. If you want to provide these, they are welcome additions.

---

2021-01-24: updated for resizable terrain. Pillar and wood pieces (that are not end caps) can now be resized. There are no plans at this time to make the blocks support nine-slicing, though I would probably accept the modification if someone wants to do it themselves as long it's acceptable quality.

This is probably a known issue, but on the other hand there aren't a lot of resizable objects that don't just tile the whole graphic right now. In fact, there's only one that I'm aware of, and that's the default updraft graphic. However, in the L2 classic style I'm working on, I didn't really see a lot of reason why the water shouldn't be vertically resizable, so I went ahead and set that up. But it doesn't look right in the editor. Works fine in game.

Editor:


In game:

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.

Found in v1.27, but at least quickly checking in older versions of the editor from installations of older versions (since I usually make a fresh installation each major player version), it's been present since at least v1.11, and is probably even older than that.

It appears to occur with any dropdown menu, as the style selector, music selector, and theme selector all appear to be affected.

OS: Windows 10

Loading a large level before attempting to reproduce is not necessary, but may help to visualize the issues more easily.

Issue 1:
To reproduce:
Load or create any level with a minimum size such that you can scroll the level vertically (you can zoom in to accomplish this). Having terrain and/or objects present in the level will help to visualize the issue, but is not required. Make sure no objects or terrain are currently selected.
Now, hover the mouse over the style selector/music selector/theme selector and use the mouse wheel to change the selected option.
Expected Result: The next option in the dropdown menu should be selected.
Actual Result: In addition to the expected result, the level will also scroll in the direction the mouse wheel is moved. Note that is the same scrolling behavior that occurs if the mouse is hovering over the vertical scrollbar on the right side of the screen. Every other mouse hover location I thought of to try using the mouse wheel either zoomed the level or did nothing (except the horizontal scrollbar, which behaves properly).

Issue 2:
To reproduce:
Load or create any level with at least one terrain piece or object, and select at least one terrain piece and/or object placed within the level.
Now, hover the mouse over the style selector/music selector/theme selector and use the mouse wheel to change the currently selected option.
Expected Result: The next option in the dropdown menu should be selected.
Actual Result: In addition to the expected result, the terrain pieces/objects will be moved in the direction of the scroll wheel. This particularly seems strange because there doesn't seem to be any other circumstance under which the scroll wheel can be used to move terrain/objects.

Note that clicking on the dropdown menu and then scrolling through it with the mouse wheel does not trigger this bug.

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.

Aesthetically, the original game's Pillar style is very similar to L2 Classic. However, they are not the same. In the original game, terrain pieces could be placed on any pixel coordinate, but L2 has a much stricter terrain grid. For this reason, many of pillar's block pieces could not be inserted in L2 unmodified, because they were sized in such a way that they do not line up with the original grid. In fact, many of the terrain blocks can't be lined up with any grid due to the larger blocks being sizes that are not evenly divisible by the smaller blocks.

This design quirk of the Pillar style has made it difficult for me to work with when designing levels, and it's actually caused me to scrap level layouts and redo them in other sets (usually L2 Egypt) on multiple occasions (an example of a level I've released that underwent this change is my Contest 20 level "Tunnel Project"). This is kind of a shame, because aesthetically the style is quite nice. Therefore, I'm thinking I'd be able to get more use out of it if I go ahead and port L2 classic to NeoLemmix and use that instead of Pillar.

When I do this, would it be preferred for me to make it an expansion to Pillar, or an entirely new style?

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.