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 ... 609
So I guess this means that while it isn't possible to assign any new skills to Neutral Lemmings, they can indeed come with certain permanent skills pre-assigned to them?


Lix Main / Re: Lix ingame UI (skill panel)
« on: Today at 12:25:01 am »
I've considered hiding skills that aren't available in a level, but NaOH wanted to always show those unavailable skills. Reason: It's easier to find a skill when it's always in the same absolute spot. Downside is of course the cluttered UI.

Being able to find the same skill in the same spot like that is very important for Lix's multiplayer mode (high-tier players use hotkeys, and newbies likely have to look anyway, but for those in the middle it's invaluable), and beyond that is a matter of consistency between single-player and multiplayer. NeoLemmix has no multiplayer mode to worry about, so skill-position-is-same is less critical there - though I do feel the relative positions should be consistent (or in other words: there should be a fixed overall order the skills appear in; with unused skills not displayed).

Challenges / Re: Lemmings SNES point records
« on: May 21, 2019, 11:44:17 pm »
:lem-mindblown: woah you did cascade 100% and with 18 skills left?!? i cant even beat the level normally! props 2 u m8 :lem-mindblown:

I'm not sure how that skill count stacks up, but 100% on Cascade has been known since long before this community existed. With that being said - I don't advise looking for it if you can't beat the level normally. The 100% solution is nothing like the normal solution that saves 10% or 12% (depending on which version of the game you have - 12% on DOS and Win95, 10% on Amiga / SNES / Genesis), and is easily on par with late-Mayhem levels, perhaps even harder, in terms of difficulty.

I think it would make more sense to use a sprite based off the existing NL sprites, yeah. If the Beach lemmings in general are direct recolors of the default lemming sprites, then the Shimmier should be an equivalent recolor of the default NL Shimmier sprite.

This was discussed, along with other modernisation touchups. The Lemmings Redux pack that Proxima mentions was the result - people felt anything beyond changes that are necessary to keep the level possible, would be going too far, so instead we created the Redux pack as an unofficial, separate pack that's perhaps more like a "remaster" (except, in terms of physics / level selection and ordering, rather than in terms of graphics and sound) than just a port.

Your "current" table is correct on everything except one - "EXHAUSTED" would currently be "--" for a single-use trap. (Exhausted exists only in the limited entrance / exit branch, and is currently only applicable to them.)

For the proposed, DISABLED would not be changed in any way. Your thoughts on "EXHAUSTED" are spot-on.

However - I am now thinking (and this is thinking ahead to the limited exits / entrances again), based on how "DISABLED" is applied in general, it should be true for limited entrances/exits when used up, too. For limited entrances and limited non-lockable exits, the two would thus become identical. For locked exits, there'd be a difference: "DISABLED", but not "EXHAUSTED", is true before the entrance has been unlocked.

See my earlier table (post #42, about half way through the post, behind a spoiler tag) for the general rules I've been applying here, keeping in mind (a) the rules themself can be changed if there's good reason, and (b) there are definitely cases where it's questionable if I applied it consistently, so if you disagree with how I've applied it (and it isn't obviously a case of "this is a situation we need to distinguish, but it's close enough to this, that we don't need an additional condition altogether"), please mention this.

I consider it acceptable for two conditions to have near or full overlap for a certain object type, as long as this is consistent with the general rules of the conditions.

The shimmier together with the secondary animations seem large enough to me to go even to V13.0.0. While this might not be totally according to semantic versioning, this might help players to distinguish versions and ensure compatibility between player versions and level packs.

Are we going to increase the major version number every time we eg. introduce a new skill? Or is it mostly the secondary anims you feel this way about? If it's the former, I'd suggest we try to get in any other planned new skills first as well (which IIRC is just the Jumper) - and maybe a few more of the planned features as well. (In exchange, I think it's also fine for a major update to take longer than a normal update to be ready.) I also think a major version upgrade would be a perfect time to introduce the username feature - I recall you wanted more clarification around this; the best place to discuss that would be Proxima's topic about record overwriting from other user's replays, which was the reason for introducing this feature.

In this case, I suggest we look at back-porting some of the bugfixes and minor features (like mass image dumping) to make a V12.4.1. If we go with such a plan, I'm happy to work on preparing such an update. (EDIT: See the v12.4.1 branch on my repo. This should integrate all bugfixes and minor features (restored image dumping, slightly nicer alpha blending, external and directional-select cursors, solid color objects / lemmings in clear physics mode), without pulling in the Shimmier, secondary animations, or nine-slicing.)

I would have voted for "Jumper" if it had been on the list :D .


Neutral lemmings to me are like ghost lemmings in reverse - harmless like ghosts, but un-assignable like zombies. Or like the disobedience gimmick, but without the possibility to abuse it by assigning a skill to cancel another, or assign a skill twice to force the disobedient lemming to perform it. You can't "waste" skills on neutral lemmings, it seems like the cursor will simply not change when you hover it above them? Like with the "one-skill-per-lemming" gimmick, where you simply can't select a lemming anymore in any way once it has performed a single skill. (Basically, I expect neutral lemmings to act like a "zero-skill-per-lemming" version of that gimmick. :D )

Jumper isn't on the list for the same reason the expanded skill count isn't - zero work for it is done yet (aside from renaming the "jumper", in the sense of a lemming stepping up a height of 3px to 6px, has been renamed "ascender" to make room for the skill at a later date). But I believe Nepster's confirmed the Jumper will at least be given a proper trial period sooner or later.

You can mouse-over neutral lemmings the same way you can with zombies. If no regular lemmings are under the cursor, you'll see info on the neutral lemming under the cursor; but the cursor will ignore them if a regular lemming is also under it. You can't assign skills to them in any case. (These details are based on the implementation as it current stands, and may differ in any future experimental or stable release.)

Sure, go for it. Please send the full spritesets to myself and/or Nepster when you're done so they can be added to the NL Git repo. Don't forget to test the recoloring (athlete, selected, zombie, and combinations thereof).

what about vertically stacking the RR buttons as well?

At this point, I feel very strongly against the following:
- Vertical-stacking the release rate button (the only logical way to do this, that still displays all information currently displayed, gives an ~8x7 pixels pre-zoom area each for - and +)

Unless there's huge support for it, consider this ruled out simply due to the result being kind of impractical.

Double-stacking everything, with full-height buttons, isn't practical. With reduced-height buttons, we'd have to be okay with the buttons being smaller on the compact panel too - I don't want to deal with the same button being different sizes on each panel.

May I also mention that on windowed mode, the window's size doesn't change when changing zooms, unless you exit the game and start it up again.

Zoom and window size have been independent for a long time now - you can use any zoom with any window size, and the level will display as much as possible for the window size, with anything beyond that needing scrolling. You can resize NeoLemmix's window the same way as any other window. The zoom setting should really be called (if it isn't already) "Minimum Initial Zoom", as that's what it does - sets the minimum initial zoom level when playing levels (the player is then free to zoom further in or out). If the "Increase initial zoom on small levels" setting is disabled, then the minimum initial zoom, instead becomes the exact initial zoom.

The disappearing skill panel is definitely a bug though, I'll look into that.

These are all features that I've developed initial code for, player-side. They still all need to be bug-tested more, and may have room for improvements in exactly how they work. How much work remains needed in the editor varies, though all of these (where relevant) have at least a little bit of editor-side code written.

Limited-count entrances and exits - Pretty self-explanatory. This lets you have entrances and exits that only release / permit up to a certain number of lemmings. Fallback code is in place to ensure you don't end up with a level that has a higher lemming count than can be released from the entrances, or a higher save requirement than the exits allow for (it'll reduce the lemming count / save requirement to the highest possible value for the level). Editor-side, code exists to preserve lemming count caps, but not to edit them. It's possible for custom entrances / exits to have custom digits and a "close" animation (pending the acceptance of the new animation system, but that's looking fairly likely now); but the feature is also 100% compatible with existing entrances and exits (regular or locked), simply using the countdown digits as a default and indicating used-up purely by the count being zero.
Neutral lemmings - Neutral lemmings cannot be assigned skills, but in all other ways act like regular lemmings, including that you can rescue them and they count towards the save requirement. Neutral lemmings can either be pre-placed, or spawn from a neutral-lemming-spawning window (which, just like a zombie or permanent-skill window, is just a regular window that's got a "neutral lemmings" flag activated). Full editor-side support for this has been implemented, except for drawing preplaced lemmings in a neutral lemming color (and the editor doesn't do that for any existing color variation, eg. athletes or zombies, either).
Piece grouping - Allows creating composite terrain pieces out of smaller pieces, in custom levels. Those who are familiar with Lix will already know how this works - NeoLemmix's implementation is very similar. Editor has support for creating and using piece groups, but doesn't yet have support for loading and saving them - though I believe adding that support is quite high on Nepster's todo list.
Username & replay matching - Allows entering a username, which will be saved to your replay files. Replays with a different username (or no username) will not modify your level completion statuses or your save / time records. There's no editor-side support needed for this feature.

Please note:
- Shimmier isn't on the poll, because it's more or less confirmed for the next stable version anyway, so no need. (EDIT: To clarify, I mean the next major stable version. IE: 12.5.0 or 13.0.0, as applicable. If we release a V12.4.1 update, it won't contain the Shimmier yet.)
- Expanded skill limit isn't on the poll, because no coding work has been done on this yet. If I code it to a near-complete state in the near future, I'll add it in. It's possible to change your vote on this poll, so don't withhold votes for now "in case expanded skill limit gets added" - you can change your vote later if it does get added before the poll closes.
- This topic is not for discussing in depth how any of these features should work (if you'd like to clarify how they already work that's fine, as it's relevant to this topic; but if you want to discuss changes, let's use a separate one), or proposing other features you'd like to see in the near-future. Use the Bugs / Suggestions board (creating a new topic if none already exists) for that.
- We're under no obligation to implement features in the order this poll determines; it's just for us to get an idea of which features are more desired. We might follow it exactly, we might not.

- Vertically stacking some of the existing buttons (Directional select would be the first target)

Directional select is already vertically stacked.

Commit 02a13ce implements a fallback behaviour: If an exception is raised during the loading of lemming sprites, NeoLemmix will make one attempt to load the default lemming sprites intead (one attempt only, to avoid an infinite loop if the default sprites are broken for any reason). The exception message will be displayed, which will in the case of a non-updated set of lemming sprites, be a file-not-found error; but the popup will also mention that it's falling back to default lemming sprites.

Poll results are strongly in favor of a small increase (6 votes for small increase, 3 votes for no limit, no votes for keep as-is or large-but-still-limited increase).

Although the poll didn't suggest an exact number, discussion has very strongly favored setting the new limit at 10. Is there anyone who would prefer a different amount for the new limit, other than for reasons along the lines of "it should be as high as possible"?

Personally, I'd lean towards 10, but I would also be okay with 12, provided we can find a way to make it look nice on the skill panel. (I feel an odd number would be weird, that's why I didn't suggest 11.) I personally can't recall any case where I've wanted to use 10, but can recall several where I've wanted to use 9 - but again, even number is preferable to me here, and I think 10 is still a reasonable amount, as well as probably still relatively easy to fit into the skill panel.

That aside, any further comments for how this should work for the skill panel?

At this point, I feel very strongly against the following:
- Any kind of scroll or page-flip (can be hard to follow for the player)
- The same button being a different size on the compact panel vs the full-size panel (difficult to implement)
- Increasing the dimensions of the panels, especially the compact panel
- Vertical-stacking the release rate button (the only logical way to do this, that still displays all information currently displayed, gives an ~8x7 pixels pre-zoom area each for - and +)
- Removing the Pause or Nuke buttons (could leave players without a known way, or in rare cases any way at all, to pause and exit gameplay respectively)

So I think it's down to these options:
- Removing any of the function buttons (other than Pause and Nuke)
- Shrinking the minimap
- Dynamically resizing the minimap when extra skill slots are needed
- Vertically stacking some of the existing buttons - any stacking must apply to both panels
- Some combination of the above

With resizing the minimap - it should be noticed the minimap size on the full-size panel can only decrease, not increase - it would overlap with the time limit / time taken, otherwise. It could indeed get wider on the compact panel, but it's already wider there - what it lacks on the compact panel is height, but not much that can be done about that.

My preferred overall approach at this point - assuming 10 skills here, still - is as follows:

Full-size skill panel - Vertically stack the framestep buttons, and two other buttons - I'm thinking fast-forward and restart, though I don't feel particularly strongly about it. This makes room for two more skill buttons.
Compact skill panel - Remove the fast forward button. Shrink the minimap by 16px (making it the same width as the minimap on the full-size panel). This makes room for two more skill buttons.

I'd rather not lose minimap width on the full-size panel, and the dynamic resizing would be quite a lot of work to implement. The above should be fairly straightforward to do.

Bugs & Suggestions / Re: [Sug.] [Player] Remember last played pack
« on: May 20, 2019, 01:07:24 am »
Commit 96a2c97 implements Proxima's suggestion of remembering the active pack - or rather, I decided to go even more precise and remember the exact level - and 1468e5e implements an improvement, where if the individual level has been removed, it'll go to the first unbeaten level (or first level, if all of them are beaten) in the same rank; if the entire rank is gone, the first unbeaten level in the pack. (In the case of ranks inside other ranks, it goes up one parent level at a time until it finds one that does exist.)

Commit dfc41be implements Strato's suggestion of being able to have a shortcut to individual packs. Shortcuts can be made to the pack as a whole, a rank, or even an individual level - this is a side effect, of that the most efficient way to write this was to re-use most of the code from Proxima's suggestion. If you've organised your "levels" folder into multiple subfolders with packs inside those, you can have a shortcut to one of these subfolders too*. Commit 639a886 adds a button in the level select menu, that can be used to create a shortcut to the currently selected level / pack.

What isn't going to happen: The option for a shortcut, that takes you to the last level you played in a specific pack. It's too much work to track this on a per-pack basis. The options are - you open NeoLemmix via the EXE file, and go to whichever was the active level last time you played. Or, you open NeoLemmix via a shortcut, and are taken to the first unsolved level in the target pack / rank (or an exact level, if the shortcut was created to a specific level).

* I would agree that this feature - including just the "you can organise inside subfolders" itself - is not a worthwhile feature to make a special effort to implement. However, this capability exists and should be (close to) 100% reliable, simply as a side effect of how pack organisation works.

Pages: [1] 2 3 ... 609