OGG Converter is a simple audio processing tool that converts most common audio formats (MP3, WAV, M4A, etc) to lossless OGG Vorbis format.

The main benefit of this is reduced file size without losing any audio quality. Ideal for storing large quantities of audio files, and also for processing music/sound for your lemmings level packs!

The program is very simple: just click "Select Files" to choose the files you want to convert, and "Convert" to convert them!

Things to note:

OGG Converter is 32-bit, but should work on both 32 and 64-bit Windows operating systems - let me know if it doesn't.

The conversion process doesn't delete or overwrite the original source file (yet), so this must be done manually unless you wish to keep both files.

Supported formats: Unfortunately, MOD and IT formats currently aren't supported due to either not being able to load, or errors during the conversion process. The most common audio formats, such as WAV, MP3, M4A, AAC and FLAC should all work just fine.

Please let me know if you have any questions or issues.

---

DISCLAIMER: Whilst I have done my best to fully test this program before releasing it, I cannot make any guarantees about its stability at this early stage in its development. It's best to backup your files first before processing them using this tool, and then check that the resulting files work correctly before deleting the originals (should you wish to do so). I cannot accept any responsibility whatsoever for any loss of data you may experience as a result of using this tool.

From this topic - the bug being reported is that assigning a new skill in "Blue R" (Replay Insert) mode silently overwrites any other skill assignments to other lems on that frame. I usually get around it by framestepping forwards and backwards to make sure I'm not going to overwrite an assignment, but - when I think about it - that's a pretty naff thing to have to do.

So, my thoughts are that one of 2 things should happen here, and one of them will be added to the SuperLemmix wish list in due course:

1) The old assignment should be detected, and the new assignment shouldn't be allowed. Now that we have the Assign Fail sound, this sound can be used here to signify that there is some reason the assignment can't be performed on that frame. An onscreen graphic saying "there is already an assignment on this frame" could also be helpful.

2) Both assignments should be allowed. Since Namida has described this as a "change of ... magnitude", I imagine that either it's something that will take a lot of time and effort to implement, or something that could open up the engine to a lot of bugs, or something that just isn't easy to figure out how to do. Since I'm now more familiar with the codebase, I know a bit more about how the replay system works, but not enough to take on something like this without a bit of help.

So, it's really a case of - which do we prefer?

If the former, I can't imagine that being too difficult to set up. Create a new flag whenever a successful assignment is made, and then check for that flag when making new assignments in Replay Insert mode - there's likely a bit more to it than that, but I at least have some idea how to get started.

If the latter, then I'll need help looking at it and figuring out what the first step is. Maybe Simon and I can add it to the list of things we may look at together? Mayba Namida won't mind casting a quick eye over it - if you can get me started, I'll figure out the rest?

Meanwhile, I do need to find ways to make some of the game features a bit more prominent. Onscreen graphics is one way to achieve this, but I'm having a lot of trouble figuring out exactly how to do this. Windows "Show Message" is easy enough, but not very video-gamey. I'll keep looking into it, because there are now several aspects of the game which probably need it.

An invincible lem would, I imagine:

Have cyclic-colour-changing hair and tunic (like objects in Clear Physics Mode)
Be able to survive any fall, regardless of distance or whether a splat pad is used
Be able to swim in water even if not a swimmer
Be immune to traps
Be immune to zombies
Not reduce the skill count when skills are assigned to them (so, effectively, all skills are infinite for invincible lems)
Ascend out of the ice cube if assigned a Freezer

And, things I'm less sure about:

Should they basically take on all permanent skills, and so climb/slide when they reach a wall as well as being able to swim? Leaning towards "no" if only because the Slider has its odd physics limitations that ought not be a problem for an invincible lem
How should the invincibility state be limited? Time would be one way, but perhaps invincible lems can't exit?
Should they ignore blockers?
If assigned a (time)bomber, should they "explode" (creating a crater), but not actually explode, and instead carry on walking? Or, should they die? Or, should they be non-bomber-assignable?
How should the state begin? A collectible item within the level that only affects the lem who collects it? Assignable by the player after the ability to assign invincibility has been obtained somehow? Assigned via an invincibility-assigning object?
Should they be able to destroy steel? (leaning very much towards "yes" for this)

And, any other ideas?

As of SuperLemmix 2.4, lemmings are now drawn on 2 different, adjacent, layers. This is so that we can have certain lemming states always appear behind other lemmings, regardless of where they are in the lemming index.

An obvious example of where this is beneficial is the exploder states. The explosion graphic is large, and even though it only appears for a single frame, it may be useful when fine-editing a replay to be able to see exactly what's going on with the nearby active lemmings:


Freezer explosion - note the other lems walking in front of the explosion graphic, even though the Freezer is "earlier" than them in the index, and so would normally appear above them.


Timebomber explosion - note that other lems, including the Freezer lem in the ice cube, appear above the explosion graphic.


Grenader explosion (it's a bit clearer here that the Frozen lem appears in front - we want this, since it's better to be able to see the position of the Frozen lem for that single frame, and the grenade destroys the ice cube anyway).

Freezer lems are actually drawn on the same "lower" layer as the explosion graphics. In the above examples, the indexing draws the Freezer lems first because they existed "earlier" and so are drawn further forward. Conversely, in this following example, the Freezer appears behind the other lemmings despite existing "earlier", because the other lems are being drawn on the "higher" layer:



This was done primarily to fix a bug where the Frozen lems appeared in front of lems that existed later, thus breaking the illusion of them being inside the ice cube. Rather than mess about with the indexing itself, it seemed a better idea to simply draw them on a lower layer.

Then, it seemed a good idea to also draw other explosion-related lemming states here - currently, all Freezer states, ohnoer, and all explosion graphics are drawn on the lower layer. We can extend this idea to other lemming states as well, if needs be.

This is an edited version of namida's NLQuickMod tool, which can be used to edit values such as the lemming count, time limit and even entire skillset for multiple levels simultaneously. It's a great tool, especially useful for making remix/challenge/test packs.

For the SuperLemmix version, I've updated the skillset to include the new skills and tweaked the layout a bit. See future posts for any other changes.

Get the latest version here.

I really can't decide on this one...

I made a very silly video a few years ago (back when my beard was huge!) which more or less sums up the problem I have with "steel is only steel when it's visible" - basically, despite it being a much more consistent way to handle steel areas in a level (I can fully admit that it removes the need for CPM in all but the most trollish and/or visually unclear levels), it's also very unintuitive to anyone who isn't yet familiar with this particular steel behaviour.

Moreover, it also doesn't prevent steel from being used in a trolly way; it's still possible to make steel pieces that don't look like steel, terrain pieces that do, and it's even possible to do this using the official styles (group a steel block with a bunch of erasers so that only 1px of not-metal-coloured steel is visible, and then use that pixel to build a steel area, etc). So, whilst it might be a tad more cumbersome to troll a player with hidden/disguised steel, it is still possible. Here's an example (from the Crystal set) - see if you can guess which is the steel piece:



What we have now is better than the OGs either way: no longer do we have those problematic "steel areas" that need to be managed separately: a steel piece is simply labelled as steel and that's that. Much better!

The question then becomes: should it always be steel, or sometimes not be steel if it's overlapped with destructible terrain? The answer is, really - "it depends", which means that it's very difficult to make a decision on this.

If we keep it the way it is, then steel can sometimes be seemingly destroyed, which to me doesn't feel right even though I'm familiar with the behaviour and understand its implementation and purpose. It feels better to have the steel behave as expected and not be destructible at all, wherever it may exist in the level, and whatever is overlapping it.

However, if we change it to "always steel" behaviour, then suddenly it becomes necessary to use CPM to see exactly where the boundaries are, and this isn't something that feels right either. Even if CPM were removed from the game (which Classic Mode does), it becomes a possible source of unnecessary frustration again to the "picture puzzlers", who prefer everything to be exactly as it seems right from the beginning.

It could absolutely be argued, though, that a partially-obscured steel block being destructible in only that obscured area gets more and more "not as it seems" the smaller the obscuring area is - especially if it's a 1px-wide thread cutting through the centre of the steel block, for example.

Ultimately, it's a chase-the-tail argument which doesn't really have a way to keep both points of view satisfied.

What might be worth looking into is whether the terrain-over-steel can be destroyed, revealing the previously-obscured steel block underneath (for example if a bomber or basher is assigned close enough for the destruction mask to make contact with the overlapping terrain). This would certainly look a lot better, but doesn't completely address the associated concerns. I'm also not 100% sure how to handle this; it perhaps becomes necessary to draw the steel onto another layer (or maybe draw it twice - once as destructible terrain, and again on a deeper layer as actual steel...?)

Basically, I need help with this one; it's not a clear cut case either way from my point of view, and so feedback is going to make a big difference on which way this one swings. All I'd ask is that you think of this from a fresh, conceptual, aesthetic and gameplay-oriented perspective rather than tying the argument up with concerns about existing content or sameness with any other Lemmings clone, port or engine.

---

NOTE: Programming-wise, this change comes down to a single word in the entire code - so, it wouldn't be out of the question to trial the proposed "steel is always steel" behaviour for a while and see how we like it. Changing it back would take seconds.

I've always thought that it should be possible to scroll horizontally & vertically by combining modifier keys with the mousewheel, so this is now implemented as of commit 98bbcdc.

Ctrl + Mousewheel scrolls the level horizontally (when zoomed in)
Alt + Mousewheel scrolls the level vertically (again, when zoomed in)

This feature will be available in Editor 2.3, coming soon.

---

On a somewhat related note (and in case anyone missed the video showing this), it's also now possible to move pieces only-horizontally or only-vertically with the following:

i) Select the pieces you wish to move
ii) Press Ctri + Alt, then move the pieces, for horizontal-only movement (along the X axis)
or
ii) Press Ctrl + Shift, then move the pieces, for vertical-only movement (along the Y axis)

This feature is currently available (as of Editor 2.2)

From a video posted by ericderkovits on YouTube:

Here is a test level showing a lemming won't explode but just leave the bottom of the level if the blasticine object is placed too low. No issues with Rock's vinewater, Marble's poison or Fire's lava objects as the lemming dies at the top of the objects.
For the lemming to explode on the blasticine, it needs to be placed higher, so the lemming will hit the trigger point.
I discovered this by accident in a lemmings reunion level (Nightmare 28-Cranking the stress) where the lemming doesn't explode on the blasticine.