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?

Quote from: WillLem on May 13, 2024, 09:58:26 PM
OK, I'll give it a try. Can't promise anything, because I currently have no idea what an enum is, let alone how it works or how to properly implement it. With that said, lack of prior knowledge hasn't exactly stopped me so far

The syntax will of course vary by language, but I think an example will be the easiest way to show it:

Note that this example isn't Delphi, as it's not a language I've worked with. This is more about the concept of enums in general, not how to write them in your language of choice.
enum Colors
{
    Red,
    Orange,
    Yellow,
    Green,
    Blue,
    Purple
}

Basically we've just created a new type* that can only hold these values**. Internally, they're probably just ints where Red = 0, Orange = 1... Purple = 5, but code that wants a Color doesn't need to care about that. When saving/loading from a file, we can convert them to/from strings as needed; some languages offer features to do this automatically, but if not, well, if we had to do some if/else to read/write anyway without the enums, we can do it with enums too. Many languages allow you to explicitly choose an underlying type and assign your own values, but there will usually be sensible defaults.

<sub>*Well, symbolically anyway. Languages vary in whether their type system considers enums to be different from their underlying types.

**Among languages that consider it to be a separate type, they also vary in whether or not you can force it to convert a value from the underlying type to the enum type even if that value isn't part of the enum, but fortunately in many (most?) languages it's difficult to do this accidentally.</sub>

---

_{Well, there's also the somewhat more complex Rust enums which basically merge unions and enums into one feature, but let's not worry about those.}

Quote from: WillLem on May 09, 2024, 12:09:56 AM
I understand your desire for the singular option, but there are benefits to keeping them separate (and, identified by strings rather than numbers). My instinct on this one is, let's keep it as it is at least for now.

I agree with Simon here regarding the use of an enum. There *should* always be one and exactly one of the options active, but an enum will consistently enforce it across the entire codebase. Even if everything's correct now, this has maintenance benefits long-term. It shows that it's intended that exactly one of the options is true, and you won't have to worry about any bad behavior as a result of attempting to run multiple options at once (sure, maybe setting them all to true doesn't misbehave for now... until some other change happens and it no longer gets handled gracefully but nobody checked).

You can still identify them with strings in the options file, and the enum values have names so it's not like you need to remember that "OptionA" is 0, "OptionB" is 1... keeping track of that is the compiler's responsibility.