Thanks for uploading these, Turrican. I've added this one to the OP.

P.S. I know you're pushed for time, so pictures and a description are more than sufficient

Maybe I should go between the NL years and do LPIII?

+1 for this: current custom packs need a bit more love.

+1 for keeping it as a laser, and I've always generally preferred "Laserblaster" over "Laserer" as a name, but I'm not set on it.

I quite like the beam as it is in all honesty, although I'm open to other ideas. Maybe a pulsating beam with a ripple effect might look cool, or it could even "twist" - really, the possibilities are endless for this. Making the laser beam customisable is something I'd strongly be in favour of, since then people could modify it to be a water cannon (or basically any other idea they wish), for custom sprite sets.

I had a play with the sprite a couple of weeks ago in the EXP, dressed the lem in a dark purple outfit, and made the laser cannon itself purple & silver. This is so it would be more easily identifiable on the panel (since no other skill currently has a purple motif); just messing around with the possibilities, I'm not suggesting that this be the final version by any means:



Very intrigued to hear other people's ideas!

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.

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.

* Set all objects of a chosen type to no-overwrite

There's a RegEx for this using Notepad++

Objects appear as $GADGET in .nxlv files, so the way to do it would be to choose Find in Files, go to Replace, and enter the following:

Find what: \$GADGET

Replace with: \$GADGET\n  NO_OVERWRITE

And make sure that Regular Expression is checked. It should look like this:



N.B. This will insert "NO_OVERWRITE" for all objects, including those that already specify it. I'm not sure what happens in this instance, but I'd guess that the double entry would just be ignored.

---

Alternatively, if you want to specifically change a particular object (for example, an exit), but within any style, try the following:

Find what: \$GADGET(.*?)PIECE exit\r?\n

Replace with: \$GADGET\1PIECE exit\n  NO_OVERWRITE\n

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...