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.

Topics - namida

Pages: [1] 2 3 ... 46

Drawn on my Toshiba Portege Z10T using Krita. Layers used heavily, but only two brushes at their default size: one of the erasers, and one of the pencils.

The two girls are a lix and a lemmina.

Okay so, I've often mentioned the reason terrain grouping is missing in NL is because the editor's file parsing code is written in a way that could lead to it being unable to load perfectly-valid level files that use terrain grouping, depending on how they're structured.

I've finally gotten around to writing new file parsing code for it that averts this, and as such, been able to enable terrain grouping (the underlying functionality of which has been there for ages - it's just loading and saving that was missing).

However, as this is a very major change - and I don't know how well-tested the grouping feature is (although it's Nepster's code, so I'd guess probably pretty well tested) - I feel an experimental build is a must here.

So - here you go. If you want to try out piece grouping, or just help test in general, download this editor. Save often, and be prepared for the risk of data loss. If a file does seem to have data loss when you load it, try loading it in the old editor or in NL - if it works fine there, it could be a bug in the new version's loading code.


If an existing level isn't loading properly, run it through Cleanse Levels. When writing the new level parsing code, I have not bothered to maintain backwards compatibility for pre-V12.7 NXLV keywords. So, any levels that predate this won't open.

And to be clear - you do NOT need a new version of NeoLemmix to go with this. NeoLemmix itself has supported piece grouping for a while now - it just never had the corresponding editor support. Use this experimental editor together with the current stable version of NeoLemmix.

Engine Bugs / Suggestions / [SUG][PLAYER] "Timer bypass" for nuke
« on: June 27, 2020, 10:32:22 pm »
So, a recent discussion occurred around potentially removing the timer from the nuke. The eventual decision was that it leads to unnecessary breakage.

However, as the flipside to this - if the timer isn't being removed, it makes sense to specifically add features to minimize the frustration that arises from it.

Therefore, here's the proposal: A new feature - which would not become the main method of activating the nuke - which essentially becomes a shortcut for "go back 5 seconds, start the nuke, then go forward the 5 seconds again". Of course, the "5 seconds" would be frame-perfect to the nuke's duration.

This would not truly bypass the timer as such. Physics don't change at all - it's purely a UI feature to reduce the need to time the activation of it.

Perhaps this could even be expanded to "Select a lemming; then - if such a nuke timing is possible - insert a Nuke action earlier in the replay, such that the selected lemming will complete his countdown on the current frame".

Non-Lemmings Projects / Tiel Attack: Retro-style 2D platformer
« on: June 20, 2020, 10:09:15 pm »
Many of you will already know about this from Discord, but I've been working on a new side project - one that, for once, is actually going somewhere.

Introducing Tiel Attack.

Some Screenshots (click to show/hide)

This basically started as my "quarantine project", and while work has slowed since then due to, well, being back to actual work; it's still progressing, just slower than before.

Tiel Attack is a 2D sidescrolling platformer, with the notable feature of being a single huge map rather than many smaller ones. The game is semi-open-ended; there's an intended linear progression (with slight flexibility) of the bosses to fight, but some freedom in exploration rather than being railroaded towards each boss.

You can also, for the most part, choose to play as Don or Nod. There's some limits on this - Nod can't get out of the starting area until a little bit later in the game, and there are some areas that require both tiels working together. But the rest of the time you can choose - Don's higher jumps, or Nod's stronger attacks?

And yes, it features my cockatiels Don birb and Nod brib as the playable characters.

Download Demo (V6):
Requires a 64-bit Windows OS with .NET Core 3.1 (which in turn requires Windows 7 or higher, I believe). May or may not work on WINE, feel free to try and let me know. CPU is more important than GPU, and RAM requirements appear to be quite low (it uses less than 128MB of RAM while running, in my experience).

This demo allows you to play up to and including the first boss. It also allows some very limited exploring of side areas.

Engine Bugs / Suggestions / [DISC][PLAYER] Remove timer on nuke
« on: June 19, 2020, 09:41:05 am »
The more I think about it, the more I'm realising - having timers on the nuke really doesn't make any more sense than having them on regular bombers. Even in levels with nuke solutions, it should generally be possible to preserve any replay simply by delaying the nuke assignment by 5 seconds.

And of course - it'd clean up the code a bit.

Is there any good reason not to do this?

(Culling the nuke is not under consideration here. Only culling the timer on it is.)

Engine Bugs / Suggestions / [DISC][PLAYER] Official game conversions
« on: June 17, 2020, 07:44:42 pm »
Okay so, it didn't take long for this to get out of control - to the point where the SAME person posted three different L1 conversions, simply to reflect the slight differences between three official ports. So, while I'm sticking to that I don't want to maintain any official conversion (and indeed that I don't think there's a need for one), I'm also going to take steps to ensure there isn't a ridiculous proliferation of them either.

There's three options I'm open to here:
1. Declaring one person to be in charge of conversions.
2. Declaring one particular conversion of each pack (or in some cases, collections of packs) to be "official".
3. Prohibiting such packs altogether, with a special exemption for Redux.

It goes without saying that my favorite is #3, but I'm guessing that won't go down well, so let's talk about whether approach #1 or #2 is the better one to take.

There are some standards I expect in either case, for any conversion:
1. The most critical NL community standards will be respected. By this I mean - I don't care what decision you make around time limits or lemming counts, but unhide the traps (special cases can apply to the hidden exits in the few official levels that have them. That is the ONLY special case I will accept), don't have weird overlaps of steel and non-steel, etc.
2. All levels should be confirmed possible to solve. For cases where a direct conversion is not possible to solve, it is up to the author how they address this.
3. Consistency. If moss-on-steel is handled by total removal in one level, it shouldn't be handled by moving-away-from-the-edges in another. A level and its repeat should retain identical layouts, unless they already had differences. This also means that as far as possible all levels should originate from the same port. Of course, if a level is exclusive to certain ports, that's another matter, but if you're eg. mostly taking levels from Amiga, there shouldn't be one or two that are taken from DOS instead.

I've put this list together because the majority of custom content is for L1 or L1-clone engines, so here's a quick reference for people looking for custom content on other official Lemmings games.

There's probably more out there, especially for Lemmings 2 - let me know if there's anything I should add.

Lemmings 2: The Tribes

General Lemmings 2 custom level thread

Author: kieranmillar
- Fun With Blockers (10 levels)
- Holiday Tribe 2017 (10 levels)
- Lemmings ... In Space! (10 levels)
- Quest From Kieran 2 (120 levels)

Lemmings 3: The Chronicles / All New World Of Lemmings

General Lemmings 3 custom level thread

Author: Clam
- Clam Spammer's Egyptian Tribe for Lemmings 3 (30 levels)

Author: kieranmillar
- Quest From Kieran 3 (90 levels)

3D Lemmings

Author: namida
- Lemmings Plus 3D (80 levels)

Author: Pooty
- "Making One's Head Turn" (1 level)

Okay so, these existed in the past, but were culled during the move to new-formats.

These of course would be purely a thematic thing, with no gameplay effect. They animate when a lemming walks past (presumably, both a "once" and a "infinite" version could exist), but otherwise do nothing.

The common argument against them is that if an object looks like it gets triggered when a lemming walks past, it should do something, and that it's misleading if it's not.

I'm not convinced by this. I do understand where it's coming from but, "nothing" is just another possibility to a list of things it could do. Without any context beyond "it animated when a lemming walked past", you don't know exactly what it does. You have to either look closer, or use CPM, to find out regardless - or, use context, like "what does the object look like?", at which point these are no different to anything else in regards to "don't make them look like things they aren't". (Even if you look at "did the lemming disappear?" - if it does, that could be a trap or a teleporter. If it doesn't, that could be an unlock button, a pickup skill, or a splitter that's pointing the direction the lemming is already facing.)

The benefit of course is purely an aesthetic one; but the effort to do this is relatively low - almost all the code could simply be copied from traps, with the "kill the lemming" lines removed.

One other reason is - some people have expressed interest in trying to do this anyway; one even trying to figure out a workaround to emulate this with features that do exist (it's possible - but I'm not going to explain how, and I don't believe that person figured it out). This may be a case where it's better to implement it properly, at which point CPM can hide or appropriately label it, or even potentially an option can be added user-side to hide them (or make them not function).

What's other people's thoughts here? Does anyone feel I'm underestimating how significant the "it should do something" factor is, or that there are other reasons against this?

Engine Bugs / Suggestions / [PROPOSALS][PLAYER] New menu design
« on: June 04, 2020, 04:17:18 am »
Okay so, I'm interested to gather some proposals on a redesign for the menu screens - basically, everything except for in game. This can be as similar or as different from the current design as you see fit, subject to the following criteria - of course, it's likely the final result will be a combination of ideas, not just one single person's idea taken as-is.

To be clear - this is not about adding new functionality. "Add an option to turn the lemmings purple" is not a relevant suggestion for this topic. On the other hand, displaying more information is fine, even if a bit of work might be needed to achieve this - for example, a suggestion that the entire skillset of the level should be visible on the preview screen and/or level select menu is fine.

The criteria are:

1. It should be possible to access all menu features, except perhaps very edge-case things like saving an image of a level from the preview screen, using only the mouse.
2. It should take into account the need to improve how talismans are displayed.
3. It should keep in mind that NeoLemmix is a game; not an office application.

I might add to this if I think of other things I've overlooked, but in particular, while keeping a similar theme (or even a similar layout in parts) to the current menu setup is not required, nor is it prohibited. If you feel a derivative of the current one is ideal, that is absolutely an acceptable suggestion.

I foresee this discussion going through a couple of topics. This one is mainly about throwing ideas out there, essentially, treat this as a "no idea is a bad idea" phase (within reason).

Here's notes on what the user can currently do or see on each menu screen. This is for reference only, and is not a declaration that any suggestions must also follow this "what's where?" structure.

Main Menu Screen
- Begin / continue gameplay from currently selected level
- Change to a different group (rank) within the same pack - this will select the first unsolved level, or the first level if all levels are solved
- Open the Level Select menu
- Open the Configuration menu
- Open the Talisman list screen (if the active pack has any talismans)
- Exit NeoLemmix
- Perform a mass replay test
- Dump images of all levels
- Cleanse levels
- Get notified if NL or style updates are available

Level select menu
- See a list of all installed levels, sorted by groups / sub-groups / etc
- Select a (sub)group or level
- See info about and completion status of the level; this is currently very limited in scope and should be expanded

Config menu
- Configure various game settings
- Run a mass replay test

Talisman list screen
- See a list of all talismans in the current pack

Preview screen
- See a preview of the level
- See the level's title, author (if noted), group and index, lemming count, save requirement, time limit, and if present and not yet obtained, a single talisman's requirements
- Save an image of the level
- Load a replay

Postview screen
- See save requirement, actual saved count, and save record
- See time taken and time record
- See a "You unlocked a talisman" text if applicable
- Proceed to the next level's preview screen; replay the current level; or exit to menu
- Save a replay

Doesn't always happen, but in some cases, the shadow will imply that the shimmier won't succeed, but when used it works fine. This seems to be purely a bug with the shadows.

This happens at the height of the jump when the gap between the floor and ceiling is 26px. It also happens at most, but not all, gap sizes lower than 26px on the last frame before the jumper hits his head and becomes a faller. It doesn't seem to happen when the gap is larger than that.

I'm thinking - NL already goes a long way to fight unfair level designs. But there's likely room for improvement here.

My intention here is not to outright disable such levels. There are several reasons for this - the risk of false positives, preservation of historical content, some might even have very rare legitimate use cases.

Instead, I'd like any solutions to take one of three forms:
a) An explicit warning message to the player. I'd kind of like this to be an intrusive, unmissable one (a popup of some kind); but it could also be something a bit less in-your-face like a "WARNING: May contain unfair content" text on the preview screen.
b) A conditional, or just always-shown, helper of some kind. For example, perhaps a big "EXIT" with an arrow appears above / below the exit at the start of the level, preventing it from hiding behind terrain even using workarounds like "fill the entire level with an updraft trigger area". This could even be more generic, just a "WARNING" sign that alerts the player that something dodgy is going on in a certain area, rather than specific graphics for each situation.
c) Additional clarity in Clear Physics Mode. This would likely be in addition to, not instead of, one of the above.

Regarding the situations this should detect, of course, some are more realistic than others to detect in practice, but some situations I'd consider:
- Objects (other than purely-decorative ones) hidden behind terrain
- "Only on terrain" objects that don't overlap any terrain - although my more-instinctive thought here is that only-on-terrain objects should be non-functional in the first place
- Multiple overlapping windows, if this affects the state of spawned lemmings or the spawn order
- Multiple overlapping pickup skills (even if they are the same skill, the overlap will affect how many)
- Objects that have functions, but blank graphics (and thus end up invisible)
- Identical in appearance steel and non-steel pieces (this would only be able to go as far as detecting them when used in the same level, and would be very limited as to how much it can detect those that are merely "similar")
- Perhaps any piece explicitly marked as "UNFAIR" in the NXMO / NXMT file, for those who are choosing to make such packs while being honest and open about it (or as a tag that can be added in the styles download to pieces that have been identified as unfair but are not detected by NL's automated tests)

If false positives / flagging of legitimate use cases become too much of a concern, this could perhaps be combined with some kind of centrally-maintained whitelist of levels that are confirmed to be fair. On the other hand, my sympathy for historical content only goes as far as "don't outright prevent it being played" - I am 100% okay with such levels being flagged with a warning, my own included in a couple of cases where I've made designs that don't stand up to today's standards.

Three things to discuss in relation to these:

1. Whether they should be kept at all.
2. If so - would you use the ability to provide custom ones for your packs, if it were supported?

3. Does anyone enable the success jingle but not the failure one, or vice versa?

Engine Bugs / Suggestions / [SUG][PLAYER] "DPI aware" option
« on: May 26, 2020, 09:17:40 pm »
See this topic for an example:

Basically - if NL reports that it's DPI-aware, the OS won't try to scale it to better suit the screen. Downside is that NL must upsize things to fit the screen itself, which can get laggy on particularly high resolutions (on my 6th-gen i7 laptop, this is noticable at 4K but not at 1080p); whereas the OS scaling seems to be far more optimized (likely, it uses the GPU).

The downside is, if the user's scaling is a non-integer value - which in particular, a non-integer value is the default on 1080p laptop screens (even at 15.6"; not sure about 17.3") - this results in NL being blurry.

Given that, I don't want to make NL "always DPI aware". But there's another option here - a user-setting.

In a sense, the user setting already exists, as described near the end of the above topic. But that's an OS setting which some users may not feel comfortable messing with. So instead, I'm thinking that an option could be implemented in NL, that determines whether or not NL reports itself as being DPI-aware. (If it does, the OS won't scale it.) Of course, this would present itself with a less-technical name, perhaps "Disable OS upscaling".

For technical reasons, this will have to be a "you must restart NL when changing this option" setting. It's very messy to switch such a setting on at runtime, and my understanding is that it's outright impossible to turn it off (the Windows API throws an error if you try).

Let me be very clear - I'm not very strongly on the side of making this work again. And I want to stress this: Please do not create packs that "require V12.8 exactly". V12.8 isn't a "notable" version in the same way V1.43 (last stable version before some major culls) or V10.13.18 (last old-formats version) is; making packs that will in the future require people to dig it up is very, very messy; and it's very arguable you'd be doing so not because of a culled feature, but because V12.8 has a bug that later versions don't (see below for the logic behind this claim), which is extremely contrary to NL's philosophy as bugs shouldn't exist, let alone be intentionally used by content. Affected levels can very likely be adjusted to use jumpers instead, or some other workaround. (It's different if you put a "this isn't yet tested for V12.9" note on an existing pack; I'm talking about new releases here, especially in the more distant future as opposed to something you've just finished and were ready to release but got hit by this issue.)

As background - there was a bug in older versions where the timing of the faller -> glider transition would depend on what the lemming was doing before becoming a faller. This is now fixed in V12.9 to be consistent, but one side effect is that the Stacker-Shimmier-Glider trick (where you assign a shimmier to a glider right in front of a stacker's stack, so they jump and land on top of it) no longer works.

There are basically three ways this can be handled. In order from my strongest preference to least preferred.
a) Accept this. The logic here - while the trick itself might seem fine, and indeed was accepted by some users who generally speaking have very low tolerance for weird or glitchy physics cases, it only worked due to an underlying bug. Therefore, it would make sense that, like any physics bug, it should be fixed. However, a counter-argument is that at this stage, NL is accepting some very minor ones (such as the floater equivalent of this very bug, which rather than actually seperating lemmings, might just cause a difference of 1 frame in how quickly they hit the ground).

b) Introduce a special edge case where a faller who transitions from a reacher, pulls out the glider slightly earlier than he normally would. This has minimal side effects but does mean there's another special case, just to preserve a behaviour that originated as a bug. Still, perhaps there's some argument as to why this makes sense (that doesn't rely solely on "we could do it before, so we want to still do it now").

c) Revert the fix, and accept the pre-bug situation. The original bug, while very specific, lends itself to creating very trollish levels once a designer is aware of it. It could also in less-dodgy situations, lead to weird unexpected outcomes in challenge runs or when trying things on particularly tricky levels. Not to mention, I kind of feel that "side effects are too much" is the kind of thing that doesn't get decided retroactively; if it wasn't so bad that people were complaining during the RC phase (during which the only complaints related to window sizing / positioning), it's not bad enough to warrant reverting a bugfix. So, option C is pretty much "theoretically, this could be done, but it won't happen".

NeoLemmix Main / Plans for V12.10.0
« on: May 24, 2020, 04:19:28 am »
So, for the first time in a while, there's no specific feature that stands out as being "the one" to go for in V12.10.0. Such a situation nearly arose with V12.8.0, but then the idea of high-res mode came up and that became 12.8's major feature.

So instead, I'm going to use V12.10 as a catch-up for various (non-physics) requests or bugfixes that have fallen through the cracks so far. Kind of a "lots of small stuff, no single big feature" release, I guess. I'll work on listing some target features later, but for now, feel free to link any existing suggestions that you think are worthy of coming back to. To be clear: This isn't me saying "all of them will happen". Even if in the past I've indicated they might happen, I may decide now that they won't - or that they won't yet. But this will be essentially a time to give them a second look, at least.

Over time, it seems that V12.10.X considerations have naturally gravitated towards many menu-related concerns. So the main focus for V12.10.X is going to be any overhauling / touching up of the menu system. By "menu" here, I basically mean everything that isn't in-game - the title screen, level select menu, config menu, preview / postview screens, etc.

A few other features have been put on the list as a carryover from the older "catchup time" goal. Most of these will likely still happen, although I may reconsider (in the sense of "delay them", not "reject them") some of the more complex ones.

To do
- Revision and mouse-friendliness of menu screens (including support for per-screen backgrounds)
--- Per-screen backgrounds
--- Record-keeping and -displaying
--- Custom post-level jingles
--- Dedicated "Pack version" field for level packs
- Allow a level (or music.nxmi) to specify a priority order rather than just a single track for music
- Turning off skill shadows
- In-game display of talisman requirements

To discuss / consider
- Cloner replay bug - probably more likely for a V12.11 fix

Pages: [1] 2 3 ... 46