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.

It might be interesting to go a bit further and examine a few more things:

How many designers enter? How far do they normally get?

If we think recognition is helpful for encouraging participation, then I think there might be some merit to having another voting category that explicitly excludes levels from the strongest competitors (as determined by past contest results).

Consider the actual visual representations of objects, i.e. how they are presented to the player, not how the game sees them internally.

Water and continuous traps such as fire don't represent an inconsistency regardless of how direct drop is handled. For example, suppose you enter a fire: it doesn't matter if you walked into it, fell into it, flew, whatever: by occupying the space you are getting completely roasted. The experience is probably not going to be particularly good for your health, to say the least. If you fall into water, you are in the water now; falling will not cause you to pass through it.

Many triggered traps, on the other hand, involve an object that doesn't really pose an active threat to your health until the trigger has been activated. Most of these traps appear to be something along the lines of pressure plates, but you could imagine a variety of mechanisms. A pressure plate would only activate if you stepped on it. A tripwire, on the other hand, can be triggered by passing through the space. While the game implements them all the same, it wouldn't necessarily be unreasonable for individual traps to have different rules about whether fallers should be able to trigger them. On the other hand, it's not really needed, because the game is consistent about how different types of traps are placed. Most of them are always placed on the ground, but for example the pillar spike trap is always attached to a wall (and thus its trigger area is mid-air). Because of this, allowing them to work mid-air is quite convenient: it means the spike traps can share code with the other traps, and since the other traps are going to be on the ground anyway, it doesn't really meaningfully change their behavior (if they fail to trigger the trap mid-air, then they just immediately trigger it when they land). Similarly, direct drop into a trap generally doesn't change things much; the lemming is dead either way and the only real difference is what goes on the death certificate. While you could certainly make a level relying on the behavior (a triggered trap can only kill one lemming at a time and splatters are already doomed, thus a trap triggered by a splatter is effectively wasting its time), none of the official levels do (nor do they really contain direct drops onto traps at all, unless you intentionally go out of your way to make it happen). Arguably for most traps the most logical behavior would be for a mix of the two where the lemming splats but the trap is still triggered regardless.

The visual design of exits is basically a building with stairs, and in official levels. I mean, judging from the door, it looks like there's a portal too, but it looks more like the sort of portal you would have to walk into, rather than one that sucks you in. The animations and boing sound effect also seem to communicate more that the Lemmings actively leap into the exit, rather than passively get sucked in. Thus, this suggests direct drop is probably an oversight rather than an intended feature: because the exit doesn't appear to be sucking them in, how exactly would it break a fall?