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.

Just tried it on NL, and yeah, it's really not all that difficult to achieve there - though it would be considerably harder on Genesis, for sure, as the majority of the diggers need to be frame-precise AND you can't rely on the "place cursor at exactly the right position" trick either as the digger will be under the cursor at the position that would otherwise work.

Quote from: Guigui on May 19, 2025, 11:20:16 PMOh I did not notice I Am A.T. had a talisman in Redux.
Now that I saw the actual level again, I am not that confident : forgot the pit near the end of the wall, and you just dont have enough digger to dig-cancel through the whole wall pixel by pixel...
Execution must be hard for sure.

I would assume you...

Spoiler

dig-cancel to make a staircase they can ascend (without getting anywhere near the pit)?

Quote from: Simon on May 18, 2025, 11:20:32 PMYou can queue shimmier to a climber. What other skills can you queue? Is the queue part of the physics? If it's not, we should be able design it so that it doesn't feel like a bug, yet complies with the NL physics.

Any skill can be queued, and it is not part of the physics. If the user attempts to assign a skill that is not currently a valid assignment to the lemming in question, it gets queued for roughly half an in-game second, and if the lemming becomes able to be assigned the skill during that time, it gets assigned at this point. As far as physics (and replay data) are concerned, the assignment didn't happen until the frame on which it was a valid assignment.

Shimmiers are somewhat unique in that some transitions from other states (specifically, Climber and Slider) to Shimmier only have a one-frame window to be assigned. My understanding is that Nepster implemented them this way on the basis that this queueing ability would make these assignments non-problematic, even in real-time play.