Consider the actual visual representations of objects, i.e. how they are presented to the player, not how the game sees them internally.

Water and continuous traps such as fire don't represent an inconsistency regardless of how direct drop is handled. For example, suppose you enter a fire: it doesn't matter if you walked into it, fell into it, flew, whatever: by occupying the space you are getting completely roasted. The experience is probably not going to be particularly good for your health, to say the least. If you fall into water, you are in the water now; falling will not cause you to pass through it.

Many triggered traps, on the other hand, involve an object that doesn't really pose an active threat to your health until the trigger has been activated. Most of these traps appear to be something along the lines of pressure plates, but you could imagine a variety of mechanisms. A pressure plate would only activate if you stepped on it. A tripwire, on the other hand, can be triggered by passing through the space. While the game implements them all the same, it wouldn't necessarily be unreasonable for individual traps to have different rules about whether fallers should be able to trigger them. On the other hand, it's not really needed, because the game is consistent about how different types of traps are placed. Most of them are always placed on the ground, but for example the pillar spike trap is always attached to a wall (and thus its trigger area is mid-air). Because of this, allowing them to work mid-air is quite convenient: it means the spike traps can share code with the other traps, and since the other traps are going to be on the ground anyway, it doesn't really meaningfully change their behavior (if they fail to trigger the trap mid-air, then they just immediately trigger it when they land). Similarly, direct drop into a trap generally doesn't change things much; the lemming is dead either way and the only real difference is what goes on the death certificate. While you could certainly make a level relying on the behavior (a triggered trap can only kill one lemming at a time and splatters are already doomed, thus a trap triggered by a splatter is effectively wasting its time), none of the official levels do (nor do they really contain direct drops onto traps at all, unless you intentionally go out of your way to make it happen). Arguably for most traps the most logical behavior would be for a mix of the two where the lemming splats but the trap is still triggered regardless.

The visual design of exits is basically a building with stairs, and in official levels. I mean, judging from the door, it looks like there's a portal too, but it looks more like the sort of portal you would have to walk into, rather than one that sucks you in. The animations and boing sound effect also seem to communicate more that the Lemmings actively leap into the exit, rather than passively get sucked in. Thus, this suggests direct drop is probably an oversight rather than an intended feature: because the exit doesn't appear to be sucking them in, how exactly would it break a fall?

I understand your desire for the singular option, but there are benefits to keeping them separate (and, identified by strings rather than numbers). My instinct on this one is, let's keep it as it is at least for now.

I agree with Simon here regarding the use of an enum. There *should* always be one and exactly one of the options active, but an enum will consistently enforce it across the entire codebase. Even if everything's correct now, this has maintenance benefits long-term. It shows that it's intended that exactly one of the options is true, and you won't have to worry about any bad behavior as a result of attempting to run multiple options at once (sure, maybe setting them all to true doesn't misbehave for now... until some other change happens and it no longer gets handled gracefully but nobody checked).

You can still identify them with strings in the options file, and the enum values have names so it's not like you need to remember that "OptionA" is 0, "OptionB" is 1... keeping track of that is the compiler's responsibility.

Regarding forks, if namida was okay with it my suggestion would be to keep the NL name (perhaps with a prefix/suffix) until breaking changes are made. If it's just an enhanced version of NeoLemmix but the physics and file formats are the same, so content made for one will work perfectly in the other, then I think a new name would just introduce confusion; conversely, if it's merely compatible with NL content, but its content is not compatible with NL, then calling it NL would be confusing.

I agree that the arrow version is better, as the animation is more of an enhancement to the visuals rather than outright required to figure out what you're looking at. I don't like to go *too* far with the picture puzzle mentality but it's much more convenient the fewer things I need to go send a lemming to test (particularly if just figuring out how to get a lemming over to the thing I want to test in the first place is part of the puzzle!) And when I'm inspecting the level I will generally have the game paused so I don't have distractions from things happening elsewhere.

Though I wonder if it might be a good idea to have an option to continue playing idle animations while the game is paused (triggered animations, such as those for triggered traps, would be a bad idea since it would make it less clear when the trap is active again). Maybe that's a dumb idea, idk. Just throwing it out there, really.

Ruler Snap like in Lix is probably the best solution.

Rather than making the end multi-colored, I think a better solution (although it would require changes to the code) would be to make the colors change. It wouldn't be entirely new functionality at least, since that visual effect is used in clear physics mode, just not with the splat ruler.

Out of curiosity what is the applicable benefit to allowing larger resolutions? I assume something related to making the game display on multiple monitors at once? (I know there's a few games that support that but I've never looked into how exactly that works).

I'm assuming there's a reason that the solution isn't "Just don't let the user do that."

I wasn't able to reproduce at resolution 1920x1080, which matches my monitor.

I've been compiling Lix from source as it makes updates very easy (git pull then dub build -b=release), so I went ahead and checked what version of the DLLs I have on my system, which appear to be version 5.2.6. I don't remember exactly where I got them. Lix version is 0.10.18.

Lix doesn't appear to show the currently installed version of Allegro. It might be useful to insert that somewhere, maybe under where the Lix version is currently shown? https://liballeg.org/a5docs/trunk/system.html#al_get_allegro_version

This is because long-term users learned to tolerate the flaw. Tolerating is a nasty solution.

In fairness I imagine many long-time users never thought to try copy-pasting something in there. It's something that I would expect to work, but also something I probably wouldn't think to try until I have a reason I want to do it. Usually password fields are the most likely ones for me to paste into (as memorizing tons of unique secure passwords is basically impossible), but Lix doesn't have those. In most other situations it's easier to retype than to go grab the appropriate clipboard contents to be able to paste.