Quote from: hrb264 on February 28, 2026, 10:49:49 AMAlso I usually like to be quite generous with the skill set because I often make mistakes  especially if I make levels with 100+ lemmings, or where you have to assign a load of floaters etc, but I get the impression many people often like to have 1 or 2 of each skill and don't like this sort of level? (To be honest, 1 of everything levels aren't my favourite type )

I think the big thing with this is just make that you're doing something interesting with all those skills. Maybe they make the level open-ended, maybe you're limiting a few key skills and providing excess of everything else, maybe it's a level where only a few of the skills are actually useful and you need to figure out which ones... What you definitely don't want is "here is the hatch where we shall be assigning 50 floaters to 50 lemmings" or "here is our massive gap that we have to cross that requires 20 builders", because at that point you may as well just lower the drops, shorten the gaps, etc.

Quote from: WillLem on February 28, 2026, 04:19:03 AM2) Does the skillset provide more skills than are required to solve the level as intended? Yes = 0, No = 1

Of course, I'm sure these are intended to be guidelines and not hard rules, but I think this one has an interesting caveat: providing more skills than absolutely required will often allow more possible solutions (which makes the level easier), but if the excess skills don't actually open any new solutions, then it could potentially make things harder by obscuring which skills you're actually supposed to use.

Quote from: Armani on November 25, 2025, 04:49:44 PMI prefer not to release all solutions at the same time I publish my levels because I enjoy seeing how far players can get without having the answers available from the start. For me, part of the fun of creating levels is watching people try to solve them on their own first and many players also enjoy the challenge of approaching a new pack without immediate spoilers. That said, whenever someone tells me they're stuck on a particular level and asks for the solution I always provide it. This has been the case for every pack I've ever released without exception.

Adding to this: It's REALLY difficult to gauge the difficulty of a level you've just created, because you already know how it's supposed to be solved, and you can get all sorts of feedback as a result of people attempting the level; even if you only get back a set of replays, you'll see that the hardest levels (for that player at least) remain unsolved. If someone spoils themselves, though, then they can generate their own replay for the level, and you lose that feedback unless they explicitly tell you that they had to look it up.

I think Discord-style emote reactions is a good idea; it's a nice way to non-intrusively weigh in when you want to acknowledge a post but don't really have anything to add to the discussion.

I don't think we need to bring back any form of karma system, though. They are mainly useful when you're dealing with post volumes that are too high for chronological order to be a reasonable sorting method and need to get some feedback from users about what should rise to the top and what should get buried, but with our current amount of posts I think it offers more downsides than advantages. Karma systems with downvotes don't provide helpful feedback (keep in mind a lot of our worst posters are probably kids that don't know better yet), and karma systems without downvotes generally means that, as long as enough people see it, even the most vile things you've ever read in your life will have several likes, which makes it look like the community agrees with those things, even if the reality is that the vast majority of people who saw the post would have downvoted it, and even if the comments reflect that, well, you're probably gonna see the likes before you see the comments.

Given the amount of dev time that would likely be necessary to support it, fully independent profiles are probably overkill. I do think there may be benefits to have hotkey profiles specifically: it would allow for easy experimentation with different layouts without losing your existing hotkeys. Of course, you can always do this through the OS; the main benefit would be convenience (and really all it has to do is automate the process of switching the files around, or just swap the file it uses for it).

Regarding skill queuing: if we're going to have a setting for it, maybe it should be for the number of frames to queue for rather than a binary yes/no.

Did a little testing though my disclaimer is I just used the .zip provided by zanzindorf; didn't try the installer.

The error I get on Win10 is "Component 'COMCTL32.OCX' or one of its dependencies not correctly registered: a file is missing or invalid."

Also tested in WINE on Arch Linux and got "0024:err:module:import_dll Library MSVBVM60.DLL ... not found." I'll note that this test could also have issues since I haven't extensively tested the wine installation to know if it's configured correctly; I got NeoLemmix running with it simply because I knew it should work and that's about all the testing I've done to it.

Of course I suppose it's possible this is an installer that's more than a glorified extractor, but just using the zip seemed a little safer. Curious if anyone who's tested the installer gets the same errors.

Maybe I'll test the installer later.

Best Guess: probably means the level has been changed since it was last solved.

Expected behavior: This icon isn't something I expect to see, so I would expect some sort of obvious way to see more information about it, either by hovering over it (e.g. tooltips), by clicking on it, or by selecting the associated level. Icons are good shorthand but ultimately users aren't psychic, so if cause and effect isn't obvious some textual explanation may be warranted.

QuoteMake panel hi-res only (regardless of game setting)

I will explicitly say I strongly oppose this. I have always disliked the high-res mode setting and the only reason I haven't complained about it more is because it's also always been optional.

For the most part I pretty much agree with what Icho's said, though there are some specifics (e.g. the release rate sounds) that I'm not opposed to as long as they're optional.

---

For now I think keep it to QoL changes only (e.g. position-based skill panel hotkeys) and let's not make breaking changes until we need to break compatibility anyway to fix bugs. I think leaving bugs can be potentially dangerous; we probably don't want to return to the level design culture of CustLemm/vanilla Lemmix where glitches were considered fair game and I think the longer major glitches/exploits are known, the more people become tempted to design puzzles with them. Difficult levels were awful back then because you'd never really know if you were just overlooking something or if the level expected you to perform some weird glitch to accomplish something that really shouldn't be possible.

CAKE
COOKIE
CHOCOLATE
VANILLA
MUFFIN

If the rule prize is split between the top 3 it's worth noting, since 1-survivor-per-rule would result in exactly 3 finalists, that it would be possible to announce rules for the next contest during the vote(s) to determine the order of the top 3.

Quote from: namida on September 04, 2024, 12:52:00 AM
One other possibility that comes to mind is, during the non-mixed phase, hold all three rules' votes simultaneously. This wouldn't cut down on the number of votes, but would get them done much quicker (and can also potentially be combined with other ideas).

I think this would help streamline things a bit. The combination of the sheer number of voting rounds is a major factor in why the voting takes so long, but it's further exacerbated by the fact that we only run one round at a time even when the rounds don't have dependencies on each other.

It's already been brought up but I would like to explicitly mention support for the idea of changing the rule design from 1st place makes all 3 rules to each of the top 3 makes 1 rule; if someone is trying to earn that reward, hitting top 3 should be more attainable.

Quote from: Flopsy on August 26, 2024, 03:38:18 AM
AFK kicking wouldn't work because it would probably kick spectators too and they aren't able to make inputs while a game is in progress.

A possible solution that would address this problem would be, instead of kicking, automatically set afk players to spectator mode.

Quote from: FlopsyIt is annoying but unreadying people when a change in colour occurs is necessary. Ironically I know who you are on about when you say this also!

I think a simple improvement to this would be to change it so that this only unreadies players in the event that teams have changed. I don't think it's necessary to unready everyone when the sole player of a certain color switches to a different unoccupied color.

I'd like to say that I don't think players should be forced to use the nuke when they can no longer improve their standing, particularly in matches with a lot of players. You can still try to lower the amount by which you lose, or cause chaos, and either way it's more fun than just sitting there waiting for everyone else to finish.

I'll note that you can still have some fun with the learning process (though there will probably inevitably be a few parts that you don't like working on but you gotta do it anyway) -- just don't go for the "dream project" right away because that's how you set yourself up for failure by encountering an insurmountable obstacle. Starting small does not need to mean starting boring.

I'd also add that we haven't touched much on the actual complexity here. Scratch is very much designed to be easy to work with and is going to abstract away tons of complexity behind the scenes. But many of those abstractions rely on being able to run it, and your proposed operating system will, at first, have no way to do so; your operating system would need to provide all of the facilities necessary for it to run (even if it's something that runs in a web browser, this is still dependent on having a platform that is capable of running a web browser). And as it turns out it's a lot easier to use e.g. a function that draws a picture on the screen than it is to write that function. Or consider responding to the user pressing a key on the keyboard: instead of simply having some sort of is_key_pressed or get_keyboard_state function or on_key_press callback, you'll have to worry about things like how the keyboard actually communicates. Alternatively, if you want to target older hardware like the NES, you still have to hand-roll a lot of stuff because the hardware is so underpowered that pretty much any level of abstraction can be expensive, so the code is going to be much more complicated than Scratch for sure.