Right, it's good to offer the game download. The game can fetch a lot itself afterwards.

-- Simon

The game comes packaged with NeoLemmix Introduction Pack (which requires further style downloads after the first rank, but all of them are within what the in-game manager can acquire) and Redux (no additional downloads required, either automated or otherwise), too, so players can get started out-of-the-box.

Are you intending to replicate L2's physics exactly, or just to create a game that feels the same to the user (but might not exactly match how L2 works)?

Just because - if it's the latter case, I would suggest comparing your project to Lemmini rather than Lemmix, as one of Lemmix's most defining features is that it attempts to reproduce L1's physics exactly. (NeoLemmix and Lix would be even worse comparisons due to the additional features in the former, and open-source-overhaul nature of the latter.) That's not to knock it in any way - an L2-like game with QoL features and playable on modern platforms could definitely breathe some new life into the game - I'm just suggesting a wording that might give people a more accurate idea of what you're aiming for.

Format breakages in NeoLemmix have almost always lead to issues, including people coming along many years later with content they never got around to updating the format of - or worse, creating content for old versions when they're already long-since-obsolete.

This isn't to say "don't do it". Just "proceed with caution". Presumably, Lix would keep backwards-compatibility, and it would only be a problem for older versions loading newer levels. In this case, the user should update their software.

Ah, duh.

I need to give that site one hell of an overhaul at some point, really... or at least an update. The downloads are very up to date as that's where they're hosted, but everything else about the site tends to be fairly neglected.

For now, I've replaced that with a "Download NeoLemmix" link. (This link will always download the latest stable version, and doesn't need to be manually updated for new versions.)

I'm going to put up a poll for the "instant" vs "short animation" behavior, and whether it's one-way or bidirectional. Please read this before voting - and in particular note that "short animation" is NOT the same thing as the triggered behavior of the teleporters.

Firstly - this is two different matters. That's why I've put options for every combination, including a "don't care" option. And just to avoid doubt - I will be looking at the votes on each matter individually, not just looking at which combination has the most votes. Or in other words - when I decide on one-way vs bidirectional, I'll ignore the "instant vs animated" part of the votes when tallying up results; and vice versa.

Instant - This would mean that on the frame where a lemming ("L") enters an in-portal, the lemming is transported on that same frame to the out-portal and immediately continues what he was doing.

Animated - This would mean that on the frame where a lemming ("L") enters an in-portal, the lemming would become "frozen" for a few frames and play a short warping animation - presumably half this animation would occur before being transported, and the other half after. Once this animation finishes, the lemming would go back to what it was doing before as if it was never interrupted. (This would be - in terms of visuals only - the same way Lemmings 3D handles teleporters.) This would NOT mean that other lemmings cannot use the portal at the same time - the animation is an attribute of the LEMMING, not the object.

Bidirectional - This would mean that if there are a pair of linked portals, A and B, a lemming could enter Portal A to come out of Portal B, and could also enter Portal B to come out of Portal A.

One-way - This would mean that if there are a pair of linked portals, A and B, a lemming could only enter Portal A to come out of Portal B; and could not go back through Portal B to come out at Portal A again.


Also, to be clear about a point raised earlier in the topic:

* Two-way portalling is problematic because we obviously don't want a portalled lemming to warp back on the next frame. If it's possible to get around this problem, then I think it's a good idea -- if the portal is essentially a "wormhole" connecting parts of the level that are not next to each other in normal space, then it would make sense for it to be two-way.

This can absolutely be dealt with - NeoLemmix already has to deal with this situation for splitters.

A thought on the Neutralizer specifically: effectively, it could be argued that it's a soft trap - it doesn't KILL the lemming, you can still save it, but if you can avoid it you probably don't want your lemmings being neutralized. With that in mind, would it count as a trap when interacting with a Disarmer?

This could be argued for the single-use or triggered-infinite variants, maybe. Not so much for the infinite-constant one, I feel.

Also to be clear, triggered-infinite is ruled out at this point, as is the zombifier.

- Should a single object be able to grant multiple skills? (How often do situations arise where simply placing two objects - one for each skill - next to each other, wouldn't be suitable?)

After further thought on this one, I'm going to go with "only one skill".

- What should occur when a Floater encounters a Glider object, or vice versa? Keep the existing skill, or lose it and gain the new one?

Thinking about this - trying to assign a Floater to a Glider doesn't replace, it just can't be done. Much like assigning a Climber to an already-Climber can't be done, for example. I'd expect a one-shot or triggered assigner to ignore a lemming that already has the exact skill in question; and I'd argue consistency would suggest the same should happen for the Floater/Glider scenario.

- Should they be single-use or infinite-use?
- If infinite-use, should they be one-at-a-time (like traps) or constant (like fire / water / exits)?

These are still open questions. However - the one thing here is that I want the answer to these to be the same for both assigner and remover. However, it's still an open question whether the remover is skill-specific or remove-all.

Further to this, after re-reading over the three topics (neutral equivalent included), I've decided to rule out triggered one-at-a-time.

Implemented in commit 8cc7fc2, with a further fix in 985b5cd.

Leaving this open because:
a) not yet properly tested
b) still need to add editor support
c) a better idea for an icon could still come up