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.

If the requirement is for it to be divisible by 2, why is the maximum 0xF0 and not 0xFE?

Hi all,

We recently had an incident where a newcomer posted fan art that pushed the lines in regards to NSFW content - it featured a "drunkard" lemming who among other things was not wearing pants (but the genitals were censored with a black box), who also had a nose that closely resembled genitalia (this was not censored in any way).

Simon initially removed this image. After some discussion between myself and him, the decision was reached to restore it, but to put the image inside a ZIP file so that no preview is shown, and put a clear "not safe for work" warning in the filename. This was primarily due to my input; my reasoning being that we have shared content of a similar level between existing members before (for example, drawings that resemble - or occasionally, just outright are - dicks, in the Jackbox topics). Simon also noted when restoring it, that the image "is edgy, but is honest fan art".

As part of this discussion, the idea also came up that we should seek feedback from the wider userbase as to how to handle such material going forward.

I do want to clear up some things right here first: There's definitely going to be limits as to what we allow. Don't expect the site to ever have a "share your favorite porn videos" topic or anything like that - Lemmings Forums absolutely is not a porn site. However, when it comes to content where the primary intent is artistic and/or comedic in nature, rather than sexual, I'm much more open to - and personally, would prefer to lean on the side of - leniency, subject to such content being hidden behind NSFW warnings (ie: no image previews for attachments, so put them in a ZIP or similar; or if they're embedded, then put them inside spoiler tags).

How do other users feel on this subject? While higher priority will be given to the thoughts of long-time members, input from newer users will be considered as well.

Okay, I'm a bit unclear about what's going on here. Is DoubleU actually the fan who's meant to be taking over the site? Some of what they messaged me made me think they were just someone who was keen for such a hosting setup to happen in general, rather than actually the person who would be taking over the site.

I can't get mellowa's 4-builder solution for Mayhem 2 to work in Lemmix either. There appears to be some discrepancy between Lemmix and Golems around the lemmings being able to exit in the exact setup here, and some investigation is needed into which one is accurate to DOS (probably with a simpler setup than Mayhem 2).

However, based on it, I did manage to get 5 builders, which is still an improvement over the current record. Most of the credit goes to mellowa for this one; all I did was slightly adapt the not-working-in-Lemmix 4 builder solution into a working 5 builder one.

You don't have to rebuild the levels. Just double-check that they're still solvable - which as WillLem says, can be done very quickly by running a mass replay check, assuming that you've kept a collection of solution replays for your level (and if not, why not?).

Hold the highlight lemming key and left-click the lemming you want to highlight, if it's assigned to a keyboard key.

Quote from: WillLem on April 16, 2025, 12:09:53 AMMIDI stands for "Musical Instrument Digital Interface" and isn't so much an audio format as it is a set of digital instructions to the audio for what it should do.

It's also a file format as well, which is what Silken is referring to. However - the contents of such a file are indeed along the lines you describe.

To explain this in more depth and contrast it to a WAV / OGG / etc file, in a way that hopefully Silken (and any people with less tech and/or audio knowledge who are reading out of interest) can get:

A typical audio file (like a WAV or OGG) file is made up of "samples". Without getting into too much technical detail about them, you can think of a sample as being the audio equivalent to a pixel - much like how a pixel tells a screen "this is the color that should be at this particular point of an image", a sample tells a speaker "this is the level of sound that should be at this particular time in the sound clip". By extension, you can think of a WAV or OGG etc file as being the audio equivalent of a BMP / PNG / etc file. Most commonly audio files tend to have either 44100 or 48000 samples per second per speaker (ie: if it's a stereo file, there'll be this many samples for the left speaker + this many for the right speaker, per channel). The differences between various formats come down to (a) different header structure and contents; (b) different methods of encoding the samples (in particular, some use integer values ranging from (usually) -32768 to +32767; others use decimal values ranging from -1 to 1); and (c) compression (similar to how BMP is mostly just uncompressed raw pixel data + a header, WAV also stores the audio uncompressed; OGG and MP3 are lossy compression, similar to JPG; FLAC is an example of lossless compression, similar to PNG).

Because of this - if a program / game wants to play a WAV or OGG etc file, it simply needs get the sample data from it (this may involve a decompression step for some formats) and then play that sample data as-is. Perhaps at most it needs to convert between integer and decimal representations, if the audio library it's using expects one, but the format loading code gives the other - this is a simple maths exercise, with almost zero knowledge of the internal workings of audio needed.

MIDI files (and for that matter, module formats like MOD, IT, etc) are more comparable to SVG. I'm not sure how familiar you are with SVG, but basically - SVG files don't contain specific pixel data, instead, they contain instructions like "draw a line from (0, 0) to (120, 120)" that are used to create the image. Any app wanting to render this image would need to be able to actually read and process these instructions - generally speaking, it would be expected they can handle all standard instructions that might be found in an SVG file. MIDI is similar - it doesn't contain actual sample data; it just contains instructions like "play this note for this length of time at this point in the track". It's up to the app trying to play it - or the underlying OS - to generate the actual sample data from these instructions. Module formats are actually kind of "inbetween", in that they do generally contain actual audio clips but these are not the entire song, rather, the audio clips are of single notes, and the module file then contains instructions on when/how to play those notes to produce the overall song. MIDI doesn't even have this - it relies on the app (or the underlying OS) providing the clips that are used to generate the sound. This is also why, especially on older PCs (it's less the case on newer ones), the same MIDI file can sound different on two different PCs - because the two PCs are using a different library of instrument sounds to generate the actual audio.

Obviously, a key difference here is that an image file will be 2D (two axes: horizontal and vertical), and generally have a few thousand pixels on each axis at most (so a few million for the entire image). Whereas an audio file only has a single dimension (time), but will generally have tens of thousands of samples per second. (This is why audio files in formats that contain actual sample data, especially uncompressed formats like WAV, get so big so quickly.)

This is why MIDI often isn't supported in apps that have widespread support for various sound formats - even including ones that may support module formats.

And how much of that old music fits with Lix's philosophy of avoiding copyrighted resources?

Pretty much anything used with Lix (outside of customizations to your personal setup, which isn't going to be a particularly high priority) is going to need to be public domain or at least something like Creative Commons licenced. So for the most part, that's going to mean resources specifically made for Lix. I would think it's safe to assume anyone who's creating quality original music can probably figure out how to get it from MIDI to a compatible format - in the unlikely event they're even using MIDI, rather than either a tracker app of some kind or else a full-on production environment like FL Studio that can just directly export an OGG file.

When that is considered, it doesn't really make sense to put a lot of effort into supporting it. Hence - if there were a low-effort way to support it (ie: if Allegro, a library already very central to Lix's code - you can sort of think of it as being what Lix uses instead of an engine like Unity or Godot etc, although there's a lot more DIY involved when working with something like Allegro compared to an engine - has native support for it, then adding support to Lix is pretty much as simple as adding .mid to the list of extensions it looks for on music files), it would happen; but if Simon has to find a seperate library just for MIDI and integrate that, or write his own code to handle MIDI, then it's not going to be worth the effort. And for what it's worth - MIDI is a much trickier format to work with in this regard than most others. To compare it to Lemmings levels; if an OGG file was a level, a MIDI file would be a list of what actions to take in the editor in order to create that level (yes, this is not a perfect analogy, don't try to take it as completely literal). So any DIY midi code is going to be a very large undertaking, and certianly an unnecessary distraction from the more important parts of Lix.