I'm attempting to implement a hotkey which sets the skill count of the current level to infinite-of-each (types remain the same).

It's easy enough to make the count change happen (barring a few wierd bugs when backskipping). The real problem I'm having is that it isn't as simple as just "set the skills to infinite, and then change them back later if you want" because if the level provides 5 of something, you set it to infinite and then use 6, what should happen when you press the hotkey again?

I can think of 5 possibilities:

1) Once applied, the skill count stays infinite until the level is restarted. Pressing the hotkey again doesn't change the count again at all. This is easiest to achieve and probably makes the most sense.

2) The count resets to the originally available count. This might seem to make sense, but if a player is already halfway through the level having used an infinite count to get there, then the original count becomes fairly meaningless. They might as well just continue with the infinite count.

3) The count resets to the originally available count, and restarts the level. Better, but might seem a bit jarring.

4) The count resets to the originally available count, minus the skills used, and any minus counts just show as zero. This option is slightly better than the second option, but would be the most difficult to manage code-wise and is fairly pointless seeing as we have a "used skills count" which would be far more useful in this scenario.

5) Keep the count at infinite, and toggle the used skills count on. This one also makes pretty good sense having considered the middle 3 options, but has the potential to be the most confusing.

Option 1 is my favourite. I think that if a user has chosen to switch on infinite skills, they've committed to playing the rest of the level with that option enabled, and so it should remain active until the level is either completed or restarted. The only problem with it is if the player accidentally hits the key without meaning to.

Another complication is replays: ideally, toggling infinite skills should be written into the replay so that any replays used with an infinite count on would make sense to the viewer, and wouldn't be broken by simply watching them without infinite skills.

Also, any levels played with infinite skills on shouldn't count towards level records, for obvious reasons. This would need to be managed as well. I think SLX might just be too complex an engine to deal with a feature like this.

I could do with some feedback on this. Do people think it's worth implementing the feature at all? What would you expect to happen if you pressed the hotkey again? Would you use it if it was there? I'm currently about 70:30 in favour of just chalking it up to "it's a good idea, and fun to do, but probably isn't worth the trouble."

I went down something of a rabbit hole with the end-of-play conditions yesterday. Here's what I've come up with:

Single-lemming Levels
If the initial lem count is 1, and 1 lemming dies, then the level doesn't end. This works nicely, and obviously works for levels with cloners as well (since, if the lemming is cloned once, and then 1 lemming dies, there is still another lemming in the level to keep it active. If that lemming then dies, the level should end anyway).

The only thing I'd like to add here is some sort of on-screen message such as "No lemmings remain. Rewind, Restart or Exit" to make it clear that there's a reason play is continuing with no lemmings on-screen.

If this works, the behaviour could extend to any condition where no lemmings remain (including when only zombies remain, which brings us nicely to...)

Only Zombies Remain
Ideally, now that we have a Kill All Zombies talisman, we don't want levels to end when only zombies remain. Thankfully, the talisman code includes a CheckForZombiesKilled method which can be used to prevent the level ending unless it returns true. That part ended up being easy enough (although further testing is needed to make sure that it behaves properly in all cases).

However, there is still the problem of what to do when only zombies remain and the user nukes. At the moment, the level ends instantly (only 1 frame of nuke animation is seen; the beginning of the countdown appears above one or two zombies); I've scoured the code and can't find any obvious cause for this, but ideally we want the nuke animation to play out before the level ends, otherwise it looks like an unintentional bug. It's not massively important, since it's purely aesthetic, but I do want to tidy up as many of these loose ends as possible.

Time Is Up
This has ended up being my favourite one to work on. The 'lems freezing mid-exit' behaviour is gone for now (since I always thought it looked a bit buggy), but I've left the code in comments in case we want to bring it back for any reason.

We still have our "overtime" period, where the time counter starts counting upwards in purple, and no actions taken during this period count towards the level result. But, I've made a few improvements:

Instead of freezing mid-exit, lems now fully exit and then re-spawn from the entrance hatch, creating an infinite loop which allows the player to start from the beginning of the level and work their way across again (with all previous skill usage - builder bridges, basher tunnels, etc - still present on the map). To compliment this, the skill count is set to infinite-of-each so that the player can fully experiment with the available skillset (although, at present, it isn't possible to assign skills to re-spawned lems - not sure why ).

If I can get this fully working, it seems a shame to relegate this behaviour only to levels with time limits (especially since most levels tend to get made without time limits nowadays). It might be worth creating a hotkey which allows the player to activate this mode on the fly, for example if they're stuck on a level. Doing so would obviously have to instantly fail the level (so, if the level is exited during this state, the level would count as a no-solve), whilst pressing the hotkey again could revert to the previous state (before the hotkey was first pressed), so that the level can be completed from there if the player has come up with a solution in the meantime. This is pie in the sky at the moment, but the behaviour itself works perfectly for TimeUp conditions and can therefore be tested for potential usefulness elsewhere.

Plenty to think about.

From a conversation on Discord:

Blocker fields are ignored on one way fields ... it's occuring in NL too

it's a minor complaint but it'd be nice if the menus like level selection, replay selector, settings etc; went away with ESC. This is expected behavior with most standard windows applications.  Of course it'd be nice if regular NeoLemmix also had this but I never mentioned this until now, that I remember

Yes, good idea. I'll get this sorted.

I'll aim to make it so [Enter] is OK, and [Esc] is Cancel/Close, where appropriate.

When converting level packs from NeoLemmix to SuperLemmix (which should ideally only be done either by the original author, or with their permission), there are several significant physics differences which may affect certain levels. These levels may need to be modified or even replaced altogether if a conversion is to be successful.

To name a few:

1) Direct drop is now possible (aka lemmings can fall directly into the Exit from a great height, as long as they hit the Exit trigger before they hit the ground). This also allows mid-air exiting.

2) Jumpers and Reachers can now jump into a mid-air Exit.

3) Sides are solid rather than deadly, and the top of the level is open to allow Jumpers and Projectile skills to continue their arc of trajectory back into the level. Other lems will stop what they're doing if they reach the top, and either walk forwards (if possible) or turn around if there's a terrain/steel barrier.

4) Shimmiers can be assigned to Climbers at any time.

5) The Laserer's range is now 3200px instead of 112px (so, it's effectively infinite given the 2400 x 2400 limit on NeoLemmix levels)

6) The water graphics from the following styles have been changed:

orig_fire water is now "lava," an unswimmable object which triggers the burner animation
orig_marble water is now "poison", a swimmable object which changes the lems into zombies
ohno_bubble water is now "blasticine", an unswimmable object which triggers the explosion animation (no surrounding terrain destruction occurs)
ohno_rock water is now is now "vinewater", an unswimmable object which triggers the vinetrap animation

It's very quick and easy to replace the graphics if needed, I've posted instructions for how to do so here.

If I think of anything else I'll post it here, but these are the main things which will affect level solutions between the engines.

---

If porting one of your NeoLemmix levels to SuperLemmix, I would advise the following:

1) If the level contains Stoners, swap these out for either Blockers, Freezers or Stackers depending on how they're used in the level. For most levels, this shouldn't affect the intended solution too much (although it will obviously have some impact, particularly if the level relies on pixel/timing-precision).

2) If the Exit can be accessed from directly overhead (albeit from a great height), consider blocking this route off if you don't want players to able to drop the lems directly into the Exit. Otherwise, leave it as an alternative solution for players to find

3) If the Exit is in midair, consider whether you want it to be accessible by any of the following: Jumpers, Reachers, Floaters, Fallers. If so, leave it, if not then you might need to fix the level to prevent this.

4) If the level contains Laserers, then tbh there's not a great deal you can do if the solution relies on the original limited range. I would consider redesigning or replacing the level in this case.

5) Any levels containing the water graphic from orig_fire and/or orig_marble will need to have the graphic replaced with orig_fire (lava) and/or orig_marble (poison), respectively. I've posted some step-by-step instructions for how to do this here.

---

With all of this said, of course it would be great to have some NeoLemmix packs ported over to SuperLemmix, and I'll do what I can to help anyone taking on this task. But, it may be even better to create new levels which make use of the new features and mechanics.

I'll be essentially re-writing my own packs for this platform (eventually!). Some levels will copy over nicely, others will need to be redesigned or replaced entirely.

This post makes me think that the auto-replay mode when restarting a level should always be optional.

At the moment, Classic Mode disables replay features altogether. But, people might want to auto-cancel replaying when not in Classic Mode. Yes, you can just click in midair to cancel the replay, but there is nothing prompting users to do so and I remember it being particularly irksome before I got used to it.

So, I've now added auto-cancel-after-Restart as a side-effect of unchecking "Replay After Backwards Framesteps." If people think that's sufficient, then I won't do anything else. But, if it should be a separate option, then I can look at adding this to the Config as well.

Note that SuperLemmix currently auto-cancels the replay after reloading from the level select screen or the preview/postview screens; this feature was added in the most recent update.

Thoughts?

I thought I'd start a topic listing the bugs that I'm aware of and trying to find fixes for. Since I'm introducing a lot of new features and behaviours with SuperLemmix, bugs are inevitable. This will help me keep track.

("WIP" means that this bug is only present in the current working copy, not in the latest stable release).

See fixed bugs here.

BUG 4: Mouse-on-land isn't preserved when zooming (present in both player and editor). This bug is also present in NeoLemmix, as detailed here.

BUG 31: Lems are not properly recoloured if both (a) hi-res mode is active, and (b) the engine is falling back to default sprites due to a missing sprite in the target style - recolouring otherwise works as expected

BUG 32: Jumpers cause a CheckPos crash when exiting from a teleporter-receiver

BUG 36: Blockers are drawn to the decorations layer even when not in water - Fixed in Commit 646ae1c03