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 ... 44
To download all styles at once: (Last updated 2020-04-03; compatible with NL V12.8.X)
Note that this link will always point to the latest styles download, even if this post has not been updated accordingly.

To download any single style manually:
Replace "XXXXXXX" with the style's name. For example, for the "default" style.
Rather than manual downloads, you may want to try using the Style Manager in-game. This can also tell you when your styles need to be updated.

If you have created your own style and want it included in the NeoLemmix download, please PM me either with a copy of the style, or a link to where one can be obtained. Likewise, do the same when updated. Simply posting it in a topic here and/or including it with a download of your pack is NOT enough, as I do not actively monitor this board, nor do I look at every level pack released. Likewise, Discord messages get lost in the crowd of messages too easily, and it is not an appropriate means to inform me of updates. If you have not informed me via PM of a new / updated style, I don't want to hear a word of complaint about it not being included in the download. (If you HAVE informed me that way and I've forgotten, you are welcome to yell at me for it.)

Engine Bugs / Suggestions / [DISC][PLAYER] Styles cleanup
« on: March 26, 2020, 08:46:09 pm »
So, it seems when pieces that are in the wrong styles get moved to the right one, issues occur for some people, even though it works fine for others.

I strongly suspect the cause here is always that some people are ignoring advice to always set up a new, clean copy of NeoLemmix with all new major versions. I know for sure this has been the cause in at least some cases. (ie: You can overwrite 12.8.0 to upgrade to 12.8.1 or 12.8.2 etc; but when 12.9.0 comes, it should be a fresh setup, perhaps copying your Settings, Replays and Levels folder - but in particular not your Styles folder (if you have WIP or unreleased styles, copy *only* those individual ones) - across.)

Even in the case of experimental builds that say "install over existing stable version", this should be over a clean copy of the existing stable version.

This advice isn't given to make things difficult; it's because it's the easiest way to avoid version-incompatibility issues.

Firstly - to avoid this, I'll be implementing code in NeoLemmix to try and detect when people have ignored the "fresh install" advice. It won't outright prevent NeoLemmix working, but it will display a warning. Not debating this, especially given that it will just be a warning, not an outright blockade.

That aside though - any remaining cases that need to get moved to the right style, I want to do the rest of this all in one go so that it's over and done with, one round of cleanup, and we never have to worry about it again.

So - if you are aware of ANY cases where pieces are in the wrong style, let me know. For example, if there are pieces that have been added to a style without the approval of the style's authors (or that were approved at the time because it was prior to style-mixing being possible, but can now be seperated out); or if there are duplicate pieces that need de-duplication, or pieces that should belong in a different style (eg. moving the (anti)splat pads from namida_wasteland to default has been proposed). Let's try to get as many remaining cases of it as possible done before or alongside 12.9.0's release, so that we don't have to worry much about it again after that.

Only confirmed in-game; preview screen is untested.

NeoLemmix Main / EXPERIMENTAL BUILD: Jumper
« on: March 22, 2020, 11:04:58 am »
Jumper Experimental V5:

Usage - New install:
1. Download and set up a new copy of the stable version of NeoLemmix
2. Extract the above ZIP over the top of this new copy
3. If you update "default" or "xmas", whether it's via the style manager or otherwise, re-extract the "styles" folder from the above zip (to re-add the Jumper sprite)

Usage - Upgrade from earlier Jumper experimentals:
1. Extract the above ZIP over your existing Jumper experimental copy

A copy of the editor with Jumper support is included. It's otherwise identical to the current stable editor build.

This experimental should only be used to get a feel for how the Jumper works, or to test for bugs. While you can start making content if you like, be aware that all of the following are possible:
- The Jumper has further bugfixes (likely)
- The physics of the Jumper are changed, especially in regards to edge cases / interactions (possible)
- The Jumper gets delayed to V12.11.X (unlikely)
- The Jumper doesn't go ahead at all (extremely unlikely)

- No skill shadow has been implemented yet (Fixed in update on 2020-03-30)
- Object trigger checks for the "inbetween" positions each frame are awkward (Fixed in update on 2020-03-30)
- Bug: Cloner should be possible to assign to a Jumper, but it isn't (Fixed in update on 2020-03-25)
- Bug: Error message when jumper hits a wall as a non-climber from certain initial positions (Fixed in update on 2020-03-31)
- Bug: Shadow is incorrect on last frame in situations that would trigger above bug (Fixed in update on 2020-03-31)
- Bug: Error message when jumper hits a wall as a climber from certain initial positions (Fixed in update on 2020-04-05)
- Bug: Jumper sometimes unaffected by blockers or force fields (Fixed in update on 2020-04-05)

Would there be interest in having a "version" field for levels?

This would be plain-text, similar to the author / title fields. It wouldn't be displayed in game (at least the way I'm envisioning it - but I'm very open to displaying it if that's preferred), but would be saved in replay files - the intention being that it would enable authors to identify exactly which version of their level a replay was made for.

EDIT: Alternatively, it could be numeric and incremented by 1 every time the level is saved - maybe even including when undo history is saved. This could get really big quick, but presumably only a small number of versions would actually be distributed, so the author merely needs to keep a note of these (and not even that if using version control).

Lemmings Main / The oldest-known custom levels have been recovered.
« on: March 19, 2020, 10:29:29 pm »
As far as I can tell, the oldest custom levels known to exist are "New Year Lemmings 1991/92", a hacked version of Lemmings on Amiga with 5 levels.

A discussion on Discord sparked a search for the oldest custom levels, and this was the result. I've managed to extract these levels.

They don't look like they're very good. (EDIT: After actually playing them, I'd say the 2nd one is decent, the rest are pretty meh.) They're mostly a matter of historical interest more than anything else, but here they are, in both DOS LVL format (adjusted to fit the normal graphic set numbering scheme) and in the form of a NeoLemmix pack - take your pick. The NeoLemmix version has the usual pack-structure elements added, but the levels themself are unmodified aside from converting them to NL format.

Title says it all. Maybe also a feature that lets the user select another level, then tells the user if the other level has a different ID.

Download (V0.88):
Source code: (written in Lazarus 2.0.6)

Phart is a pixel art tool I've written for myself, primarily for use on my pen-input tablet. But - I figured, why not release it publicly too.

A help window will pop up the first time you run it; you can bring this up again by clicking the ? icon in the bottom-right. Anything you can't figure out from that or with a bit of trial-and-error, ask away.

Engine Bugs / Suggestions / [DISC][PLAYER] The final new skill
« on: March 12, 2020, 09:29:42 am »
Okay, so, let's have an official topic for discussion of what the final new skill might be - as I have said I'd like to add one more to bring the total to a nice 20.

I'll keep a list in this first post of anything I've (a) ruled out, (b) stated could be considered, or (c) seems to be a strong contender.

The earliest this skill will be added will be V12.11.0. It might be later.

Past topics that might be of interest here (note that this does not mean I'm actively supporting any suggestions within; just mentioning them as potentially of interest - some of these have outright been rejected already):
- It's time to work towards a "final" version.
- Joke ideas for skills and objects (Most of these won't be suitable, but some at least could be made into serious ideas)
- Downward construction vs upwards destruction
- General suggestion thread
- Add L2 skills to NeoLemmix?
- Upward Digging: Relevance, Required Effort, and Alternatives
- Ideas for skills
- New skill: Farter
- Superstacker / Lightsaberer proposal
- Hookshotter proposal
- Shielder proposal
- "Remove permanent skills" skill proposal

Ruled out
- Anything involving changing the direction of gravity - too complicated to implement
- Anything that requires further input beyond "select the skill, select a lemming" - again, too complicated to implement
- Anything that has widespread effects on other skills used by the lemming (but "has one or two edge cases" or "has a special interaction with one or two other skills" is okay), including changing the speed of all actions in general
- Anything involving random or highly-chaotic factors (come on, I shouldn't have even needed to state this!)
- Skills that are identical to existing ones, except in terms of whether or not they're fatal to the lemming
- Reviving the Ghost feature as a skill - too complicated to implement, and ghosts proved to be not particularly useful in practice
- All L2 skills not listed below
- Skateboarder (see reply #2)
- Permanent-skill-remover skill - only ruled out as a skill, I'm still open to this as an object but that's a discussion for another time
- Rock Climber
- Runner
- Girderer (see reply #32)
- Sleeper (see reply #80)

Willing to consider
- Creator (see reply #96; will need a better name if used)
- Downward builder
- Gunner (kills zombies at a range), or another zombie-killing skill, perhaps with other effects
- Hookshooter
- Laser-Blaster
- Resetter, or some reasonable variation thereof (see reply #80)
- Rocketer (see this topic) or some variation thereof
- Shielder
- Tank (zombieproof / trapproof / fireproof, but not waterproof, lemming)
- Tunneller (upwards digger or ultra-steep upwards diagonal destructive)

Strong contenders
- Projectile construction skill (such as Spear-Thrower)
- Projectile destructive skill (such as Bazooka or Mortar)
- Slider (Dedicated topic:

Also doable with other skills, but miner is what I discovered this with (while testing to see if a certain other bug happens - the other bug I suspected did not actually happen).

See attached level for an example - assign the miner towards the right just before hitting the wall, with the first lemming (there's steel placed to prevent assigning too early for the correct position to trigger this).

After some examination of the code, I've determined the reason for this - different skills may move the lemming downwards by different amounts before transitioning to a faller, ranging from 0 to 3 pixels. This was the cause of the fall distance difference between walkers vs bashers/miners in DOS, but NL has long since fixed that side of things - splat distance is consistent. Then, the lemming pulls out the glider - theoretically - after falling 7 pixels. Even for this - NL correctly tracks it regardless of the downwards movement at the start.

The bug arises from the fact that a faller falls 3 pixels per frame, but the "do I become a glider now?" check only happens once per frame (before any downwards movement). If the downwards movement before transitioning to faller is 0 or 3,  then the lemming will fall a total of 9 pixels before transitioning (as on the first frame it will have fallen 0, the second frame 3, the third frame 6 - none of which are enough to start gliding yet); whereas if it's 1 or 2, they'll only fall 7 or 8 pixels respectively (1, 4, 7 or 2, 5, 8 respectively).

As of a few versions back (12.6 IIRC), NeoLemmix allowed players to enter a username. This name is saved into replay files, and is used to identify your own replays vs other people's so that your records don't get overwritten from watching other people's replays.

Recently, a bug has arisen specifically in cases where people do not have a username entered. Prior to this, no bugs were known, but of course the "your replays vs others' replays" distinction couldn't be made when no username is entered - which did need additional code specifically to handle it.

The obvious solution here is to simply not allow no username. This could either be via specifically rejecting such input, or alternatively, by generating a random string of letters / numbers if the user does not enter a username / if the config file doesn't contain one / etc.

Does anyone feel there is a strong reason why this change should not occur? Keep in mind that nothing forces you to use your real name (or your forum username; you could literally just enter a random string of characters) in the username field.

May only apply to ones that are offset and/or different sizes; not sure yet.

Engine Bugs / Suggestions / [DISC.][PLAYER] Jumper physics
« on: February 26, 2020, 12:59:56 am »
So, the plan is for V12.9.X to introduce the Jumper skill. Thus, it's time to figure out how this skill will work.

Some discussion has already been had on Discord. I provided two sample images (1st and 2nd attachments here) for the width / height of the jump respectively, and asked people what their instinctive reactions are re: what the jumper should / shouldn't be able to do.

For width - I felt that the 32px gap should be a near-miss, but others all felt it should be crossable.

For height - I felt 16px should definitely be possible to jump and land on, but 20px maybe should not (with 24px being a definite no). There was some disagreement about whether 16px should be, but it seemed to lean more towards "yes, it should be" overall.

To avoid a 32px gap needing too much precision, 36px was proposed as the width. I like this suggestion. For reference, this is very slightly shorter than a platformer bridge (which is 39px).

This lead to 18px being proposed as the figure for the height - partly due to being exactly half the width, and also because it's exactly between the "should be reachable" 16 and "should not be reachable" 20.

The other details that came up:
- Jumper -> Hoister transition, for near-misses with regards to height. This would allow the 20px block to be ascendable - but with a hoister transition in the process.
- Head checks. These should be similar to the builder or shimmier checks.

The third attached graphic is how a jumper assignment, based on 36px length / 18px height, would play out in various places in some of the Fun levels. Note that while this graphic takes the Jumper-Hoister proposal into account, it does NOT take head checks into account. (You may want to open the image in a viewer tool and zoom in a bit.)

Overall, I very much like the general nature of this proposal, but I am open to tweaks to the specifics (or even to larger tweaks, if there's enough support for them - maybe someone will suggest a brilliant idea that hasn't been considered yet, for example).

It looks like no one has a problem with the suggested 36 x 18 trajectory. Some other questions that came up:

Would a glider glide at the top of the jump arc, or after the full jump is complete?

If a climber jumps into a wall, would it start climbing, or simply fall? Can a climber jump away from a wall?

If a jumper hits the ceiling, would it be possible to transition to a shimmier?

See reply #13 for my thoughts on these.

Reply #24 has made some decisions: Jumper-Climbers grabbing and climbing a wall mid-jump will be allowed; as will Jumpers grabbing a ceiling to shimmy. On the other hand, Jumper->Walker and Swimmer->Jumper will not be allowed.

Still remaining open are:
- Should a Jumper-Glider start gliding at the peak of the jump or at the end?
- Should the splat distance be counted from the top of the jump or the end?
- If a Jumper hits a wall mid-jump, should he fall facing the same direction, or turn around (and still fall)?
- Should it be possible to assign a Jumper to a climbing lemming (to "wall-jump")?
- Should updrafts affect Jumpers, and if so, how?

As of reply #51, poll results suggest jumpers turning around upon hitting a wall is favored. A new poll has been put up to confirm whether this is "turn around and continue the jump", or "turn around and fall" - but I'll note I'm leaning strongly towards the latter.

Further polls have suggested "turn around and fall", and ruled out the possibility of transitioning automatically to a "slider".

There's significant preference for allowing wall-jumping, and gliding from the top of the jump arc.

Current status as at post #96:
- Jumper<->Climber transitions are allowed, in both directions.
- Swimmer -> Jumper transition will not be allowed.
- Jumpers cannot be cancelled with a Walker, and cannot cancel a Blocker.
- Jumper will turn around and immediately fall upon hitting a wall (unless the Jumper is a climber).
- Fall distance is measured from the point of transition to a Faller.
- Gliding begins from the top of the arc (or if the Glider is assigned after this point, it begins immediately upon assignment).
- Jumpers will not be affected by updrafts.
- Double-jump and/or Faller->Jumper transition will not be allowed.

Post #97 has a detailed list of interactions with other states:

A Jumper experimental build has been released:

Specific case: Any style using the lemming sprites from gigalem_millas seems to reproduce this issue in low-res mode only. Can confirm that xmas, and default with or without recoloring, do not reproduce it, in either resolution.

Instead of displaying as it should, it only shows a single lemming facing right. It can still be distinguished from the Walker pickup by the positioning of the lemming, though this is a very subtle difference. (See attachment - left = walker; right = cloner.)

For example - if I create a level with a talisman that has two conditions, "Use only Fencers" and "Use no more than 4 Fencers", the talisman condition text on the level preview screen (and presumably the talisman list screen as well) is glitched, and simply says "Complete" (without listing any further conditions).

This is purely a bug with the displayed text explaining the condition. The actual talisman itself still works fine - it will be awarded when it should be, and not when it shouldn't.

Pages: [1] 2 3 ... 44