SMF is now upgraded to 2.1.6.

Please note, as a side effect of fixing a minor (but nonetheless, present) security issue I noticed during the upgrade, all account activation / reset password links in emails sent prior to the upgrade will now be invalid, and all users will have been signed out.

Please report any other issues you notice.

We had an incident the other day involving a large (by our standards) wave of spambots.

As a temporary measure to combat this, I have changed the question when registering an account to one where the answer cannot be found in public - instead, it's basically a "password" that must be obtained from site staff (possibly via another member). To be clear - this is purely an anti-spambot measure, and the password will pretty much be given to anyone as long as we're sure they're a human and not a spambot. When the site prompts people for this, it will advise them to ask on either the Lemmings Forums Discord or the #lix IRC channel.

Staff members who are not already aware of the password can find it in the topic about the spam wave on the staff board. If a non-staff member needs the password for the sake of passing on to a friend who is trying to register, you are welcome to ask any of us for it - again, it's purely a spambot filter, and I have no issue with humans sharing it with each other. However, please do NOT post it publicly. If sharing it with someone, do so via a private communications channel (eg. DMs on a social media site, or email).

On a side note, it was brought to my attention that users with no posts were being hit with this prompt every time they tried to send a PM. This should no longer be happening; nor should new users have to answer the question a second time when making their first post. It should now appear once during registration, and never again after that. (However, the wording for SMF's setting regarding this was a bit ambiguous, and it may in fact have the opposite result - now making everyone, except mods / admins, answer the question every time they post, even if they've posted before. My testing suggests this is not the case, and that it's working as intended, but please let me know if this is not the case.)

I will be looking into a better means of dealing with this - there are a few good open-source anti-spam solutions out there that go way beyond just a security question (viable but annoying) or a captcha (basically useless these days), and I'd be surprised if SMF doesn't have plugins to integrate with them. The password-style security question is just a temporary measure until that happens.

I'm no longer actively working on Loap. At some point I'll probably make a small fix for the music looping bug that showed up in newer versions, but aside from that there's no plans for further work simply due to the low interest in it. With that being said, it's open source (MIT licence), so anyone is free to take over if they wish.

Loap doesn't intend to be a 1:1 accurate replication of the DOS game. This becomes more noticable with custom levels, where some of my custom ones actually needed modifications to ensure they worked properly under Loap. You're likely correct that there's a one-frame (or so) window where the climber is considered to be inside the block above him, but Loap handles this differently (either by not having such a window at all, or by having a different timing of when the bomber takes effect so that it can't do so within that window).

You can definitely increase the resolution of the skybox... if you have a higher resolution version of those images to use there. (Maybe a rip from the Playstation version? I believe it has higher-res skyboxes compared to DOS, which is where these were ripped from.) No special steps needed, just replace the existing image with the higher-res one and it should just work.

Well, guess we'll be upgrading to 2.1.6 then.

A new update to SMF has been released, so the forums will need to be updated to it at some point. As always, due to the customizations and the use of addons (some of which have had to be installed manually and modified to be 2.1 compatible), it's not going to be as straightforward as just running the auto-update; but I'll look at sorting this update in the near future.

At this time I have no expected dates or other further details to share.

Quote from: Silken Healer on June 11, 2025, 06:31:08 PMHmmm 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?

Adding it as a comment in the replay data itself (and perhaps even the time itself could be added there, as filenames can easily end up changed - of course so can the content of files, but modifying the timestamp in a file would be a specific intentional act, whereas doing so in a filename could just be a "I don't care if it's there or not" thing) seems much more reasonable than adding it to the filename, if there is a desire to tag replays with their creation time.

This feels overkill tbh. I don't think it's really necessary to account for timezones at all; presumably, the main intent behind putting the time in the filename isn't to actually communicate the time of recording, but simply as an easy way to ensure unique filenames for the replays.

If there really was a desire to account for timezones, rather than making the filename longer, I'd suggest using UTC instead of local time when generating the filenames.

To the users who previously raised concerns about not receiving all site emails: Has this remained the case even after the change from SendGrid to an internal service?

SendGrid, the service used to send emails from the site, is discontinuing their free plan in the near future.

Rather than just find a substitute (or use their paid service), I've opted to go for a self-hosted solution here. I've tested this and all appears to be working, however please note that as a result of this change, emails from the site may have a higher risk of going to Spam and/or being flagged as "unusual" for a little while.

You probably need to install some WINE equivalent of the .NET Framework as well. I'm not sure off-hand how to go about that.

I'm thinking along the following lines. Note that this is just a proposal at this stage, not confirmed rules. I'll probably also tidy up the wording a bit before making anything official, so while input on the wording is welcome too, I'd like y'all to focus primarily on the underlying intent.

General
- Staff discretion is final. The flipside here is that in borderline cases, staff should be lenient (ie: just edit in NSFW warnings and give the user a heads up; rather than issuing forum warnings or bans).
- Putting an NSFW warning in a topic title does not exempt posts in that topic from having to put NSFW warnings on applicable content they contain. (This is because there can be ways to end up in the topic without noticing the title.)
- An NSFW warning for content embedded inline in a post should be done by wrapping the content in a Spoiler tag. Make sure the spoiler tag header notes that the tag is hiding NSFW content.
- An NSFW warning for content in an attachment should be done by including NSFW near the start or end of the filename. If the file is a type that would usually show a preview (eg. images), please also put it inside a ZIP file (or similar) so that no preview is shown.
- An NSFW warning for an external link should be done by clearly putting "NSFW" before or after the link (on the same line; or the warning and the link (with nothing else) on two consecutive lines).
- Users are not expected to go to extreme lengths to verify that external links, don't in turn contain links to other NSFW material or never show NSFW ads etc. The users following these links need to be mindful of that external sites are usually outside the control of both this site, and of the user linking to the external site.
- To avoid doubt, it is not against the rules to put NSFW warnings on content that you personally believe counts as NSFW even if it does not count as NSFW by the site's standards.

The rules - Pornographic content
- Realistic pornographic content is prohibited under all circumstances, whether or not it is actually real.
- Unrealistic pornographic content (eg. drawings, non-lifelike CGI, clay models, etc) that is still clearly depicting that kind of subject matter, must have a purpose other than just being pornography (such as comedy or educational value) and must be hidden behind an NSFW warning.
- Things that vaguely resemble pornographic content (eg. a rock formation that kinda looks like a penis) does not need any warnings, even if it was intentionally made to look that way.

The rules - Gorey content
- Gorey content is only outright prohibited in extreme circumstances, in particular, where the content relates to real-world violence and is intended (either by the poster, or by the original creators of the content) to glorify or justify said violence.
- Realistic content that is more than mildly gorey (beyond the kinds of things you'd see in everyday injuries like minor cuts / scrapes / bruises) must be hidden behind an NSFW warning.
- Unrealistic content that is severely gorey (deep wounds, excessive blood, etc) must be hidden behind an NSFW warning.
- No warning is needed for mild stuff (such as the cartoonish gore in many Lemmings styles), or unrealistic moderate stuff.

The rules - Explicit language
- To avoid doubt, we continue to not give a fuck about explicit language (as long as it isn't being used to attack other users or engage in hate speech). You are welcome to hide explicit language behind NSFW warnings if you wish to do so, but it is not in any way required.

That's fine; you know now.

There may occasionally be cases where the styles aren't available from the in-game downloader, these would usually be provided by the level pack's creator alongside their pack (either as a seperate download or just bundled with the levels). There's a few reasons this can happen:
- The style isn't considered appropriate for inclusion in NL's style downloads for any reason (eg. contents aren't useable in levels without significant workarounds; abundance of pieces that are excessively large even by "special graphics level" standards; or objectionable content)
- The style's creator hasn't requested for it to be added to the style downloads (which may either be because they don't want to, or they're unaware of how to do so - I do not proactively seek out styles to add)
- It's only just been released, and hasn't been added to the style downloads yet

If you enable online features, you can also download them in NL itself, and it should prompt you to do so as required. These are disabled by default because some users felt uncomfortable with NL connecting to the internet for any purpose whatsoever. (To avoid doubt, this was on the basis of their general principles, not any specific concern about NL.)

Quote from: WillLem on May 20, 2025, 09:13:08 PMPlaying without Classic Mode is the norm on the Forums and you'll likely switch to that eventually (as we all do!),

More crucially: Most custom levels are generally designed with the assumption that you're not using classic mode, and are (at least to some extent) taking advantage of the fine control features (eg. framestepping, rewinding) that exist on modern engines. The official levels are of course perfectly playable under classic mode conditions, but some custom levels might be a bit of a struggle.

Quote from: WillLem on May 20, 2025, 08:45:24 PMThere may be a way to see whether the queue frame is >= 1, and if so then play a different sound as opposed to the regular fail sound (assuming we figure out a way to "know" the reason for the failed assignment).

From memory, what I recalled was that the assignment always gets queued as long as the player actually has at least 1 of the skill they're trying to assign.

I wasn't 100% sure on this, so I checked the code and did some testing. Note that this is based on 12.14.0, not NLCE or SLX. It turns out there are three criteria - and "having at least 1 of the skill" is not one of them, which can be confirmed by trying to assign a skill you have none of, then gaining one via a pickup skill during the queue timeframe. The criteria are:
- There's actually a lemming to try and assign to (ie: the assignment isn't failing because there's no lemming under the cursor). Common sense and I don't think NL would get as far as even trying to do this, but this is explicitly checked again when queueing.
- The skill must not be a permanent skill
- The lemming must not be neutral or zombie

Otherwise, the skill will be queued. I would actually argue that, with deneutralizers existing (plus the pickup skill edge case being a thing), the permanent skill and neutral cases should be allowed to queue too; keeping only the "lemming doesn't exist" or "lemming is a zombie" cases. On the other hand, we can also add the cases of "lemming has been removed" (yes, this is actually not checked currently - though of course, the queued assignment will always expire without happening in such a case, if you can even find a way to queue such an assignment in the first place), "lemming is exiting", "lemming is burning or splatting", and "lemming is drowning AND the skill is not Swimmer".

Note that "skill is a permanent skill the lemming already has" (or is blocked due to floater/glider exclusivity) is a borderline case as to whether we can exclude it or not. Technically, that assignment CAN become valid, due to the skill removers. However, unless the remover's trigger area is only 1px wide, the assignment would just immediately get eaten again by the remover, and thus be wasted. But technically, the skill does get assigned successfully. Nonetheless, I think I'd lean towards the practical side here, and say that this case could be blocked from queueing too.

All other cases, you'd need to actually simulate ahead (and keep in mind, simulations are not 100% accurate, especially when it comes to interactions between multiple lemmings or the effects of their ongoing skills, not to mention it can't predict other assignments the player might make to other lemmings during that time) in order to determine if the queued assignment will succeed or not.

I think ultimately - a solution needs to be found that relies only on what can be determined at the time the player attempts to assign the skill, and not make assumptions either way about what happens afterwards.

Keeping in mind both this restriction, and that queueing is basically universal, perhaps the approach to take is to visually indicate that the lemming has a queued skill in some way (whether it's showing the specific skill, or just a general "queued skill" indicator that could be eg. an icon displayed above the lemming's head similar to the countdown digits / highlight icon). We then have three sounds - "success", "queued", and "failed". Failed would play if either (a) one of the conditions to not even queue the assignment is met, or (b) when the queue duration runs out, if the skill did not successfully assign at any point during it. Otherwise, if the assignment doesn't succeed immediately, the queued sound is played. Maybe it's also worth considering different sounds for immediate success vs queued success.

This does raise a difficulty with the situation-specific fail sounds. If the fail sound is only played at the end of the queue duration, what if the fail reason was different on different frames? Does the frame you tried to assign it on take priority, or the one the queue expired on; or is it a matter of certain reasons having higher priority and the sound is based on the highest-priority one encountered? Or perhaps which one occurred on the most frames during the queue time? I'm not really sure what the right answer is here - perhaps if anything it's a good reason to just rule out the situation-specific sounds altogether.