NeoLemmix V12.11.0-RC Released [RC2 update released]

[namida]

The Release Candidate build for V12.11.0 is now here.

Known issues

Issues that are struck-out here are fixed in source code, but the fix is not yet included in the latest RC release.

- Editor support needed for default sizing in aliases. In the meantime Cleanse Level is your friend.
- Apply default size to piece selection panel in editor?

Download (V12.11.0-RC2, editor V1.34 included): https://www.neolemmix.com/download.php?id=490

This download only includes the Orig and OhNo styles, plus "default", "xmas" and "special". You can use the in-game Style Manager (in the Settings) to download other styles, or you can download styles manually:
- All styles: Not currently available for V12.11-RC; please use style manager or individual manual downloads.
- Any individual style: https://www.neolemmix.com/styles/12.11/XXXXXXXX.zip (replace XXXXXXXX with the style's name, eg: https://www.neolemmix.com/styles/12.11/orig_fire.zip for orig_fire)

As always, it is recommended you install the RC build to a new folder, rather than trying to use it in the same folder as your existing version of NeoLemmix. You can copy across your hotkeys file (from the Settings folder) after running the RC build for the first time.

What is a Release Candidate build in the context of NeoLemmix?

A release candidate build could be thought of as a pre-release version of an upcoming release. The idea is that except for bugfixes, or issues that were specifically noted as "should be tested during the RC phase before deciding", there won't be changes between it and the stable version, and thus it can be used to start updating content, as well as for ironing out last-minute bugs. Content specifically targetting it should not be released, though styles targetting it can be submitted for the next styles download.

Changelog (from V12.10.3)

################
# New Features #
################

> Custom postview jingles are now supported.
> Support has been added for resizable terrain.
> Title screen layout can be customized for each pack.
> When running a mass replay check, options are presented for organising replays based on results (or just in general).

##################
# User Interface #
##################

> Added an option to force the default lemming sprites.
> Added a "timer bypass" nuke, which when activated, inserts a Nuke action into the replay timed such that the first lemming will explode on the current frame. Note that this does not allow doing anything that is not already possible as it simply calculates the correct time and inserts the action into the replay.
> Clear physics mode highlights one-way terrain when moused over.
> Hatches now show the remaining lemming count when in clear physics mode, even if they are not lemming-limited. Zombie hatches do this even outside of CPM.
> Mass replay check draws attention to mismatches between the version of the level used to record the replay vs the one used to test it.
> Mass replay check marks replays which obtain a talisman.
> Much more customization is possible for replay filenames.
> NeoLemmix is now DPI-aware.
> Postview success / failure jingles are now merged into a single option instead of being set seperately.
> Skill panel zoom is now independent of level zoom.
> Zombie color in CPM has been tweaked.

#################
# Other Changes #
#################

> Lemming spritesets are now required to contain athlete and selected-lemming recoloring data. They are also required to contain neutral and zombie recoloring data, but only on levels that actually use the respective kinds of lemmings.
> Level version number is incremented by 1 when running Cleanse Levels.
> Resizable objects can specify a default size that's different from their base image size. (The new resizable terrain supports this too.)
> Selected skill outline is now in a PNG file (which can be customized by packs) rather than hardcoded.
> Water objects in all official styles (including orig_dirt_md and orig_sega) is vertically resizable. Default-height water still looks exactly the same as it did before except minor differences in the ohno_rock water.

#######################
# Bug Fixes - Physics #
#######################

> Fixed buggy behavior when a Climber encounters a Splitter.
> Fixed bug that allowed assignment of Shimmier to a Climber at the top of a ledge.
> Fixed difference in dive vs turnaround height for Swimmers based on whether or not they are also a Climber.
> Fixed inability for swimmers to descend out the bottom of water. (Debatable if this was actually a bug or not, but it's changed.)
> Fixed incorrect fall distance for swimmers.

#####################
# Bug Fixes - Other #
#####################

> Fixed bug where a no-overwrite entrance / exit with a limited count, the remaining lemming count would also be displayed behind terrain.
> Fixed, hopefully, the temp-freeze that occurs if leaving the menu screen while the update check file is downloading. Fingers crossed this one sticks.
> Fixed (to the extent possible) replay issues that arise when preplaced lemmings are reordered and/or cloners are inserted / deleted.

Changelog, V12.11.0-RC1 -> V12.11.0-RC2

> Added support for specifying a size when aliasing a non-resizable piece to a resizable one. (This does not yet have editor support.)
> Style manager now fails more cleanly if a style is not present on the server or a download becomes corrupted.
> Uses a new V12.11 styles folder when accessing the server.
> Fixed bug: Nuke countdown is not removed from a lemming dying in a fire trap

What do I need to do with my existing content?

It is possible that a very small number of replays involving Swimmers might break, so please run a mass replay test. Report breakages, rather than immediately fixing them - it is possible that if the impact is too severe, alternate fixes (with less side effects) may be considered.

That aside, if you have any custom lemming spritesets that do not include recoloring data for athletes and selected lemmings, you will need to add such recoloring data in order for those spritesets to remain useable. You will also need to add zombie and neutral recoloring data for the spritesets to be useable on levels that contain zombie and neutral lemmings, but this is not required for use of the spritesets on levels without those kinds of lemmings. Most spritesets should already have this as it was a de facto standard anyway (just not enforced until now).

Finally, when running a mass replay check, you'll be given options, including to refresh the replays. This is recommended, especially for replays that include Cloners.

[namida]

Just as a point of clarification - V12.11.0 replays can be loaded on older NL versions, though they lose their improved Cloner tracking outside of V12.11.

[namida]

One more feature coming in RC2: Aliases will be able to specify a size. This means that if you have two pieces which are currently just different sizes of each other, you can delete one and use aliases to point it towards the other (while maintaining the correct size).

Editor-side support is still needed for this.

[WillLem]

Exciting stuff! This looks like it's going to be the best update since 12.10!

I've been playing with the new Swimmer stuff, and I've found what might be a bug. A Swimmer encountering a downward slope exits the water (yay!), unless the water is positioned at the top of the level, and then they swim upwards and off the edge of the level...! This happens even if you put a ceiling between the water and the top of the level

This video shows the behaviour in action.

EDIT: After further investigation, it seems that there needs to be at least 7px of terrain between the water and the ceiling to prevent the Swimmer from "ascending" out. It doesn't matter how deep into the terrain the water trigger goes, and it only happens where the setup is at the very top of a level.

[namida]

I've been playing with the new Swimmer stuff, and I've found what might be a bug. A Swimmer encountering a downward slope exits the water (yay!), unless the water is positioned at the top of the level, and then they swim upwards and off the edge of the level...! This happens even if you put a ceiling between the water and the top of the level

This video shows the behaviour in action.

EDIT: After further investigation, it seems that there needs to be at least 7px of terrain between the water and the ceiling to prevent the Swimmer from "ascending" out. It doesn't matter how deep into the terrain the water trigger goes, and it only happens where the setup is at the very top of a level.

It's not a bug, keeping in mind that pixels outside the level area are always nonsolid and have no trigger effect. The lemming encounters a solid pixel at its current height, with a nonsolid pixel above it at a height to which it can ascend, so steps up (via Ascender if necessary). At this point it's outside the level boundaries, so dies.

To visualize it a bit better, look at the attached image. All three preplaced lemmings are swimmers - they don't have athlete colors purely because this screenshot was taken in the editor. (Or maybe I actually didn't make them swimmers, I'm genuinely not sure now, but that doesn't matter as it's just a screenshot.) The bottom-left one is not touching a level boundary. You'd expect him to swim to the edge, then step up onto the steel. The top-left one is just this exact same arrangement, but moved so that the top of the water / steel is touching the level boundary. You'd still expect the same here - he steps up, because it's the same setup, and only open space above. The only difference is that after stepping up he's outside the level, so dies.

That brings us to the top-right case, which can be a bit tricky - what you need to keep in mind is that everything outside the level area is always nonsolid and no trigger area. So, even though the water and steel are graphically cut off part-way, they don't extend beyond the boundary - they're cut off, and it's still empty space above. Thus, this situation is no different from the top-left one.

With that being said - this may not be a bug, but these kind of edge cases are exactly the place to be looking for bugs, so thanks for reporting it nonetheless.

[WillLem]

It's not a bug, keeping in mind that pixels outside the level area are always nonsolid and have no trigger effect. The lemming encounters a solid pixel at its current height, with a nonsolid pixel above it at a height to which it can ascend, so steps up (via Ascender if necessary). At this point it's outside the level boundaries, so dies.

I understand this, and I absolutely would expect this behaviour if there were no solid terrain above the Swimmer. But, in the example video, the lemming is stepping through solid terrain to ascend above the level, not simply stepping out of the water...

[Pooty]

How about this?

This lemming in the image below is a swimmer. It drops into the water and begins to swim towards the exit. It dives down during the first downward slope, but it ascends on the second one and gets caught in the trap. Is this behaviour a bug?

I have also attached the level to this post so you may try it out.

[namida]

It's not a bug, keeping in mind that pixels outside the level area are always nonsolid and have no trigger effect. The lemming encounters a solid pixel at its current height, with a nonsolid pixel above it at a height to which it can ascend, so steps up (via Ascender if necessary). At this point it's outside the level boundaries, so dies.

I understand this, and I absolutely would expect this behaviour if there were no solid terrain above the Swimmer. But, in the example video, the lemming is stepping through solid terrain to ascend above the level, not simply stepping out of the water...

Take the exact setup you're talking about - water, followed by a wall 6px or less tall - and move it away from the top of the level. Do you expect the lemming to step up onto the top of the wall? (For reference, this is the same distance a walker can ascend.) If yes, then it is not a bug that it happens at the top of the level - because that's what's above the terrain there, empty space.

This lemming in the image below is a swimmer. It drops into the water and begins to swim towards the exit. It dives down during the first downward slope, but it ascends on the second one and gets caught in the trap. Is this behaviour a bug?

Again, this is tricky, because a walker in the same situation would be able to ascend the second but not the first. However, with this one, I do see why it might make sense to change the behavior here. What would you feel should happen in these alternate cases? (Assume that any pixel that's blue is water trigger area.)

[Pooty]

Again, this is tricky, because a walker in the same situation would be able to ascend the second but not the first. However, with this one, I do see why it might make sense to change the behavior here. What would you feel should happen in these alternate cases? (Assume that any pixel that's blue is water trigger area.)

Hmm... I'm starting to see why this may be a problem to fix. I would expect the lemming to dive in A, but B is less clear cut. My gut thought is dive again because the top of the ledge is not directly visible to the lemming, but I can easily imagine this breaking some existing content.

[WillLem]

a swimmer... drops into the water and begins to swim towards the exit. It dives down during the first downward slope, but it ascends on the second one and gets caught in the trap. Is this behaviour a bug?

It's not a bug as such, since I understand what namida is saying now: the Swimmer treats the surface of the water exactly the same way as a Walker would treat terrain, and so ascends whenever they meet a vertical wall of </=6px.

The following picture illustrates what's happening:



However, it does feel like something different should happen when there is terrain immediately above and behind the Swimmer, so...

Again, this is tricky, because a walker in the same situation would be able to ascend the second but not the first. However, with this one, I do see why it might make sense to change the behavior here. What would you feel should happen in these alternate cases? (Assume that any pixel that's blue is water trigger area.)

Based on the above image, I would suggest that the large pink dot is where the Swimmer makes an additional terrain check that a Walker does not (necessarily).

So, in situations C and D, there is no terrain immediately above and behind the swimmer, so they ascend as normal (in the latter case, they would transition to Walker before doing so anyway). However, it does seem that examples A and B present situations that should not be navigable to a lemming mid-swim.

Physics-wise, I'd suggest that in these instances (even if the lem is a Climber-Swimmer); if there is terrain above them, they should dive if they can, or turn around if they cannot. "Diving" would, essentially, be the opposite behaviour to "ascending", which is what a Walker would do in these situations. The upright position of a Walker vs. the horizontal position of a Swimmer justifies the difference.

My gut thought is dive again because the top of the ledge is not directly visible to the lemming, but I can easily imagine this breaking some existing content.

Agreed, this tweak may cause potential for level breakage. However, since there have recently been other changes to Swimmer behaviour (specifically when they're also Climbers), maybe now is the time to make the change if at all.

[namida]

Again, this is tricky, because a walker in the same situation would be able to ascend the second but not the first. However, with this one, I do see why it might make sense to change the behavior here. What would you feel should happen in these alternate cases? (Assume that any pixel that's blue is water trigger area.)

Hmm... I'm starting to see why this may be a problem to fix. I would expect the lemming to dive in A, but B is less clear cut. My gut thought is dive again because the top of the ledge is not directly visible to the lemming, but I can easily imagine this breaking some existing content.

The thing is though: Both situations are the same. The lemming encounters a wall going upwards, and a slope going downwards, with a bit of an overhang above. The only difference is how far the overhang extends, but in both case it extends out further than where the lemming is stepping up.

The actual behavior here in turn, just ignores any overhang whatsoever, much in the same way a walker does when stepping up. Taking this into account, the two situations A and B are further the same thing as WillLem's C, as far as the Swimmer -> Ascender transition is concerned. While it has quite significant differences, the Swimmer is ultimately based on the Walker, which is part of where these behaviors come from.

(That does not mean it can't be changed; just explaining why it's how it is.)

[Pooty]

The thing is though: Both situations are the same. The lemming encounters a wall going upwards, and a slope going downwards, with a bit of an overhang above. The only difference is how far the overhang extends, but in both case it extends out further than where the lemming is stepping up.

That is fundamentally the reason why my belief is that both situations should give the same result.

[WillLem]

the two situations A and B are further the same thing as WillLem's C, as far as the Swimmer -> Ascender transition is concerned. While it has quite significant differences, the Swimmer is ultimately based on the Walker, which is part of where these behaviors come from.

(That does not mean it can't be changed; just explaining why it's how it is.)

It's an interesting thing to have discovered, as I wouldn't have expected the two to be so closely linked, particularly because a Swimmer can move around within a water trigger area, whereas Walkers can only walk on the surface of terrain, unless they're tunnelling through it.

This, coupled with the horizontal/vertical orientation of the skills, consolidates my view that the two ought to have different behaviours when encountering the above situation. An overhead terrain check for Swimmers (as I suggested) may be one way to do it, but I'm not sure how it will affect other situations tbf.

[IchoTolot]

I don't think the lemming should always try to dive down.

I would expect him to go through small ceilings in such a situation, as he encounters a small overhang below (even if it's just a pixel).

I think the confusion comes from that an overhang of 1 pixels is already enough to trigger this, but I think you are underestimating a main point here: A swimmer always strifes to get UP and out of the water.

He will always go up if he has a chance and down only if there is no other way (no way to go up or step out). He does not want to dive.

Also I see quite a bit of breakage potential in such a change as stepping out of water surrounded by rougher terrain is quite a common situation.

[namida]

Okay so ultimately - that's not a bug. It may be a bit surprising, but it's logical when broken down. And as such, this behavior will remain as-is.