Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - namida

Pages: [1] 2 3 ... 843
Is there any real need to distinguish between the cause of termination (ie: time ran out vs no lemmings left), if we make "nuke has been activated and no lemmings remain" a special case?

Let's rule out any distinguishing between "saveable" and "unsaveable" lemmings, except for the special case of zombies. This one is simple because zombies are never saveable - they cannot exit and cannot be transformed to a state where they can. Anything else, such as a blocker, needs further checks to confirm if it really is unsaveable or not. Even a neutral blocker requires "do only neutral blockers, who are not overlapping teleporters, remain?" Whereas "do only zombies remain?" is already tracked, and will always be tracked as part of calculating the remaining alive lemming count.

Let's also be clear that, I'm not going to implement every option that simply "might" be liked. If there is no or little interest in a particular behavior in practice, it doesn't need to be added, especially if it only saves a single button press. Poll results show no interest at all in the exit behavior; not much for pause either but not outright nothing.

Distinguishing between "player has nuked" and "player has not nuked" is worthwhile to consider as a special case. There is always the option to add a delay of a few seconds after the last lemming dies, to handle rewinding in nuke solutions.

Lix Main / Re: Level file format: player count, neutrals
« on: November 26, 2022, 08:12:03 AM »
Should this be determined by the level rather than a single hardcoded behavior?

To some extent, this could be solved with multiple variants of a level (ie: levels with identical layout, but different number of players). This could get messy. Alternative: Allow a level to contain multiple seating arrangements, for different numbers of players, including a "discard" option (eg. in a map designed for 7 players, when playing with 3, it specifies that the 7th seat's exit / entrance are removed entirely, while the rest are distributed two seats per player). Then, do not allow - or at least give a visible warning - playing that map with a number of players that it does not contain a seating arrangement for. Between these two options, it allows the level designer to figure out and provide what works best for their level. The editor could also provide options to quickly set all seating arrangements based on some default pattern.

Contests / Re: Level Design Contest #WasteMyTime
« on: November 26, 2022, 07:58:23 AM »
Here's an example of what I was talking about earlier with bashers. Feel free to count it as an entry if you like (though there's almost certianly room to fine tune it to take even closer to the full 8:20 without making execution too difficult - I'm only really trying to illustrate the concept here, of how a level can be time consuming but not remotely interesting).

I'd think you'd get more value, especially considering the general philosophy of NeoLemmix, if you were to base it on how long it takes you (from the start of your first attempt) to find a solution. Your call, of course, as it's your contest - that's just my general thoughts.

Contests / Re: Level Design Contest #WasteMyTime
« on: November 25, 2022, 08:06:55 PM »
You could also just make a series of long bashes that go the full length of the level, each one slightly lower than the last. Or a climber-digger wall with a similar concept, with a second lemming who must also be saved but only one climber.

Fixed in commit 51fa561.

I've put a poll up about what option people would use.

To be very clear, some form of "allow continue playing" will remain an option, and in all likelihood the default option. That feature is not going to be removed. It also has to be considered - there will likely be one-off cases where a player wants to continue playing even if they usually set their option to "exit on time-up", so how to achieve that has to be considered (it may be that the answer is "don't; it's their problem, they can change their settings", but I want to at least give some thought to this).

Okay, so it doesn't seem to outright cache them; it just doesn't regenerate it if the previously-rendered preview was for a level with the same ID as the current one. It should be easy enough to change this to use another factor (I believe performance reasons is why this happens at all; so not going to remove the check altogether).

Packs should be fixed to avoid ID collisions regardless, but (if that is the cause) it should nonetheless be fixed. In particular, physics / bug test levels that aren't intended to be played seriously, I wouldn't necesserially expect the same efforts to avoid ID collisions to be made for those (and indeed, I don't always do so myself), but preview differences could still be important to see. I vaguely recall writing code to cache level previews; it's very possible that it identifies the level based on level ID (and if so, it can probably be changed to instead rely on file path).

Beyond that, I'd have to look into it to say if that is indeed the cause (and if not, what is).

Ah, I see the issue upon looking closer - in the grouped pieces, some pixels are becoming non-solid where they shouldn't. I'd have to look into the code to figure out why, but this is definitely a bug. I do notice it happens specifically where the two pieces overlap - which should not become non-solid when the non-overlapping pixels remain solid (as they would be more opaque, not less).

Regarding the steel - when steel is involved in overlapping semi-transparent pieces, it depends how semi-transparent they are as to what the result is. As a general rule of thumb, if a given pixel is opaque enough to be solid when placed not overlapping other terrain, it's also opaque enough to overwrite steel with non-steel physics.

I'd have to look into it more closely - haven't had a chance to do so yet. Can you post a pic of them in the player (not grouped) to compare, or tell me which style / pieces these are? Or post a sample level?

The editor does not handle semitransparent terrain properly. This is a known issue but hard to resolve with how the editor is written.

NeoLemmix Styles / Re: Style updates topic
« on: November 15, 2022, 08:34:25 AM »
Updated to here in both the style manager and the all-styles zip.

NeoLemmix Main / Re: Definition of Complete Replay
« on: November 14, 2022, 01:11:25 AM »
That's an excellent point. I should flag such cases in mass checks even if the replay ultimately still passes.

NeoLemmix Main / Re: NeoLemmix V12.12.5, Editor V1.40 Released
« on: November 12, 2022, 09:25:14 PM »
NeoLemmix V12.12.5 released. This backports several minor fixes that were implemented for V12.13.0, see first post for changelog. Full download link is in the first post, or you can use the attached ZIP to upgrade from any previous stable V12.12.X release.

Pages: [1] 2 3 ... 843