Tip for replicating L2's style: Lemmings 2's terrain is strictly grid-aligned; this is why L2_classic is not a direct port of orig_pillar: orig_pillar's tiles would not have been the right size for L2's grid, and many of them don't align nicely with any grid size, so they had to redesign them. If I'm not mistaken the smallest size piece you can place is 16x8.

---

Is disallowing Water in Rule 3 intentional, or is it an oversight (since the stated reasoning is "Anything that was not available in Lemmings 2 is not allowed")? Water is present in L2 and the Classic water tiles are not unused in L2: they appear in 9 of the 10 official Classic levels.

There are also several unused tiles and objects in the set, which I still chose to include when I put L2_Classic together (using a rip made by... I think it was Icho?), but it's probably worth clarifying if these tiles are allowed. To my knowledge they are:

Steel: steel_01, steel_02, steel_03, steel_06, steel_07 (basically, just the small 16x16 square and one variant of the tiny 16x8 rectangle is used).
Wood: wood_14 to wood_24 are unused.
Misc: gray_block, pillar_end_03, pillar_end_05, pillar_end_06
Objects: trap_01, trap_02 (plus NeoLemmix standard objects: owa_down, owa_left, owa_right, lemming, pickup, button, updraft, flag_blue, flag_green)

I don't think the forum software supports it out of the box, if at all, but I wonder if there's a way we could implement ranked choice.

To clarify, by "larger resolutions" I'm considering this any resolution that's larger than the monitor's native resolution. We certainly wouldn't want to reject a resolution that we're not 100% certain shouldn't fit.

But I suppose the "larger than the monitor" part probably isn't the actual problem. Just hazarding a guess: could excessively large resolutions just use too much e.g. VRAM and then the application doesn't know what to do?

From looking at what's been posted here, I do have a possible guess as to why Forestidia got a different behavior than Silken: from other reports we know Silken prefers hardware fullscreen, so it's possible the behavior may be dependent on it.

One thing I really appreciate about your approach to Lix is that you will look at something that people find unintuitive, and say that the fact that it's unintuitive is a problem. There's definitely a lot of people who write off those sorts of concerns as "It's working as intended." [often implying: "It's not broken or badly designed; you're just stupid."]

Also posted on Github as on one hand it seems like the most appropriate place to report bugs, but I thought it would be useful to post here too as I imagine people will be more active here than on the Github issues page.

Observed during 1/27/2024 lemforum session on central server.

A player dropped and rejoined. The other players in the lobby remained visibly readied up, but when all players were shown as ready, the game did not start. Appears there was a desync at some point. My client version is 0.10.18, compiled from source (I know I wasn't the only one affected, but I'm not sure what version everyone's client was or exactly how many players were affected; I want to say one or two people may have still been on 0.10.17).

I tried to reproduce this with a locally hosted server; the observed behavior was that a player leaving and rejoining would unready all players in the lobby. I need to do some further testing e,g. if the client crashes somehow. I don't know what version of the server is running on the central one; I'd assume it's probably up-to-date but have no way to confirm. The locally hosted one I used to test should be 0.10.18.

---

Edit Simon: Solved in Lix 0.10.19 with a client-side bugfix. This 0.10.19 and newer can still play with older 0.10s: If the game starts at all, it starts for everybody at the same time.

Since having enough slots for everyone isn't typically a problem, I usually don't commit ahead to joining and just kinda see how I'm feeling day of. I'd say the times aren't great, but they are doable but I'm not sure I can really suggest a better alternative, because the reality is we have players on multiple continents so times that are convenient for one continent often won't be convenient for other continents.

With regard to maps, I think maybe one possibility might be give weaker players a chance to feel out the maps, particularly the overall routes to the exit, before sending saboteurs to collect or destroy the honey pot, so to speak; keep the sabotaging mostly contained to stuff that's directly in the way or just between strong players when playing a new map.

Putting a bit more thought into this and reading through the older replies:

I still agree that turning should in no way be part of the interaction; it just doesn't make sense why this would be a special case where deassigners climb.

Climbers and Sliders have a mechanically similar counterpart which isn't a permanent skill: the Shimmier. It wouldn't get cancelled by this object since it's not permanent, which is technically consistent, but it does make me wonder if perhaps it *should* cancel because the skills are so closely related in function. But then why stop at cancelling Shimmiers -- why not cancel *any* skill, *including* the removal of permanents? Or, on the other hand, there's Simon's earlier suggestion of having the skill remover only remove the skill but not cancel it: so a climber would *finish* climbing the wall, but it wouldn't be able to climb again unless another climber was assigned. But -- this would cause a unique situation in which the climbing/sliding/floating/gliding/whatever state is decoupled from the status of actually having the skill. On the other hand, it's at least a simple rule.

The problem with potential turning is that it's a complicated rule: Usually, the deassigner won't turn lemmings, but in certain cases (which you need to memorize), the desassigner will cause a turn. Non-turning is a simple rule, but there's one "oh, I didn't think it would work that way but I guess that makes sense" exception you have to memorize with the shimmier ("it should cancel a shimmier too, right?" seems like a reasonable misconception even if logically, it's not a permanent so it doesn't get cancelled). If you cancel shimmiers too, then that's a different actual exception that you have to memorize. Non-cancelling (the permanent skill will finish its activity but can't be used again) or all-cancelling (including non-permanents) seems like the simplest rule.

I can't remember if it was an option in the experimental or not, and I could see the UI for it being a problem, but assuming you could find a reasonable way (maybe if you hover your mouse over it?), there's also the option of allowing arbitrary combinations of cancelled skills, which I actually think would be more interesting for puzzles than a simple deeassigner that deassigns everything (whether it affects non-permanents or not): you could imagine a puzzle where you're given multi-athletes and you have to navigate them through a maze of deassigners that requires retaining at least a few of the skills to navigate, so you have to figure out which ones you can afford to pass through.

I believe they were a replacement for Only-On-Terrain, a setting that was used in the DOS/Lemmix days which caused an object to be shown if and only if it is overlapping terrain (pixel-by-pixel). This setting could be applied to any object. But in practice, it was almost exclusively used for one-way-walls.

A few levels in the original game use it for decoration, but it's not many (and not in the DOS version). I can think of two off the top of my head, namely Fun 20 (We are now at LEMCON ONE) and Mayhem 7 (Poles Apart) (they use the same layout). I'd have to play through the Amiga version again to see if there's any others that use it, but this particular instance can be replicated using resizable water objects. In the DOS version, the setting does not render properly (specifically, the colors get messed up) when used on arbitrary objects, but it's hard to say if this is a bug or not -- the DOS version culls a lot of decorative terrain/objects anyway, and thus it's possible that they only considered one way wall objects when they designed the DOS implementation (perhaps they could make it perform better that way).
 
If I remember correctly, the Paint setting was a designation for decorative objects that are intended to be used with the Only-On-Terrain tag, with the intent being that those objects would become paint objects and then Only-On-Terrain would be culled. OWW in NL have had the behavior for a while out of the box with no need for the tag, and on other functional objects the Only-On-Terrain tag would probably be considered a bit of a troll to make use of it.