Updated to here.

@92Dexter11: I have fixed it myself this time, but please note that the correct names for the terrain/object/etc folders are all lowercase. You had them instead starting with an uppercase letter. This doesn't matter on Windows, but might make your style not work correctly for people playing on Linux or Mac via "emulators" (and even more so, could be a concern for future ports/clones or associated tools that can natively run on those OSes).

I have also in general rewritten the topic's rules. Nothing is actually new (aside from clarifying the above regarding names); they've just been rewritten to (hopefully) be more clear - in particular, to be clearer on what exactly the stance on AI is (and to clarify that the prohibition on "image gallery" type styles would still apply even if the images weren't AI generated but otherwise ticked all the same boxes that made those styles an issue) - as well as putting a few unwritten but widely-abided-by rules into writing.

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.

No, GigaLem is quite right in this case. Fandom have a bad reputation for a reason.

GigaLem is indeed very prone to jumping on bandwagons and getting fixated on things like this in general, sure, but he's actually right about this one.

It's important to keep in mind that always going against the majority opinion isn't any smarter than always going with it (and is just as easy to end up doing without realising it). You're still blindly following others, just in a different way.

It's just taken offline at this stage, so yeah, I can restore it. Remind me another time and I'll get it out for you.

Okay, yeah, it definitely looks like this is one of those ideas that people liked the idea of but weren't too keen on actually doing, so let's take this down now...

It looks like I needed to specifically enable it as a permission for regular users too. This is now done.

Quote from: Silken Healer on March 29, 2025, 06:22:31 PMThanks . I now see draft-related options in my settings and an empty "My Drafts" page if I click on my name, but I still don't see anywhere I can save a draft .

I get a Save Draft button next to Preview and Post when I'm making a topic / reply (including the quick reply). Does that not show up for you's?

Quote from: Guigui on March 28, 2025, 05:50:37 PM* went to fullscreen mode (despite Wine warning against it).

I should note: It's not WINE warning against this, but NL itself. Not sure if it's still the case nowdays, but at one point NL's fullscreen mode didn't play nicely with some Linux desktop managers (including Ubuntu's default one at the time), so if NL detects that it's running in WINE, it shows a warning message (and whereas it defaults to fullscreen on Windows if there's no existing configuration, it defaults to windowed when it detects WINE).

Yes, it is, and it should now be enabled.

Limited benefit, but also fairly easy to implement and does no harm by existing.

Personally, I'd say wait and see if any active users want this feature.

I think he just wants to be able to set the grid size independently for the X and Y axes, instead of having to be the same for both? (Eg. Make it possible to have pieces snap to a grid that's, say, 24x16, instead of having to stick with either 16x16 or 24x24 or find some workaround like setting it to a common factor).

Quote from: Simon on March 03, 2025, 10:37:15 PMnamida, what exactly do you fear for climbers? I imagine that tan x will keep the climber foot inside the wall (what I consider strange, but necessary for NL compatibility)? All collisions will happen a pixel higher, against trigger rectangles that also moved higher. I don't see a problem. What is it?

-- Simon

Imagine a flamethrower object placed such that the trigger area extends to cover the last pixel outside the wall, but does not go into the wall. With the "pin inside the wall" setup, the climber passes by this flamethrower safely. With the pin outside the wall, he gets burninated.

All other cases (except Sliders, which are basically just Climbers that move downwards instead of upwards) can be addressed simply with a corresponding 1px rise in the trigger area heights, but the climber case - where moving the pin outside the wall also involves horizontal movement - is not as straightforward, and would appear to require either level adjustments or a special case. (In general - I've found that "pin inside terrain", although perhaps counterintuitive from a visual point of view, just seems to work better from a programming point of view in general - even in non-Lemmings games. I took a similar approach in the Commander Keen fangame I made a while back.)