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.

You mentioned making these sounds customizable was a goal. If so, the default could be the same as the current hardcoded setup (or multiple default profiles can be offered, similar to what NL does for hotkeys).

One thing to keep in mind is that the Shimmier is somewhat unique in having situations that require frame-perfect assignments. Nepster designed it this way (I did the same with eg. the Slider for consistency); queueing was already a thing at the time, so I believe Nepster felt it was acceptable to require the frame-perfect assignments precisely because queueing gave a generous window to "assign" it anyway.

For SLX, I would even go as far as suggesting changing this behavior - allow Climber->Shimmier whenever the climber is less than one animation cycle away from hitting his head (internally: there is at least one solid pixel somewhere between (lemming Y - head check offset - distance climber ascends in one animation cycle), and (distance climber ascends in one animation cycle - 1) below that). Slider->Shimmier is trickier, but perhaps during the last few frames, or alternatively, introduce a "dangler" state which it can be assigned during. Obviously such a change is out of the question for NLCE.

Quote from: WillLem on May 16, 2025, 09:03:51 PMThe problem would then be determining why the assignment has failed code-side: this is not trivial. I'd probably need to see significant community support for the idea before embarking on it. There's already plenty to be getting on with CE-wise so it'd be a fairly low priority at present.

It's not trivial, but I don't think it's quite as hard as you're thinking. From memory: All attempts to assign skills go through functions that return either True or False to indicate if the assignment passed or failed. So, the way I'd approach this is - instead of returning a Boolean, make these functions return an enum, with values for the various failure types (and one for success, of course). You could also use integers and constants, but an enum is a bit more bug-resistant, especially if for whatever reason you want to change the order of the possible values later.

I'd generally approach a change like this by first making the new code use the Enum and return the correct values of it (so, I'd replace all cases of "Result := false" in the relevant functions with the specific Enum value rather than a "generic fail"), but otherwise do exactly the same thing the old code did - essentially the Enum is just a fancy Boolean where one value means true, any other value means false. Once that works, I start writing code that actually does something with the new Enum values. Although this would change the physics code, assuming there's no bugs it won't change the actual physics (as it doesn't change what's reported as a success vs failure, it only adds more detail to the failures), so wouldn't be an NLCE-incompatible change.

This does however raise the question of how (or perhaps, if) to define the cutoff.

The first thing to come to mind is "if it's specifically intended to look like it, rather than accidentally coming off that way". However, I'd also think that many things - such as Strato's examples - that would be described as "a deliberate attempt to make it look like something accidentally resembles it", are likely to be similar in vagueness and should be handled the same way; and I'm wary of making rules based on the intent behind the content rather than the content itself. (There can be cases where doing so is necessary; I don't feel this is such a case.)

Another thought to come to mind is "would it be reasonable to use this depiction, to try and show someone what the NSFW subject matter in question looks like?" However, this is very subjective - one person might think two lumps of dirt either side of the tall narrow piece is suitable for this purpose, many others wouldn't, and it seems a bit unfair to expect people to be able to judge their content to our standards (which might even end up not consistent with each other) on this.

Of course there's the option of "duck testing" / "we know it when we see it", rather than claiming (accurately or otherwise) to have any objective rule. Of course, enforcement would have to be very, very light-handed (outside of really blatant cases) in such a case - and we have to consider whether it might lead to people unnecesserially slapping the warnings on things, thus diluting the significance of them.

This has been reported in other topics (or maybe Discord, or maybe both) in the past.

Making a topic about it, also so that I can save a record from the error log here:

Quote<username redacted>
<IP address redacted>
<session ID redacted>
https://www.lemmingsforums.net/index.php?action=pm;sa=send2
/home/lemmingsforums.net/www/public/Sources/Errors.php (Line 234)

Backtrace information

Type of error: Undefined
Error message
2: Undefined array key "attachments_limit_per_post"

The problem with this is that a queued skill may still end up failing (if the queueing expires before the skill is able to be assigned). The only way around this would be to simulate this duration ahead every time a skill is assigned - which is doable, and code to simulate ahead already exists, but it is not quite 100% accurate; in particular, simulations do not take into account other lemmings besides the one being simulated, for the most part (one exception is that blockers still affect the simulated lemming), so for example, in the case of the Climber->Shimmier transition, this may be detected as a pass because the climber reaches the ceiling within the timeframe, but the assignment ends up failing because a bomber that was about to explode (which the simulation does not account for), does so (and removes the ceiling) inbetween the shimmier being queued and the time where it would have taken effect. It would still be an improvement over status quo, but there are edge cases it would miss (and depending how it's implemented, it may end up not playing a sound at all in these cases).

For now at least, let's assume no - I think there's a certain level of vagueness at which it's not worth worrying too much about. We'll see where discussion goes from here. (You can be assured that if the decision is made that yes, one is needed, you aren't going to be penalized in any way for not retroactively having one. We'll either just ask you to add one, or add it ourselves, and that's all.)

Quote from: Silken Healer on March 29, 2025, 06:23:26 PMI'm not sure why this thread has been moved from it's original board. I thought NeoLemmix was still accepting editor suggestions.

To elaborate here: This was more a matter of that I allowed suggestions to be made, because unlike NL itself, the editor doesn't necesserially need to ever have a "final" version, so it's not a problem to have more suggestions floating out there in case someone wants to take on the project of further work to it someday... which is pretty much exactly what WillLem is doing here. Moving the topic to this board is simply his choice regarding how to organise such suggestions.