To download all styles at once: https://www.neolemmix.com/download.php?program=52 (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: https://www.neolemmix.com/styles/12.8/XXXXXXX.zip
Replace "XXXXXXX" with the style's name. For example, https://www.neolemmix.com/styles/12.8/default.zip 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.)

Only confirmed in-game; preview screen is untested.

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).

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.

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: https://www.lemmingsforums.net/index.php?topic=4713.0)

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.

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: https://www.lemmingsforums.net/index.php?topic=4656.msg80439#msg80439

A Jumper experimental build has been released: https://www.lemmingsforums.net/index.php?topic=4718.0

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.