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.)

To be clear, I don't have any need for this feature myself. I'm bringing it up on behalf of discussions I've seen elsewhere online.

From what I've seen on a few Reddit etc posts, the Windows dialogs used for level select, options, replay editor, popup messages, etc don't play nicely with the Steam Deck when in game mode (rather than desktop mode), so it may be worthwhile looking into non-Windows-dialog replacements, even if they don't offer the full functionality.

Potential issue: How does a user who can't use these menus, activate this mode for the first time? (Perhaps try to autodetect Steam Deck, and enable the option by default? It isn't the end of the world if it gets disabled again by mistake - the user can always switch to desktop mode to change back.)

It is likely this could be tested using a handheld device running Bazzite (or something that has the same limitations as a handheld, ie: has a controller and touchscreen, but no keyboard or mouse), as that's very similar to Steam OS.

Quote from: ∫tan x dx on March 03, 2025, 03:46:36 PMIf we switch to using the foot pixel to determine movement and collisions, then there will have to be extra checks to see if the pixel beneath the foot is within a hitbox. Fundamentally, there is no real difference between this and just using the anchor pixel. Changing it would also potentially lead to messier code.

Alternatively, you could simply move trigger areas upwards by one pixel compared to where NL would place them. The only place this would end up functioning differently to NL is the top and bottom rows of pixels, and neither is particularly likely to have a trigger area there that doesn't extend higher/lower than just that one row and is significantly affected by this change (and I'd question what kind of fair level even could have such an object, though I wouldn't outright rule out that there's a way).

On the other hand, if a similar change is applied to climbers, I can see that being a bit harder to handle in a way that's always consistent with NL.

I think for the reasons you state, it would be best to use a seperate board. I'm quite happy for you to have mod access on the NL ones for the purpose of reviving topics for NLCE purposes. I'm fine with WillLem's proposal as-is if it's preferred as the best way forward.

With that being said, I'll also give my two cents on the how (and this is just a suggestion, not a ruling) - we probably don't need the overall structure of the NL Bugs & Suggestions board anymore either, now that there's no active development on official NL (other than updating the collection of user-created styles periodically). Perhaps a better way forward - we create a single new board to use as an archive of NL bugs / suggestions, and turn the existing NL B&S board into NLCE ones. I would approach this by first moving everything to the new board, then letting WillLem go through this board and move back the ones that he wishes to revive, creating redirect topics for each move (the only effort required to do this is clicking a single checkbox when moving the topic) - I usually prefer to avoid creating those, but in this particular case (moving topics out of what would otherwise be an archive) I think it should be done.

We'd need to confirm with WillLem exactly what he wants to do around editor suggestions though, as my understanding is he's working on a single combined editor that covers both NL and SLX, rather than seperate ones.

I'm now remembering: I intended for the assigners, deassigners and portals to specifically cancel the projection shadow, as an alternative to having to make the shadow handle these cases (as it would be a relatively rare edge case anyway of needing a shadow that passes through one). Seems however, I forgot to make it only apply to the projection shadow (and maybe also added neutralizers / deneutralizers by mistake?).