OK, even better.

This time, we factor in IsOutOfTime as well.

            if (Game.CurrentIteration > CutoffFrame) or
               Game.IsOutOfTime or Game.StateIsUnplayable then
            begin
              Game.Finish(GM_FIN_TERMINATE);
              if Game.GameResultRec.gSuccess then
                fReplays[i].ReplayResult := CR_PASS;
              if Game.GameResultRec.gGotTalisman then
                fReplays[i].ReplayResult := CR_PASS_TALISMAN;
              if (Game.StateIsUnplayable or Game.IsOutOfTime) <------------------------------------
                and not Game.GameResultRec.gSuccess then      <--------changed these lines------
                  fReplays[i].ReplayResult := CR_FAIL;        <------------------------------------
              Break;
            end;

This now only returns CR_UNDETERMINED if the level has an infinite time limit. Otherwise, if the time limit has been reached and the result is non-Success, it returns CR_FAIL. Not sure why it wasn't always like this tbh, there are probably reasons. But, this works nicely.

New .exe attached. We'll call this one The 4pm Version

No, unfortunately that didn't work.

The code snippet does deal with PASS(TALISMAN)/FAIL/UNDETERMINED, so that's almost certainly what we need to be looking at.

I thought that maybe StateIsUnplayable needs to explicitly pass a FINISH message. But, if we zoom out and examine more of the RunTests method, we can see that this should indeed be happening:

            if (Game.CurrentIteration > CutoffFrame) or
               Game.IsOutOfTime or Game.StateIsUnplayable then <------------------- N.B. this line checks for StateIsUnplayable
            begin
              Game.Finish(GM_FIN_TERMINATE); <------------------------------------- So, the message is passed
              if Game.GameResultRec.gSuccess then
                fReplays[i].ReplayResult := CR_PASS;
              if Game.GameResultRec.gGotTalisman then
                fReplays[i].ReplayResult := CR_PASS_TALISMAN;
              Break;
            end;

            while Game.MessageQueue.HasMessages do
              if (Game.MessageQueue.NextMessage.MessageType = GAMEMSG_FINISH) then
              begin
                if Game.GameResultRec.gSuccess then
                begin
                  if Game.GameResultRec.gGotTalisman then
                    fReplays[i].ReplayResult := CR_PASS_TALISMAN
                  else
                    fReplays[i].ReplayResult := CR_PASS;
                end else
                  fReplays[i].ReplayResult := CR_FAIL;
              end;
            if fReplays[i].ReplayResult <> CR_UNDETERMINED then Break;

I'm going to try adding the fail result to the first of these two code blocks and see what happens.

Suggestions welcome in the meantime.

If tribe alignment is a property of the exit: The exit is now responsible for showing tribe alignment, all by itself.
---
It's possible to solve this by introducing extra tiles conditionally when the game constructs the level from a level file. But this feels unnatural. If you solve it with extra tiles, don't allow another way of adding these tiles; the only way must then be by setting exits' tribe alignment.

This is kind of what I'm aiming for. The Editor auto-draws the tiles when the property is set. It also re-draws them if the property is changed at any time (I still need to make it so that all markers are auto-removed if no Exits are marked as Rival).

Assuming you make tribe alignment a property of the exit (and not a result of overlaying two tiles): Avoid reliance on human-placable marker tiles in the editor. The editor should render the exit as it will appear during play, or show other equivalent information on the exit.

*Ideally, the markers should remain in place, anchored to the Exit, and be non-editable. That way, they appear exactly as they will appear in the Player. This is on the to-do list.

For now, they can be edited and moved around. A band aid would be to simply call the marker-adding method upon saving the level (the method first removes all existing markers), but this obviously isn't ideal.

EDIT: Another possible method would be to add the helper graphics to the Editor and draw these wherever they are relevant, in the same way that placeholders are used for pickup skills in the Editor. This should probably happen anyway, since the Editor currently has no way to visually represent pre-assigned hatches, lemmings, etc. I did take a quick look at this yesterday and found that it would take some doing, but it might ultimately be worth it for more than just the Rivals feature.

Downside of introducing extra tiles conditionally when you render the map: The editor can't naturally show these tiles and not put them into the level.

If I can achieve the above^*, then re-introducing the tiles at map rendering will make them appear exactly as they appear in the Editor: from a user point of view, nothing has changed. We still need to do it simply because the level file can be edited in Notepad; the only way around this would be to somehow bake the animations together in the Editor, which I'm not sure is even possible (and certainly wouldn't be worth the time and effort it would take when we can simply re-draw the markers in the Player, achieving the same result - this is how Secondary Animations are handled).

Do you have deneutralizers? What happens when you neutralize a rival, then deneutralize him: Will he be regular lemming or rival?

This is a good question with no easy answer.

Instinct: they should keep the Rival tag.

Then, I remember that I don't want to have to recolour Rival-Neutrals a different colour to regular Neutrals, so these lemmings become only a source of confusion.

So, I then think that Rivals should simply ignore Neutralizers. This would at least be consistent with code-base behaviour (since Rivals cannot also be Neutral at any other time), but could seem odd to players.

So, I then think that SLX shouldn't feature both Rival lemmings and Neutralizers. The latter is essentially just another trap to be avoided anyway, which makes them mostly uninteresting. De-neutralizers have much more gameplay and puzzle potential, and can play nice with Rival lemmings.

Thanks for the comments, mobius. It's helpful to hear back from others even if it's just a few mostly-on-instinct comments.

I'd say a rival exit/exits should automatically get marked in some fashion. I say don't count on level designers always doing things right but also people can just forget things.

Agreed, this is ideally what should happen.

So far so good: in the Editor, we can add the relevant markers automatically (and even place them over the correct exits) with a single click! Furthermore, the Editor will check the level's theme for custom markers before applying the defaults. If any Exit is changed at any point, the markers are all replaced accordingly - all good.

The only issue is that the custom pieces must be named "exit_marker_normal" and "exit_marker_rival" in order for this to work. This might not seem like such a big deal, but it means that (a) it isn't possible to have more than one of each marker per-style, and (b) if a style does have its own markers, they are placed alongside the existing default ones in the piece selection window rather than replacing them.

Neither of these are necessarily bad things, though: limiting the number of these markers that a style can have might not be the worst idea, and designers may wish to select the default markers even if a style presents custom ones - as it is, it's currently easier to do just that.

Meanwhile, the next step will be for the SLX Player to delete all existing markers and replace them; the idea here is that markers will then only be useful for the level designer whilst in the Editor, and the player whilst in the Player. This is about as much as I can do code-side to make sure that the feature is as clear as possible.

on the matter of creating incorrect/incomplete stats with and unusual number of entrances/exists; solution A seems best to me. Still using the rivals; having them play a part (hindrance in this case) is interesting.

Again, agreed. Solution D, then Solution A, seem best to me personally. Since you're the only person who has replied and you've shown support for A, I'll look at going down that route.

Anyone else?

OK, Rival Exits will be assignable in the same way as pre-placed Lemmings/Hatches; simply check the "Rival" checkbox to designate the property to the selected Exit in the Editor.

As for adding flags/markers, for now let's rely on the existing helper graphics system to show when an Exit has been designated as a Rival Exit; this isn't an ideal long-term solution though, because it doesn't help when in Classic Mode.

I'm going to experiment to see if there's a way to detect the presence of an Exit-marker (e.g. the flag), and automatically add one if it isn't found. If this is too difficult though, then other options will need to be explored. That's for another day though.

Some thoughts on this would also be much appreciated if anyone has time to reply.

Well, I love a good spreadsheet so here's what we can possibly do for each of the sound cues :

N/A means Not Applicable - we won't use a Visual SFX cue here.
TBA means To Be Announced - we either won't use a Visual SFX cue here, or we need to decide on one.

Sound Cue	Text VSFX	Symbol VSFX	Panel Message (off-screen events only)
Level Start	"LET'S GO!" (above entrances/pre-placed lems)	TBA	N/A (off-screen level start areas shouldn't be formally supported)
Zombie Level Start	"BRAAAINS!" (above zombie entrances/pre-placed zombies)	TBA	N/A
Builder/Stacker/Platformer Warning	"CHINK" (above working lems)	Frustration lines (above working lems)	<- Bricks are running out! ->
(Time)Bomber 'Oh No' State	"OH-NO!" (above lem)	N/A	N/A
(Time)Bomber/Freezer Explosion / Balloon Pop	"POP" (above lem)	N/A	N/A
Hit Steel/OWW	"BONK"	TBA	<- Action interrupted ->
Lemming Death	"YIKES!"	N/A	<- Lemming lost ->
Time Up	"TIME UP" (above exits)	Clock (above exits)	Time is up!
All Collectibles Gathered	"WELL DONE"	Star (above lem)	N/A
Button Click	"CLICK"	N/A	<- Button Pressed ->
Exit Unlocked	TBA	TBA	<- Exit Unlocked ->
Lemming Exit	"YIPPEE!"	N/A	N/A

Made significant progress with this. The feature is working a treat so far, including recolouring (which took some doing to get everything to line up, but it seems to be playing along nicely).

A few concerns have arisen, which will need to be addressed before I'm happy to release this feature:

1) How should Rival exits be marked?

This is where those decorative flags might finally come in handy for something. It would be fairly arbitrary to design a different-looking exit (which to all intents and purposes would still just look like... an exit!). There are also cases where a Rival exit would need to behave like a normal exit code-side anyway (more on this later). So, how about this for starters (note that these lems are going to their correct exits!)?



For the default ohno/orig Rival Exits, the red flag can be baked in to the animation. This should prompt designers to manually apply the blue flag for Normals.

There may even be a way to detect the presence of the flags within a certain radius of the exit's trigger area, and enforce this code-side if the level contains Rival lemmings. That does seem a bit drastic, though. Let's hope that designers choose to mark the exits appropriately if they're creating a Rivals level, and give them a nudge in the right direction if they choose not to or genuinely don't realise that they should.

2) What should happen when a level has only Rival lemmings but only Normal Exit(s) (or vice-versa)?

This one should be fairly easy to deal with: if there is only one type of lemming (Normal or Rival), then any exits present behave like regular exits for that lemming type. The way that Rivals code has been implemented so far could easily support this, and it would mean that people could make legit levels featuring only Rival lemmings should they wish to do so, whilst also preventing troll levels/genuine mistakes.

In the absence of any better ideas, that's how I'll probably solve this one.

3) What should happen when a level has a mix of Rival & Normal lemmings but only Normal or Rival Exit(s)?

This one is more difficult. At present, it would be possible to create the following level:

20 Normals + 20 Rivals
Save requirement of >20
0 Cloners in skillset
1 Normal exit

Such a level would be impossible to complete, and this is a scenario which could come up fairly innocently. So, it feels like it should be handled code-side. I can see 3 possible solutions:

Solution A would be to default the save requirement to the amount of Normal lems. That way, the Rival lems could still be used as part of the level's solution, it would just be necessary to divert them away from the exit.

Meanwhile, the more complex Solution B would be to subtract the number of Rivals from the current save requirement, and have the resulting figure be the new save requirement. So, for example, in this scenario...

20 Normals + 20 Rivals
Save requirement of 25
0 Cloners in skillset
1 Normal exit

...the save requirement would become 5. This would essentially completely disregard the presence of Rivals in the level. So, if the solution requires that 15 lems be sacrificed, those lems could be either Rivals or Normals and it would still be possible to meet the save requirement.

Meanwhile, Solution C would be to change the Rival lems to Normals. This would be the cleanest code-side, and would at least allow the level to be loaded and played.

Note that in any of the proposed solutions A, B and C, the same logic would apply vice-versa for (mixed lems + Rival exit).

Finally, Solution D would be to not load the level at all unless there is at least 1 Normal and 1 Rival exit, in the case that there is a mixture of Normal and Rival lemmings. This is probably my preferred solution out of all of them as it bypasses Rivals being used for unintended purposes and keeps the feature clean, but it does mean that the potential puzzle benefits of solutions A and B are discarded.

Thoughts? Could do with some feedback on this as either solution requires a fair amount of commitment to that solution before plowing ahead.

Glad to have approval for this. It'll be present in 2.8 for sure

One thing I am now wondering though is whether the regular status text (athlete info, etc) should also be hue-shifted... this is where I might be overthinking it a bit. Let's leave things as they are for now!