Someone has to say it.

Pretty much the same people always win LOTY and LDC. Here are the top 3 designers in every contest for the past 5 years. If listed twice, the designer placed in the top 3 with 2 separate levels. "/" denotes joint winners:

2023 LOTY: NieSch, Armani/Icho, (3rd place TBA)
LDC 29: Armani, kaywhyn, Icho
LDC 28: Kingshadow, Armani, Simon
2022 LOTY: Armani, Icho, Icho
LDC 27: Simon, Simon, NeiSch
LDC 26: NeiSch, NeiSch, Armani
LDC 25: Armani, Icho, (no 3rd place)
2021 LOTY: Nessy, Icho, Icho
LDC 24: tan x dx, Icho, Kingshadow
LDC 23: Kingshadow, Armani, (no 3rd place)
LOTY 2020: DireKrow, Armani, Icho
LDC 22: Armani, Nessy, (no 3rd place)
LDC 21: Icho, Armani/Armani, (no 3rd place)
LOTY 2019: Icho/Namida, Crane, Icho
LDC 20: DireKrow, Armani, (no 3rd place)
LDC 19: Icho/Flopsy, Armani, (no 3rd place)
LDC 18: Namida, Crane, (no 3rd place)

I've put the designers that only appear once in bold. There are only 3 unique designers out of a possible 51 (top 3 multiplied by 17 contests)

Here's the final stats for all 51 award slots:

Armani, Icho: 13 appearances each
NieSch: 4 appearances
Simon: 3 appearances
Crane, Kingshadow, Namida, Nessy: 2 appearances each
Flopsy, kaywhyn, tan x dx: 1 appearance each
(3rd place not awarded 7 times)

Firstly, congratulations to Armani and Icho for setting and maintaining the high standards of level creation that these contests enjoy - let's be clear that the quality of their levels is not in question here at all, nor is the value of their participation!

However, these 2 designers account for more than half of the total possible appearances in the top 3 of all contests. Honestly, we can probably be doing more to make sure other designers get a look-in, particularly when it comes to making it into the top 3.

In fairness, the actual 1st-place winner of each contest is more or less different each time, but the point here is that the pool itself is often very similar. This is particularly true when looking at the final round of each contest; it's nearly always the same 4 or 5 designers every time, with maybe the occasional wild card from someone who made a particularly good level that contest.

What I'd suggest is adapting the format of these contests slightly with the goals of (a) encouraging more participation, and (b) increasing the likelihood of different designers making it into the top 3. I'm sure that Armani and Icho will always be strong contenders, and rightly so, but we need to see other names up there more often than we are doing at the moment, otherwise more and more people will tune out, and this will only exacerbate/perpetuate the problem.

My hope is that the following suggestions will open the contests up a bit and ensure that, even if Armani and Icho always make the top 3, maybe that 3rd person will be someone different each time, and more designers will benefit from the encouragement of having had one of their levels make it to the finals.

---

On to the suggestions:

There were 7 contests in which a 3rd place wasn't awarded. Awarding Gold (1st), Silver (2nd) and Bronze (3rd) ought to be standard in every contest - this alone would ensure that more designers get to see their name in the top 3 slots.

In the case that 2 of the same designer's levels make it into the top 3, either choose only the one that got the most votes or (probably better) count them as a joint award for that slot, and award the next slot to the designer with the next highest amount of votes. Or, to put it another way, we're awarding the designer rather than the individual levels in this particular case, and so we can place equal recognition on both levels. However it ends up being formulated, the end result should be that no fewer than 3 designers end up in the final round. Example:

       Armani gets 8 votes for Level A and is awarded Gold (1st place)
       Icho gets 7 votes for Level B, 6 votes for Level C and is awarded Silver (2nd place) for both levels combined
       (SomeoneElse) gets 5 votes for Level D and is awarded Bronze (3rd place)

Better yet, only allow 1 entry per designer per contest, with the possible exception of LOTY. (EDIT: This suggestion has been updated in response to Armani's post)

If keeping the "3 rule" format, allow all 3 winners of the previous contest to choose 1 rule each, rather than the top spot winner choosing all 3. This in itself would likely incentivise more participation; making it into the top 3 suddenly means more, and a designer who manages to make it that far is rewarded for doing so. This is particularly meaningful when there are only 1 or 2 votes in the difference between the top 3, which is sometimes the case.

Alternatively, the "3 rule" format could either be reduced to 2 rules (maintain an element of choice whilst reducing workload and possible confusion for participants) or scrapped altogether in favour of a single rule (easiest to follow/maintain and could help make contests shorter, so they could be run more often and therefore provide more chances to win, but could also have the undesired side-effect of reducing participation due to lack of interest in the rule).

In many cases, LDC levels that placed in the top 3 also end up in the LOTY top 3 for that year. Perhaps implement a contest entry condition preventing the same level from entering 2 different contests. The level has already been awarded an accolade previously - giving it another award, whilst perhaps deserving, prevents other designers/levels from receiving recognition. Preventing this is an easy way to ensure that different levels (and, perhaps therefore different designers) get a fresh chance with each contest. And, if the same designer is awarded a LOTY top 3 place for a different level than their LDC top 3 place, it's a chance for that designer to be recognised for more of their work, arguably making the award more valuable to them personally. Conversely, perhaps we deem it necessary to bestow more recognition on a particularly good LDC winner. One way to achieve this would be to have a separate "Contest Level Of The Year" award, which pits all of that year's contest winners against each other for one final vote.

I hope these suggestions are useful. If nothing else, it might be worth trialling a few of them for the next few contests and see if it amounts to at least an uptick in participation. Or, if people don't think there's a problem with the way things are now and this just comes across as complaining, that's fine. Feel free to ignore this post and I'll go back to ignoring the Forum contests (it's not as if I haven't got plenty else to be getting on with!)

But seriously, I'm making these suggestions in the hopes that it might benefit other designers who are discouraged from participating due to thinking there's no chance of winning, or even simply due to confusion regarding the format. There's actually very little for me to gain here personally, I'm just being a voice.

Introducing Colour Swap, a free tool that allows you to batch-swap colours in multiple .png files simultaneously!



This will no doubt come in very handy for anyone creating styles/sprite sheets.

Instructions for use:

1. Select a folder containing images you want to colour-swap.
2. Add a colour swap to the swaps list using 6-digit hex codes for each colour (the codes are available in most image editors, or you can use this site).
3. Once you've populated the list, choose whether you want to overwrite the original files or save the modified images to a new "Colour Swaps" folder (saved within the original directory).
4. Hit the Swap Colours button!

It's also possible to save and load swaps lists for quickly recalling swaps for subsequent use, or for quickly generating a full list using a text editor.

Enjoy!

As of commit d57ee948c, wherever an Exit's trigger overlaps one or more other object triggers, the Exit will always take priority:



SuperLemmix now has a full "Exit Rules All" physics system; if ever a lemming makes contact with an Exit's trigger by whatever means, and time remains on the clock, they will exit regardless of current state or any other factors.

If anyone playing SuperLemmix notices any situation where exiting can be expected (however remotely) and doesn't happen, please let me know and I'll fix it as soon as possible.

Proposal: relax Builder checks so that they only stop building if they have terrain immediately overhead, or at their foot position during the "step up".

So:


^^^Correct, current behaviour - the lem's head has hit terrain, so they stop building and turn (yes, the turn is debateable, but will be kept if the proposed change goes ahead)


^^^Much more arbitrary - why did the lem stop building here*?? Let's do away with the need to spam builders to complete the bridge!


^^^This is better! They should keep building until the existing terrain prevents them from stepping up, at which point they stop and turn as usual

*NOTE: code-wise, the stop-and-turn at this point is because the Builder needs to check for terrain in front of them as well as overhead. In this scenario, though, the check is returning a false positive of sorts; the check needs to be less complex, then.

Clicking the button, or pressing [Enter], [Space], or double-clicking the replay event itself will skip the game to that replay event. Surrounding events are unaffected, and remain in the replay list so that other events can be subsequently skipped to.



Implemented in Commit 87af92086

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.

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.

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.