[DISCUSSION][PLAYER] New behaviour for invalid replay assignments

[IchoTolot]

Alright time to report some problems I found:

1.)
I was greeted upon checking United with the following error:
TBaseAnimationSet: Error loading lemming animation metadata for REACHER. Falling back to default lemming sprites.

I think I know why: It was a highland level and I never used any of the custom sprites for highland,shadow,.... now they seem to be seeked out as default and I don't have the animations. Proposed solutions: Either don't treat them as default or include the nessesary animations in the main download.

2.)
And here is the big thing: Your sins will come to haunt you and the sleepers will arise in your replay database!

The devil lies here:

> Failed skill assignments from replays are queued instead of discarded

Every time you had to fix/alter a level it could be the case that an assignment in the old replay became impossible and was therefore discarded. So you fixed/altered your replay to the new version of the level, but the sleeper is still there and now the old failed skill assignments of the past come back to haunt you, leaving your replay database in shambles.

I fixed my replays for my packs for for the other packs I solved my replay database is now let's say unreliable.

I would propose: Failed skill assignments from replays are discarded again.

[Strato Incendus]

Okay, 2) ist a big one indeed - I guess it's even worse when using Old-Formats replay files, since those are not text-based, i.e. you can't even tell that easily whether there are any covert skill assignments in them? For example, SEB Lems is a pack I started playing in Old Formats before transitioning to New Formats, so a lot of my replays are Old Formats.

With regards to the missing Shimmier (and Reacher) sprites: Yep, some people still haven't brushed up on their custom sprites, sadly. It's definitely true for Nessy's sprites (Highland, Shadow, and Machine), maybe also for Arty's (Underwater and Silhouette)? Christmas sprites don't have Shimmiers, either, because those require more work than merely recolouring standard lemmings.

Since I did my reshadings with ancient Photoshop 7.0, I can only use the "replace colour" feature in a way relative to the original colour schema, rather than picking a specific colour with the colour picker tool from an existing image of, let's say, Nessy's Highland sprites, to recolour the Shimmier and Reacher in exactly the same shade of red.

Though I remember someone here told me about a software a while ago that can indeed replace a colour with an existing colour (aside from manually using the "fill" tool with literal pixel precision), and I also remember installing said software. I think it was Paint.Net?

EDIT: Yes, it was! So if Nessy can't find the time to include Shimmiers and Reachers into his three sprite types, maybe I can take a look at this. I would refrain from creating the Christmas Shimmiers, because require actual spriting by hand, but if it's merely about recolouring and then submitting the .pngs, as long as it doesn't take ages to figure out how this is done in Paint.Net compared to Photoshop, I should be able to do that.

[namida]

With regards to the missing Shimmier (and Reacher) sprites: Yep, some people still haven't brushed up on their custom sprites, sadly. It's definitely true for Nessy's sprites (Highland, Shadow, and Machine), maybe also for Arty's (Underwater and Silhouette)? Christmas sprites don't have Shimmiers, either, because those require more work than merely recolouring standard lemmings.

Highland has shimmier graphics, but the relevant metadata in scheme.nxmi is missing. This should be a simple copy-paste from a scheme.nxmi that does have them, so I'll sort this out later today - this will only require a redownload of the styles. I can probably even just make a small patch download that just overwrites the relevant scheme files, instead of requiring a full redownload of the 36MB styles ZIP.

The Xmas style has shimmier sprites, no worries there. As it's an official style, it falls on NL's developers (in this case, myself) to create the sprites for it where needed. If you're getting issues with the Xmas lemmings sprites, please double-check that you've downloaded the styles update.

Yes, Paint.NET can do this - there's an option on the fill tool to make it "global" rather than just "local", which will cause it to recolor every pixel in the graphic of the source color, instead of just the continguous ones. Make sure to turn antialiasing off when doing this. Although - as mentioned, I think this is just an issue with the scheme.nxmi files (it definitely is for Highland, haven't checked the other custom sets).

Every time you had to fix/alter a level it could be the case that an assignment in the old replay became impossible and was therefore discarded. So you fixed/altered your replay to the new version of the level, but the sleeper is still there and now the old failed skill assignments of the past come back to haunt you, leaving your replay database in shambles.

I fixed my replays for my packs for for the other packs I solved my replay database is now let's say unreliable.

I would propose: Failed skill assignments from replays are discarded again.

I think you've got the wrong idea here - and this is maybe my fault for not going into more detail about how this works / assuming you're familiar with the finer details of how queueing works overall.

As you probably know - the existing queueing feature is, if the user tries to make an invalid skill assignment, it'll be queued for a while (off-hand, I believe it's up to 1 second game time, but I could be wrong on this). If the assignment is successful, it's written to the replay at the time the skill actually executes, not at the time it was queued. If not, nothing gets written to the replay.

The changes simply extend this to cases where the replay tries to make an invalid assignment. The same behaviour regarding what's stored in any new replay, still applies. So, let's say you load a replay that tries to assign builders to Lemming 0, on frames 16 and 24; but on frame 16, the lemming is a faller. At frame 16, the assignment gets queued. Let's say, at frame 20, the lemming lands. At this point, he can be assigned a builder. Then, at frame 24, he's already building, so this assignment gets queued - but when the queueing expires, he's still building, so the assignment never happens. In turn, it gets removed from the in-memory replay data.

If you were to save a replay at this point, the newly-saved replay would contain just a single assignment - a builder at frame 20. As such, this will not have unforeseen consequences on new replays derived from existing ones, as far as I can tell.

Any existing replays, of course, should always be double-checked when a level is modified, or a new update that could break them is released. In this case, I'm not aware of anything other than this change that might affect existing replays, although there's always the possibility of (a) a new glitch (which would mean NL, not your replays, need fixing); or (b) that Nepster made a change I'm not aware of.

Of course, if I'm misunderstanding what you were saying and the above isn't relevant, please correct me.

[IchoTolot]

Well, that's not what I meant. I am referring to already existent replays that cointain "dead" skill assignments that now get reawakened as zombies if that's a good comparison.

Let's say you assign a builder at frame 20 to a Lemming. The replay solves the level. At some point the level gets changed so that the builder in the replay cannot be assigned, but is still present inside the file as an invalid skill assignment. The replay is altered to solve the new version of the level and the not assignable skill is still in it. Now in the new version they get queued and become active again, breaking the replay. I had quite a bunch of replays in each pack get broken because random skill assignments to wrong Lemmings appeared out of nowhere.

I would propose to let the sleepers rest again. Replays normally solve levels and and this change brings unwanted skill assignments back again. They were invalid for a reason. I would rather argue for deleting invalid assignments.

[namida]

Just to check - I ran Lemmings Plus I, V, VI, OmegaII and Alpha through the mass replay checker. Across all of these combined, two replays broke - both in levels where the current replay file is still one that was a direct conversion of an old-formats replay (ie: a conversion of the raw file, not "load it, let it run and re-save it in new-formats").

And keep in mind - the new format for replays was introduced back while everything else was still on old-formats. If I remember correctly, V1.43 was the last one that used the old replay format.

[namida]

The replay is altered to solve the new version of the level and the not assignable skill is still in it. Now in the new version they get queued and become active again, breaking the replay. I had quite a bunch of replays in each pack get broken because random skill assignments to wrong Lemmings appeared out of nowhere.

It seems that older versions allowed such a situation to arise, but new versions properly tidy it up. I'll have to look more closely to make sure of this, but if this is the case - I think instead, what we need is some way to easily clean out these invalid assignments from older replays.

For the record, I made this change based on this topic here: https://www.lemmingsforums.net/index.php?topic=4029.0
I simply extended it to - if it should happen for that invalid situation, why should it not happen for all invalid situations?

[IchoTolot]

Well for me it's about 5-10 replays in each pack, all levels were subject to changes through patches at some point. All were checked recently with every single one solving. I guess it has something to do with me doing changes and patches for packs more often therefore the chance of introducing invalid assignments is higher.

And this is the only possible change in the patch-notes that could have caused this: Invalid assignments that now become valid.

Why do we want to let them become valid in the first place if I may ask?   Aswered because of the last post.

Still: Why not simply discard all invalid assignments? They are invalid for a reason. Nobody would miss them as they were not felt before.

[namida]

If the general preference is that this change should be reverted, I'll do so.

Do you still agree with the specific case you mentioned in the other topic - that when it's a duplicate assignment, it should be queued? And how strongly do you feel about this (as it would be much simpler to apply a single behaviour to all invalid assignments, than to differentiate based on the reason - though far from impossible to do the latter)?

[IchoTolot]

For the duplicated case you still must manually edit the file to do that. So it's a corner case. Back then I did not forsee this result when not only it but every invalid assignment gets queued.

To be consistent I would argue for discarding the second assignment in this specific case as well, as it is by double-assigment rule invalid. So simply ALL invalid assignments in replays get discarded.

[namida]

I'll leave this open for a bit to see what other users think - as well as to see if this causes any problems with new replays, or replays that are modified in the current version, or if it only breaks old ones. (If it causes issues even with new ones, that's an extremely strong reason to revert, regardless of any other arguments. That doesn't mean it won't be reverted if it doesn't cause problems on new replays, but just that if it does, it's an almost guaranteed revert.)

However, this is something better addressed sooner rather than later. If a change is decided on, expect a V12.6.1 update for it, likely with no other changes from V12.6.0.

(Also - to be clear, one of the "no preference" votes is from me. While I really don't have a strong preference either way, I mostly did that so that I don't have to click "View results" every time I want to see the current state of the poll.)

[Minim]

I think the V12.6.0 queued idea has potential. So for example, if your lemming is building a long stair and you have 5 builders, assign the builder five times to the lemming quickly and fast forward a couple of times, voila! Your long stair is completed!

[IchoTolot]

I think the V12.6.0 queued idea has potential. So for example, if your lemming is building a long stair and you have 5 builders, assign the builder five times to the lemming quickly and fast forward a couple of times, voila! Your long stair is completed!

Yes, in game it makes sense, but that is not discussed here. Skill queueing like in Lix is a desired feature that I am totally 100% in for! (I think this is already brought up in the feature wish list as well.)

We are talking about not queueing invalid skill assignments in replays here. Invalid skill assignments that were not wanted before and that are now distrupting solving replays. This has nothing to do with queueing 5 builders for easy stairs in game. In fact queueing skills for a few frames in game is already implemented for quite a while in NL now.

[namida]

Sorry to say this Minim, but you have completely the wrong idea about how this works. See the second half of my first post in this topic.

[Minim]

The changes simply extend this to cases where the replay tries to make an invalid assignment. The same behaviour regarding what's stored in any new replay, still applies. So, let's say you load a replay that tries to assign builders to Lemming 0, on frames 16 and 24; but on frame 16, the lemming is a faller. At frame 16, the assignment gets queued. Let's say, at frame 20, the lemming lands. At this point, he can be assigned a builder. Then, at frame 24, he's already building, so this assignment gets queued - but when the queueing expires, he's still building, so the assignment never happens. In turn, it gets removed from the in-memory replay data.

Oops. Sorry about that earlier post. I must've read the poll and thought of an idea without looking into the thread. Now that I've looked closer and seen this paragraph in namida's first post I totally understand it now.

[namida]

It seems there isn't that much interest in the issue overall, and I'd like to resolve this quickly so - I'm going to go with "minimum damage" route and revert this change. Expect a V12.6.1 update very soon. The only change will be that it reverts to the old replay behaviour (minus the "two assignments in one frame" bug).

EDIT: This is assuming that the replay change is confirmed to be the cause of the replay breakages, but I can't see anything else that would be.