Version 4.0 Update

A small but very significant update. Styles are now handled differently so that they are smaller and easier to maintain.

If you're using an earlier version of RetroLemmini, it's strongly recommended that you update to Version 4.0.

Here's what's new!

Style Handling

• Objects no longer need to have a separate 'om_' image with the trigger rectangle. Instead, we use maskX, maskX, maskWidth and maskHeight in the style's .ini to set the trigger rectangles.
• If you're a style creator, you can use the Editor's trigger area rendering capability (go to View > Show/Hide Triggers) to make sure you've set the correct values.
• Objects are now named 'stylename_o_n' instead of 'stylenameo_n'. This is so that styles can have names ending in 'o' without potentially causing problems.
• All included styles have been updated to this system - levels and replays are unaffected.

Force Fields

• It's no longer possible to Rotate/Flip/Invert Force Field objects. This is to keep the graphics consistent with the physics.

Entrance Hatches

• Under the new style handling system (see above), lemming spawn points are now set by the maskX and maskY values for entrance hatch objects. The spawn point is shown both in the Editor and in the updated Debug mode.
• It's no longer possible to Rotate entrance hatches (they can still be Flipped/Inverted!). If any existing levels use rotated hatches, I'm happy to add a new rotated hatch object to the 'special' style.

Up/Down One-Way_Arrows

• Upwards and Downwards-facing One-Way_Arrows have been added to all OG styles courtesy of EricDerkovits. Some of the images need to be upscaled to hi-res, which will be done over the next few weeks. You can keep the styles up to date by going to 'Help > Update Styles'.

More Java Exception Eliminations!

• When a level doesn't load, we now show exactly which resource is missing that's causing it not to load.
• The lack of a second value in the 'sound' section of a triggered object's .ini entry is now tolerated by being defaulted to 1 (so, the sound will play on the first frame of the animation unless another frame is specified) - see this topic for details.
• Improved error messages for missing resources.

Debug Mode

• Object trigger areas are now shown when in Debug mode. Please note - this should not be routinely used when playing levels as levels cannot be legitimately counted as 'solved' in Debug mode; the feature is intended for use when creating and maintaining levels and/or styles. I may consider adding this as its own feature (a 'Physics View' similar to the one in NeoLemmix), but there would have to be a lot of vocal support for this from RetroLemmini users; I'd very much prefer to keep it as a Debug-only feature.
• The panel info layout is improved and now shows object type when mousing over an object.

UI/Bugfixes

• The browser now always opens at the 'levels' folder when adding an External level.

See also - RL Editor release topic for the latest version of the dedicated RetroLemmini Level Editor.
N.B. - You must update to Editor 2.1 for cross-compatibility with RetroLemmini 4.0 - a copy of the Editor is included when downloading the RetroLemmini update to ensure that you're good to go.

---

Get the latest version of RetroLemmini here.

Version 2.1 Update

Skipped version 1.9 to go straight to 2.1 due to a significant update to Style handling.

If you're using an earlier version of RetroLemmini, you must update to Version 4.0 for Editor 2.0 to be cross-compatible.

With that established, here's what's new in the Editor!

Online Updates
 • The Editor can now check online for updates! This happens automatically once per week when starting the Editor, or can be done manually using 'Help > Check For Updates...'

Style Handling
 • In accordance with RetroLemmini 4.0, the Editor now looks to the style's .ini folder to find object trigger areas. This system replaces the 'om_' object mask images so that styles can be smaller and easier to maintain.
 • Furthermore, objects are now expected to be named with the updated suffix '_o_' rather than 'o_' as before.

Hotkey Config
 • Added 'Clear Current Key' button.
 • Bugfix - 'Edited' label persists until changes have been saved successfully.

UI / Bugfixes
 • Added default title 'Untitled' when creating a new level.
 • Rotate/Flip/Invert is now disallowed for Force Fields to keep behaviour consistent with RetroLemmini.
 • Rotate is now disallowed for Entrance Hatches (they can still be Flipped/Inverted).
 • '_pg' object gfx no longer show up in 'Terrain'.

---

Download the latest version of the RetroLemmini Editor.

Hi hrb264, thanks for taking the time to create this new style and level pack for RetroLemmini! It's great to see some creativity and personality in these levels, and you've done well to bake in a consistent theme throughout - pun very much intended!

The levels themselves are fun to play and showcase the Jewish theme well with clever titles and interesting layouts. The levels are not as easy as they look at first, and present a challenge similar to that of the "Tricky" levels in that they provide plenty of skills but also plenty of obstacles and irregular terrain to work your way around. Nice work!

As for the style, it's very inspired, very colourful, and certainly decent enough for a first effort at creating a style, which is a very difficult thing to master. I like the background color and the fact that the builder bricks are red - this is good attention to detail and really helps it to feel like its own thing.

I do have some suggestions that would improve things a bit:

You could try making all of the pieces half the size they are now. You wouldn't lose any detail at that resolution, and you'd probably find that the pieces would become a bit more versatile as well.

The objects need a fair bit of work. There are some inventive ideas for traps that fit the theme very well, but I'd definitely suggest resizing these so that they're a bit more lemming-sized and can therefore have a more appropriate trigger area. Also, the animation frames need to all be exactly the same size and offset relative to one another to keep the animation smooth and consistent. I'll happily take a look at these with you at some point - creating animated objects is no easy task!

Also, the 'metal' style is required to play a couple of the levels. You mentioned that since you're only using one piece you might add it to 'shalom' and maybe recolour it to fit your theme even more - I'd say that's definitely a good move.

Other than that, this is a very good first set of levels and style pieces. Keep up the good work!

---

I've taken the liberty of re-uploading the levels and style with the style re-named to 'shalom' instead of 'shalomx', since RetroLemmini 4.0 and Editor 2.0 can now play nicely with style names that end in 'om'. The objects also needed a tiny bit of empty space cropping off the bottom so that their height is divisible exactly by the specified number of frames - this has also been done for you. The animations themselves and positions in the level remain identical.

I'll be happy to help you develop your style further if you wish.

This is now fixed in RetroLemmini 4.0. The lack of a second value in the 'sound' section of a triggered object's .ini entry is now tolerated by being defaulted to 1 (so, the sound will play on the first frame of the animation unless another frame is specified).

Fixed in RLPlayer 4d026a2.

Quote from: lemmkeev20 on October 16, 2026, 11:11:11 AMi dont really use community edition so yeah make them downloadable styles that are compatible with all versions of neolemmix

NeoLemmix 12.14 and NeoLemmix CE use the exact same styles and always will - just thought that should be made clear.

Thanks for reporting!

Fixed in NLCEPlayer commit 8a9d103.

Quote from: UltimateLemmings on October 14, 2026, 08:55:36 AMOh no. I just discovered that the macintosh graphics also contains 1-bit graphics for the 9" Macintoshes. So guess what I naturally did...?

My guess: you've added those as low-res versions?

If so, this is even more of a reason to have these as separate "mac_" styles.

Quote from: lemmkeev20 on October 15, 2026, 12:07:47 PMi thinks we should decide which way do we make the MACINTOSH II styles be...

should they be a HR replacement OR downloadable styles

Downloadable styles, all day every day.

If they must be hi-res replacements, I'd personally want to have a lot of say as to exactly which images are selected as I'm one of the few people who exclusively uses the hi-res mode. The process of adding the images would therefore take longer, and it's likely that a good chunk of them would be vetoed in favour of other versions.

And, again, even if I was completely outvoted and everybody wanted to use only the Mac images as hi-res counterparts to the orig_ and ohno_ styles, many of the images are a slightly different shape and would need to be edited for compatibility anyway. This is not a trivial task; someone would have to do the fine-editing work for every affected piece.

Basically - if people want the Mac styles, unedited, as-is, let's just add them as their own styles and have done with it.

Thanks for reporting!

Fixed in NLCEPlayer commit 167bb84.

At present, the Lemmini codebase relies on 2 things to know the relative position and size of an object's trigger area:

1) A separate image (with an "om" suffix, which stands for "object mask") with solid pixels giving the size of the trigger area

2) "maskOffsetX" and "maskOffsetY" values in the style's .ini to specify the final position

One of these, then, is completely redundant.

The separate image can give position as well (offsets would be 0, 0) by being the same size as the object, and having the solid pixels in the exact position that the trigger should be.

Meanwhile, if we're using offset values to 'correct' the position anyway, we might as well just specify width and height whilst we're at it and get rid of the separate image altogether.

Given that the separate image inflates the size of the style on disk unnecessarily, this is what should be eliminated. We can then specify trigger area position and size in the following way:


maskX_n = x
maskY_n = y
maskWidth_n = w
maskHeight_n = h


For the above, "n" is the object's ID, whilst the values on the right of the "=" would be the correct figures required to position the trigger relative to the top left of the object, and then size it accordingly.

No need for unnecessary loading and handling of a separate image, just one easy set of values for style creators (and dev!) to maintain.

Previously, the separate image was likely useful for visualising the trigger area; this is the only reason I can think of as to why it might have initially be done this way. But now that we have visible trigger areas in the Editor, we can easily use this to ensure that trigger areas are located and scaled correctly.

So - it's very likely that the next RetroLemmini update will have this system implemented.

All styles will need to be updated accordingly - there will be no backwards-compatibility handling in either RetroLemmini or the Editor. I'll most likely create a handy tool that can output the correct values quickly and automatically, ready for dropping in to the style's .ini. Since I know of only a small handful of Lemmini style creators, and basically all styles are managed by ericderkovits and I, it's unlikely anybody else will be affected by this change.

To be absolutely clear: levels and replays will NOT be affected by the proposed update, only styles. And, they will become smaller and easier to maintain as a result!

Discussion welcome. If you have any comments or suggestions, now's the time to speak up.

Quote from: namida on August 11, 2026, 09:16:22 AMhttps://demozoo.org/productions/224224/

This seems to be what [Lemming Curd Porto Caval Shunt]'s a reference to.

And in finding this and sharing it here, I've probably instantly moved it one or two tiers up the iceberg.

That's the Paradox of something being at the bottom of a list.

For example, someone might list 'Most -> Least Interesting Songs'. The song at the bottom of the list suddenly becomes more interesting than those above it, because it automatically begs the question of why it's the least interesting, which is a point of interest!

The same thing applies to 'Most -> Least Known Facts'. Whatever is at the bottom will become more known simply by its position in the list.

Quote from: namida on October 13, 2026, 08:38:37 PMThat being said - if for whatever reason one did want to make an HR-focused style, I don't see any problem with creating HR graphics then downscaling them to create the LR versions.

Yes, this could be an acceptable solution.

Quote from: namida on October 13, 2026, 08:38:37 PMI don't think we need yet another version of the official styles just to achieve that, rather than making these the HR versions of the existing ones.

It's not as simple as that.

At the very least: not all of the Mac gfx are the same shape as their low-res counterparts. This is something we'd need to tackle if we were going to make these images the basis of a hi-res set.

Then, there are some pieces that just... don't look as good (IMO). An example being this one, in Pillar (which is also a different shape):

      
L->R: Mac version, Windows 95 version, Amiga version (200% Nearest)

IMO, the best version from the above is probably the Amiga one, but - of course - it isn't actually a hi-res image.

If we wanted to make a proper project of this, take our time and get it right (we should!), we could do something like this, which solves the shape issue and (IMO) looks better:


Top of Amiga version composited with bottom of Mac version

Other pieces we could just use as-is from the Mac version, of course. There are likely to be only a small handful of pieces from each style that will need manual TLC - but they will need it.

Quote from: namida on October 12, 2026, 11:28:01 PM

Quote from: WillLem on October 12, 2026, 11:11:56 PMmaybe we could support hi-res-only styles in CE. If a level uses them, temporarily switch to hi-res whilst that level is playing.

This would break 12.14 compatibility.

How? Unless I'm mistaken, the compatibility direction is that all 12.14 content must be playable in CE, not the other way around.

If I'm not mistaken, there's no reason we couldn't support hi-res only styles if people agree it's a good move. That would mean we could simply supply these gfx as "mac_dirt, mac_crystal, mac_fire, etc..." and keep them as independent styles (which I would prefer tbh).

Quote from: UltimateLemmings on October 13, 2026, 12:12:40 AMIf you need help sorting the graphics in a format better suited to NL I am happy to assist.

That would be very helpful!

Maybe a few of us can take a style each and go ahead and prep all the graphics. That would certainly be better than one person doing all the work by themselves.

I'd like to nominate Crystal as my chosen style if I'm involved (dibs!)

Quote from: Proxima on October 13, 2026, 12:28:58 AM

Quote from: namida on October 12, 2026, 11:28:01 PMBut, could they be used ... for supplied, rather than upscaled, high-res graphics for the default styles?

That was the idea when Will and I started doing exactly that a couple of years ago, with a copy of the Mac graphics sourced from, I believe, ccexplore. We got through most of the pillar style, and I still have those graphics on my installation of NL.

The only issue (as far as I remember) is that many of the Mac gfx aren't the same shape as the Amiga/DOS gfx. The low-res ones would provide physics anyway, but it could look very odd if the hi-res counterparts don't match.

Another issue is that some of the Mac gfx don't look as good as the Windows '95 upscaled versions IMHO. Others look perfectly fine with NL upscaling, and others still look great simply resized with 2x Nearest Neighbour.

I'd probably suggest that, if we were to take on this project properly, we should take each piece and choose whichever looks best out of the following:

1) 2x Nearest Neighbour resize
2) Windows '95 version
3) NL's hi-res upscaled version
4) Mac version

I wouldn't be too concerned about asset clash here either: I have a handy tool that can perform color swaps in multiple images simultaneously, so we could easily normalize the color scheme for all pieces regardless of their origin.

That's my two cents. I anticipate disagreement, so - if we're just blindly using all the Mac gfx - we should at the very least ensure that all of the pieces are the same shape as their Amiga/DOS counterparts.

Or, we could just go ahead and add these as independent mac_* styles and support hi-res-only style sets in CE.

Or, we could add them as independent styles and then resize them by 50% for the low-res versions if people don't want hi-res-only styles to be supported.

---

NOTE: As a hi-res user, I feel particularly strongly about what happens here. Watching this space.

Wow, yeah...

Looking at the folders, it would take a while to get those sorted into proper styles. Also, the images are all hi-res so wouldn't be supported in NeoLemmix or CE without low-res counterparts. We could of course use the existing gfx, but what would be the point? - this is a style that's meant to be seen in hi-res.

Which brings me to an idea: maybe we could support hi-res-only styles in CE. If a level uses them, temporarily switch to hi-res whilst that level is playing.

I'm currently looking at implementing a low/hi-res on-the-fly debug switch anyway, so... this could be even more of a reason to go ahead with it.

Quote from: namida on October 12, 2026, 08:39:44 AMI think the main focus of his post is the ripped Mac graphics he's offering for use...

Yeah, thanks for pointing that out. I've updated the title.

Quote from: lemmkeev20we need a tutorial or something to how to finish the folders

What are you struggling with?

Quote from: Simon on October 11, 2026, 09:15:05 AMMakes me wonder how you're going to load from file a previously-rotated forcefield.

Load it untransformed. The point of this fix is to have these objects behave consistently between levels; previous levels that used transformed force-fields are no longer supported, then (but there are most likely 0 such levels anyway).