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 - WillLem

Pages: [1] 2 3 ... 22
Before (Player):

After (Player):

Before (Editor):

After(Editor) - note that multiway resizable objects (i.e. water) are still incorrect - this will be fixed soon:

The repositioning bug seems to have been caused by an ancient bugfix that was later addressed elsewhere in the code, but the original bugfix wasn't updated to match.

Player-side, we'll have to watch out for any existing levels which contain flipped/rotated/inverted objects - OWWs are all fine because they're exact squares, but basically all other objects may now have triggers in a slightly different (but, actually correct!) position as a result of this update. Thankfully, this is being done before there's too much made-for-SLX content. I only have a small handful of levels which are affected by this and it's been very easy to fix them.

Editor-side, the only remaining bug is that resizable objects' triggers are still not resized properly (note the water objects in the above screenshots) - I'll get this fixed ASAP.

When replacing the title of a post, sometimes it's desirable to change every reply's title to the same replacement (albeit with [Re:] prepended).

Can this option be added for mods?

Found a particularly nasty bug today when running tests on the SLX Replay Manager (which is essentially a re-skinned version of the existing NL Replay Renamer with a couple of extra features), and discovered that it exists in the engine as far back as NL 12.12.5.

To say the MRC deletes the files is somewhat incorrect. It does delete them, but this behaviour is actually correct. The bug is that the newly-generated replays are being saved over each other iff they have the same filename.

Steps to reproduce:

1) Unzip the attached Replay Check Batch to a new folder in "levels"
2) Run MRC on the replays within the folder, making sure to choose "move to" or "copy to" (choose Position + Timestamp to make it more likely that the buggy behaviour will occur, but it can occur for any renaming string)
3) Some of the replays won't have been saved (well, actually, they have been saved, but they overwrite each other because they have the same filename)

This is most likely occurring because the timestamp used for renaming is that of the replay check time rather than the timestamp on the original replay.

Suggestions for fixes:

1) Add an incrementing alphabet character to the timestamp iff the current timestamp has already been used (so, for example, __2024-06-05_15-26-51.  __2024-06-05_15-26-51A,  __2024-06-05_15-26-51B, etc)

2) Retain the timestamp of the original replay and use that instead (arguably, this should be happening anyway)

3) Check to see if the current "NewName" has already been used in the current replay check. If it has, add an alphanumeric character to the end of the replay name (so "NewName := NewName + i; Inc(i); or generate a random short string of digits) - essentially the same as suggestion (1), but we're taking the full replay name into account rather than just the timestamp

I'll likely go ahead and apply whichever of these fixes proves to be easiest in SLX, happy to do a PR if it tests working.

Paiy has reported two levels not awarding the "No Pause" talisman (on Discord). I also noticed this happening several times whilst playtesting Lemminas Origins, and did attempt to fix it in commits 00989847d - b76c92531. It seemed fairly watertight after that, but since paiy has confirmed being on the latest version of SLX (2.7.3) and playing without pressing pause or loading a replay, it's clear that more needs to be done.

Currently, the No Pause talisman fails in any of the following conditions:

1) Pause was pressed at any time during playing the level
2) A replay of the level was loaded at any time

Checking for pause is not a problem: if the pause button or hotkey is pressed, a flag is set to true and it remains true until the end of the level, at which point the talisman is failed. If the user restarts the level, the flag is set to false.

What's more likely to be the issue here is checking for a replay having been loaded. Many in-game actions can cause a replay to be inadvertently loaded (backstepping, rewinding, restarting, even changing the release rate) and it's very difficult to keep track of them all for the purposes of this talisman.

Maybe, then, we should only check for a replay being loaded if it's explicitly loaded from a replay file. In all other cases, we check only for button/hotkey presses (backstep, rewind, restart) to determine whether this action should fail the talisman:

Backstep and rewind should, obviously. Restart should only fail it iff the user has "replay after restart" behaviour activated and pause was pressed at any time during play - furthermore, we already allow 55 frames' grace to cancel a replay if the player paused, restarted (with replay after restart activated), and then cancelled immediately - in real terms, the player has until the music starts to cancel.

From a quick look at the code, the "replay was loaded" flag (which fails the talisman) is set to true and false in lots of places, likely due to the number of actions that can trigger a replay load. This is not good, and shows that we need a more watertight solution.

So, I propose two fixes for this:

:lemming: The first is to remove the "replay was loaded" flag and replace it with something which only tracks player input - no automatic in-game processing events should be responsible for failing the talisman.

:lemming: The second is to draw some sort of marker to the panel to explicitly show the status of "no pause" - visual feedback provides the player with assurace that their playthrough will pass the talisman, whilst also making it easier to find the cause of any bugs, should they arise in the future.


Clickables and UP/DOWN hotkeys added to the MRC output screen. Doesn't really provide any additional value than simply looking at the text file tbf, just wanted to see if it could be done. If nothing else, it's practice working with the menu screens.

SuperLemmix Bugs & Suggestions / [SUG] New Level Select menu
« on: May 25, 2024, 04:00:56 PM »
Dreaming of a new Level Select menu free of Windows dependencies/forms. There might be no going back from these gorgeous mockups, but even if I do make a start on this it will likely take a long time and potentially cause sizing issues; I'd want the text to be at least medium-res, which would mean increasing the minimum size that the SLX window can be.

Even so, let's just enjoy imagining the possibilities for now:

Each pack would have its own preview button, complete with player progress info. Any Talismans would simply be grouped by colour (Bronze, Silver, Gold) and only "lit" once all Talismans of that colour have been achieved for the full pack. Perhaps clicking the Talismans could bring up a list, as per the current default pack display.

Clicking a level pack would select it for Play / MRC / Playback / Cleanse / Shortcut-creation purposes. Clicking an already-selected level pack (or Single-left-clicking the "List" icon (bottom left of each level pack preview)) would open the levels list view:

Each group would be clickable - clicking it displays the list of levels in that group. Info for the currently-selected level would be shown on the right, with options for Play, Screenshot, Cleanse, etc. displayed across the bottom. All very similar to what we have now but built into the game window rather than relying on a popup Level Select form.

Thoughts welcome.

This bug is present in both 12.13-RC and SLX, reporting it here because it'll need to be fixed for both.

The problem lies in the SavePngStream method in PngInterface.Pas - it's one of the methods Anders updated, seemingly making use of an updated PNGWriter.

Best guess: old PNG-saving code needs to be updated. Investigating, I'll post here if I manage to find a fix.

From this closed NL bug.

@Crane - can you remember exactly how you managed to set this up in your screenshots? I'm having difficulty replicating exactly what you have there.

However, I have noticed that this happens, and I wonder if it's one and the same bug:

Left: Fencer seems to be able to continue past the steel | Right: Fencer has found steel and stopped working, but walks forwards rather than turning, and the "chink" sound isn't cued

I'll try to find a fix for this.

Refactored the animations loading today. Moved incidentals such as countdown digits, highlight arrow and pickup/hatch/exit numbers to the "effects" folder in styles/default. This means that they can now be customised per-style. It also means that gfx/masks now contains only essential, non-customisable graphics for rendering skill actions in-game.

LemAnimationSet's ReadData is now renamed to PrepareAnimations, and has been refactored for readability.

This has come about in part due to the way that Exit Markers are handled (still a work in progress for now, but getting to a more settled place), but also because with grenades, spears, balloon pop, Freezer overlays, invincibility overlays, etc, this procedure is getting increasingly busy. Well, that's been improved now and the code is much more streamlined. I've also renamed some variables to make it clearer what's happening throughout, particularly where the sprites are loaded.

This post is really just to log the change publicly and make a note of the commit for future reference. (Simon showed me how to rebase commits recently, and it's been an absolute game changer for my natural workflow.)

Squashed all associated commits to 0b9c489b8.

Whilst working on the Rivals feature, it's become clear that we need a way to visually represent pre-assignment of skills and other properties to (at least) Hatches, Pre-placed Lemmings, and (if Rivals are implemented) Exits.

I wonder if this has ever been suggested or discussed before, because it seems like a no-brainer. However, the Editor can sometimes be quite difficult to work with, particularly when it comes to adding something completely new. I can see why it may have been intentionally avoided in favour of simply using the checkboxes in the Piece selection tab to see what's what.

Anyway, Pickup skills have a placeholder image inserted, and this image can be updated on the fly. I've examined this in some detail so far, but can't quite figure out how it's done. As far as I can tell, all the object data is updated when (and only when) a new style is loaded into the Editor. The checkboxes don't seem to have any bearing on the placeholder image in-code, even though they clearly do in-use. I'm probably missing something very simple, but it's not for lack of trying.

If anyone knows C# and wants to help me have a look at this, I'd be very grateful (and, likely, so would many Editor users in the future!). Failing that, this can be something I revisit every now and again and hopefully, eventually, find a solution for.

From a conversation with Simon on Mumble. He suggested that Zombies might un-push Buttons, which I think is a great idea. :thumbsup:

I liked the idea so much that was about to go ahead and implement the change immediately, but he then pointed out that it would mean they shouldn't then interact with Buttons in their regular state, and also asked what should happen if the Exit is already unlocked.

The first of these points does present an interesting issue - Zombies can now exit, so it's in their interest to push buttons to unlock the Exit (it's one of the reasons I implemented Zombie interaction with buttons in the first place). However, their presence in the level is generally negative - they eat pickups, count as -1 towards the save requirement, ignore skill assignments, and zombify other lems. So, it makes sense that their interaction with buttons should also be negative. More discussion is needed on this.

Meanwhile, if the Exit is already unlocked, it should of course be re-locked if a Button is un-pressed. We'd have to display the unlocking animation in reverse (easy enough, hopefully), but it might not be as simple as even that.

Discussion welcome!

SuperLemmix / [FEAT][DISC] Replay Manager
« on: April 23, 2024, 12:43:56 PM »
First things first, the dialog is now larger and edited for readability. I've also added an option to append the replay file with a result tag (Passed, Talisman, Undetermined, etc...), and it works nicely:

Note that the tag is replaced for subsequent checks, even if "Keep Existing Filename" is checked (the first part of the filename will remain unchanged, as usual).

My question here is, should this option be checked by default? I would lean towards yes, but I can see reasons why people might not want this.

I have found that sometimes the mouse cursor will revert to the Lemming hand cursor used in the title screen instead of the Windows mouse pointer ... I have experienced this if the Level Select screen is on-screen and then Alt-Tab or the Windows key is used to switch back to the desktop/another app, and then switched back to SLX.

From a quick look at the code, I can't see anything that would be causing this and I haven't been able to replicate the bug.

If possible, can you give a step-by-step of exactly what leads to this happening as this would greatly help me to find a possible cause (and therefore a fix).

Does it happen in NeoLemmix with the NL menu screen cursor? Has anyone else experienced this?


The original Lemmings game, but with Lemminas sprites!

More than 5 years in the making, this pack features my favourite levels from the debut DMA Lemmings game we all know and love, some presented as they were originally and others remixed slightly, plus a handful of levels that I've been working on since I first became active on the Forums back in 2019!

The levels all feature the Lemminas sprite set that we're all familiar with by now - female Lemmings with their hair in a swish, ready-for-action ponytail. They're presented here in the "classic" recolouring, with blue tunics and green hair.

Please note that this is a SuperLemmix-exclusive pack.

As well as featuring Timebombers in place of Instabombers, all levels feature at least one Talisman that requires Classic Mode for completion, and all water objects have been updated to their SLX counterparts. I have absolutely considered releasing a NeoLemmix version of this pack with Instabombers, no Talismans and the water objects reverted, but ultimately I believe that SuperLemmix is the most ideal platform on which to enjoy this pack as intended.

In fact, this pack is one of the reasons I began work on SuperLemmix in the first place! I wanted these levels to be played on a Lemmings engine that could provide an experience as close to the original Amiga game as possible whilst also providing the player assists and QOL features we've all become accustomed to, and SuperLemmix finally fits that model as well as it can. It's been an incredible learning experience and a journey of both discovery and re-discovery, and... here we are, at last!

So... with all of that said, let's take a look at Lemminas Origins... :lemcat:


For the most part, the levels themselves are identical to the originals, however some of them have modified skillsets, whilst others have had their layouts remixed.

:lemming: Some of the levels have had subtle layout changes:

Tricky 9 All The 9s

Taxing 4 Compression Method 2

:lemming: Whilst others have been more extensively re-shaped:

Tricky 15 Lost Something?

Taxing 11 X Marks The Spot

:lemming: And Tightrope City has been given a bit of visual TLC:

Tricky 17 Tightrope City

:lemming: Backroutes have been fixed where appropriate:

Taxing 1 If At First You Don't Succeed...

Taxing 14 Take A Running Jump.....

:lemming: There are also a number of brand new levels, made exclusively for this pack:

Mayhem 22 Nothing is Impossible

Mayhem 26 What The...?

Taxing 26 As Complicated As It Looks

I hope you enjoy this pack! Feel free to use the Lemminas sprites and music for your own levels, but be sure to credit me if you do so. Thank you!

Music Credits

Included with this pack is 10 star-gazing, head-bopping, toe-tapping tunes, arranged and produced especially for the Lemminas style :lemcat: All tracks have been arranged and produced by me using Logic Pro X, composer credits as follows:

Music composition credits (click to show/hide)

To install, simply unzip the folder to your SuperLemmix directory; it contains everything you need to run the game:

:lemming: levels - the levels themselves, plus the menu cards and skill panel graphics
:lemming: music - the 10 new music tracks (see above for credits)
:lemming: replays - a full set of replays generated during playtesting

It is strongly recommended that you play this pack with SuperLemmix version 2.7.3 or later, ideally with Classic Mode and Hi-Resolution graphics activated.

SuperLemmix / [FEAT] Cursor flicker trick
« on: April 17, 2024, 01:23:10 AM »
I've decided to implement the Amiga "cursor flicker" trick. This will come in very handy when trying to get a lem facing a certain direction in Classic Mode; since this mode aims to closely reproduce the OG experience, this is pretty much a necessary part of it.

Clear physics shows it best - note that the directional arrow only faces left when the cursor is flickering to the right of a group of lemmings:

Commit b432a5bbe implements this feature

And whilst we're on the subject, here's a new trick for you - since lem recolouring for athletes is kept active in Classic Mode, assign a Floater or some other permaskill to one of the lemmings in a group, and this lemming will now visually stand out from the crowd! From there, it's very easy to see which direction that lemming is facing in, and whereabouts they are! ;P

Pages: [1] 2 3 ... 22