If this helps it get added, I've created a version of :geek: with a more typical, neutral glasses colour.

Quote from: Baldem1990 on November 29, 2025, 03:12:10 AMMicrosoft Windows 95: archive.org/details/lemmings-disk

This one can't be played in-browser.

Quote from: Simon on December 06, 2025, 03:23:21 PMI have no preference between WillLem's santa and Silken's santa. Among these two, I'll put what others want.

I always appreciate in emojis when emojis are based on simple modifications of another emoji. For example on Twemoji, this emoji:


Is actually just this emoji:


With teeth and glasses added on.

I always thought that was a nice touch, so I wanted to make the Santa emoji be based off of the classical Lemming . I don't see the need to create a new eyes expression for it. Actually I think the eyes might be from ?

---

Quote from: Simon on December 06, 2025, 03:23:21 PMIn posts, both santas will look the same to me anyway. On this principle alone, we can already rework or toss 10-20 existing smileys.

Good idea for both the Santa and for the other emojis. I would feel a bit sad losing some emojis, and I always think it's better to avoid changing hotlinked things as much on principle just in case. As you say, there is a lot of overlap though, so maybe it's worth it.

---

If WillLem can send the santa hat on it's own prehaps we can make more Santa emojis e.g. Santa .

---

Quote from: Simon on December 06, 2025, 02:43:52 PMI make no statement yet about all the other backlogged ideas here.

In hindsight, after thinking on it more, I'm really not sure about :geek:. Orange glasses really don't convey geek to me. As for :shrug: I'm not sure if we should have both the animated and non-animated, one of them, or neither. I guess we already have animated emojis with non-animated counterparts e.g. , , , and the animation does convey shrugging more, so that would make sense. So if we use that precedent to chop down the decisions I'd probably say an animated shrug is fine.

Before you add it I made this alternate version, what does everyone else think?

I was just about to mention this from your post in the "[RELEASE][2.4 UPDATE] RetroLemmini - A brand new version of Lemmini for 2025!" thread before you said so yourself. If I may say so, I really like this one. It's probably the best one out of :shrug: :geek: and :xmas:.

First off, in a PM Namida sent to me I was told me comments without counting up the number are fine, so I'm not disobeying Flopsy's advice that he gave to me.

For me, while I ultimately can't speak for everyone else, nor for Gronkling when he started this thread, I don't believe that there has ever been a "resetting the count" function of this game. For me, I've always been under the impression that the point of the game was to count up to the next number, and that if you make a genuine mistake that's fine, mistakes don't reset the count, and that deliberately counting to the wrong number is considered disruption outside of the spirit of the game, and that everyone else in this thread also shared this common belief. Such a function has never been described in the OP, and I've never seen anyone else deliberately count to the wrong number this game, other forum games of a similar nature don't typically have this reset function, and everyone else from my memory of the deleted posts has either ignored you and carried on with thread or explicitly stated that they don't want you to "reset the count".

Unless anyone else feels differently and wants to speak up, but I'm 99% sure no one does, I think it's safe to say that there hasn't been a "resetting the count" function of this game, and that everyone else agrees with me and thought the rules I outlined in this post are common knowledge, and in future if anyone counts to the wrong number, we should just count up from the last correct number. So whoever wants to go next your number is 266.

Best wishes for the health of Cookie.

I don't really think it matters tbh, I think everyone can internalize the spirit of what you mean, even if it's one of those things that ends up being finnicky creating an air-tight rule for

Edit 2025-06-17 10 PM BST: Ohhh wait, I thought you were saying if someone live-solves a part of the puzzle in there head, then they might interpret the rule to mean they can't say it, I misinterpreted that massively.
Edit 2025-06-17 10:52 PM BST: I don't think there's anything wrong with that tbh, it's just that B is doing it from the frame of mind of helping solve together, and A would already know the solution before.

Archiving the videos locally to this forum just in case

Quote from: Simon on June 17, 2025, 09:11:33 PMThis rule forbids hints that other people in the same chat are allowed to write after they live-solve a part of the puzzle in their head.

How will they know if the part they solved is used in the final solution correctly unless they solved the whole level, or they solved the final part?

Anyway, for Miners' Haven, I actually solved it all and I still interpreted the rule as fine to tell you (though you didn't end up needing my help).

I think you're on the right lines about the rule interpretation should be on the part of the interpretation of the viewer and largely unenforced.

I think you can simulate a multi-monitor setup in virtual machines if you don't personally use a multi-monitor setup already and it would cost more time/money then is worth to get one to test this bug e.g. if you don't just have a spare TV you can plug in to your computer or something.

Quote from: Simon on June 12, 2025, 02:44:08 AMWhat problem are you trying to solve?

No problem, I just thought it might be cool

Quote from: Simon on June 12, 2025, 02:44:08 AMDo you mean the time zone name (ET), the time zone name with DST information (EST/EDT), or the UTC offset (−05:00/−04:00)?

Probably UTC offset would be the most clear out of those

Quote from: Simon on June 12, 2025, 02:44:08 AMAnd of what? Of when Lix saved the replay? Or of the level's built datetime? The levels' built datetimes carry no time zone information in the levels.

When Lix saved the replay

Hmmm yeah maybe that's fair; I wouldn't want the time zones to be normalized to UTC because then that would create confusion about timestamps before this potential update was added; I'd rather just keep things they way they are then that. Perhaps the time timezone could instead be added in someway to the markup of the replay files themselves instead?

Recently, I was thinking, perhaps Lix should include the time zone in the replay filename.