Don't exit on losing all lemmings (feature development)

[WillLem]

@Simon - Let me know if you'd like another session on this. I'll have a look at the Nuke code in the meantime and see if I can figure something out. The rest of it is mainly bug-testing.

Not sure how to test/replicate the settings loading bug, but hopefully this will fix itself with the recently modified logic!

[Simon]

What happens to this option when we start NL with empty options file/new installation/...?

Same thing as with every other option: a default is set (in this case, Always Exit To Postview).

Consider to change the default to: Exit only if won, freeze if lost. namida agreed that this can be a sensible default.

That will then happen to match what I saw in the settings menu after supplying the exp 3 config. If we want to debug this properly: My hunch is that you hardcoded the defaults in two different places (e.g., once in the options menu, and once in code that loads config files) and the two defaults don't agree.

@Simon - Let me know if you'd like another session on this.

I'll be available tomorrow (Tuesday) evening from 18:00 UTC through 23:00 UTC. I'll also be available Wednesday from 18:00 UTC through 23:00 UTC. I'll sit in Mumble at those times.

Alternatively, at these same times, I can stream playtesting. If you're really fast with the bugfixes, a stream may be more useful than code review in Mumble. But I'll plan for looking at code via Mumble.

-- Simon

[WillLem]

Consider to change the default to: Exit only if won, freeze if lost. namida agreed that this can be a sensible default

OK, but it would still be good to identify the cause of the bug.

My hunch is that you hardcoded the defaults in two different places (e.g., once in the options menu, and once in code that loads config files) and the two defaults don't agree

Double-checked this, and as far as I can tell, the default is definitely only set once.

Did you get the "NeoLemmix Welcome Screen" when you first loaded "V4 + V3 config"? If so, this would indicate that the settings file has been ignored. If not, then the settings should absolutely have been loaded correctly unless I've missed something. The fact that manually re-setting the option fixed the issue would indicate that it's a loading (rather than saving) problem.

Let's see if the updates we made in the session the other day have fixed the issue - it's a possibility.

I'll be available tomorrow (Tuesday) evening from 18:00 UTC through 23:00 UTC

I'm free now for a bit, I'll jump on Mumble soon.

Best bet for Nuke is to simply exit to postview when the game is frozen and nuke is activated. It's by far the simplest option.

[WillLem]

@Simon - in case you see this before looking through the code - I checked everything, and the very latest pushed commit works exactly as we want. So - for whatever reason, UserSetNuking seems to be needed wherever it currently appears in the latest commit. Removing it breaks one or more of the nuke/exit-to-postview-related behaviours.

[Simon]

So - for whatever reason, UserSetNuking seems to be needed wherever it currently appears in the latest commit.

I agree! From digging the source: UserSetNuking is indeed part of the physics, not the UI. It's good that it's part of the physics, then it makes it the prime candidate to check in StateIsUnplayable, ShouldWeExitBecauseOfOptions, ..., which all care only about a reached physics state (and maybe options), never about UI.

UserSetNuking tells you if a nuke has been applied from the replay to the physics state, either now or during any earlier physics update. This is exactly what you want to know: Is the nuke active. (And it's not: Has the user double-clicked the nuke button on this main loop iteration.)

There is also ExploderAssignInProgress, which becomes true when UserSetNuking becomes true, but eventually becomes false when physics have run out of lemmings that can receive countdowns. Thus, this ExploderAssignInProgress isn't useful for us.

Let's still have a session tomorrow as planned.

-- Simon

[Simon]

Code Select Expand

function TLemmingGame.StateIsUnplayable: Boolean;
begin
  Result := (LemmingsOut = 0)
            and (LemmingsToSpawn = 0)
            and (DelayEndFrames = 0)
            and (fParticleFinishTimer = 0)
            and not (UserSetNuking and CheckIfZombiesRemain);
end;

Code Select Expand

procedure TLemmingGame.MaybeExitToPostview;
begin
  if fGameFinished then
    Exit;
  if ShouldWeExitBecauseOfOptions then
    Finish(GM_FIN_LEMMINGS);
end;

According to my understanding, this is now all that we need. I've moved your zombie logic into StateIsUnplayable, which is where I really believe it belongs. Let's chat about it tomorrow evening. E.g., it's still not clear if LemmingsOut = 0 is good, or if you need that lengthy addition.

ShouldWeExitBecauseOfOptions isn't touched; it's the same as in your latest commit 6091bd7887.

-- Simon

[WillLem]

@Simon - thanks for the code snippets, I gave them a try and could only find 1 issue:

In a level with >1 active lem and 1 unavoidable zombie, nuking with >0 active lems lets the nuke countdown and animation play out in full even after the active lem(s) become zombies - this is good. However, once the ParticleTimer is at 0 (so, all debris is finished), the game doesn't exit to postview. It also doesn't freeze or show the minimap message, it just continues updating.

The most recent commit is the only version that fully works (so far, with minimal testing); I've attached a compiled .exe of this version. I'm sure that some of the simplifications to the code that you've suggested can be made, we'll just have to be careful not to accidentally omit something - or, make sure we factor everything in to the simplifications.

Hope this helps. Speak tomorrow, WL

[Simon]

I found no bugs in your attached executable. Nice! Haven't tested for the config-loading bug yet. Happy to playtest more.

Issues with my snippet: Ah, right, I forgot that we already talked about how NL's nuke doesn't set LemmingsToSpawn to 0; NL's nuke merely prevents the unspawned lemmings from spawning. We must account for this.

Replace: and (LemmingsToSpawn = 0)
with this: and ((LemmingsToSpawn = 0) or UserSetNuking)

It looks strange to test the nuke in two different lines of this expression, but it expresses reasonably succinct: No more lems to spawn and no more zombies about to get nuked.

-- Simon

[WillLem]

It looks strange to test the nuke in two different lines of this expression

To be fair, in one line we're testing for (true or something else), and in the other line we're testing for (false and not something else). So, they are absolutely two different conditions, good work!

Replace: and (LemmingsToSpawn = 0)
with this: and ((LemmingsToSpawn = 0) or UserSetNuking)

Tried this - the result is that the game freezes when it gets to the end of the nuke animation...

Better, but ideally we always want the game to exit to postview in the event of a nuke, regardless of the option. So, we need to factor this in to the two options that sometimes (or always) won't end gameplay. The following chunk fixes the issue and maintains most of your refactoring. If you can see a way to reduce the presence of "UserSetNuking" further, I'm all for it! In the meantime, this revision and the attached .exe seem to be working exactly as we want:

Code Select Expand


function TLemmingGame.StateIsUnplayable: Boolean;
begin
  Result := (LemmingsOut = 0)
            and ((LemmingsToSpawn = 0) or UserSetNuking)
            and (DelayEndFrames = 0)
            and (fParticleFinishTimer = 0)
            and not (UserSetNuking and CheckIfZombiesRemain);
end;

function TLemmingGame.ShouldWeExitBecauseOfOptions: Boolean;
begin
  Result := False;

  if not StateIsUnplayable then
    Exit;

  if GameParams.AlwaysEndGameplay then
  begin
    Result := True;
    Exit;
  end;

  if GameParams.EndIfLevelPassed then
  begin
    Result := (LemmingsIn >= Level.Info.RescueCount) or UserSetNuking;
    Exit;
  end;

  if GameParams.NeverEndGameplay then
  begin
    Result := UserSetNuking;
    Exit;
  end;
end;

procedure TLemmingGame.MaybeExitToPostview;
begin
  if fGameFinished then
    Exit;
   
  if ShouldWeExitBecauseOfOptions then
    Finish(GM_FIN_LEMMINGS);
end;


Let me know if you find any issues. From some quick testing, this seems to be the one. I've pushed the commit (820872bcb)

I'll look into some catchier names for these methods as well



Attachment removed. Instead, you can get version 5 here.

[Simon]

I playtested version 5 on stream on Monday, April 1st. This was short notice and I didn't expect anybody to see this in time. Sorry, was busy all week!

Stream is over, a short stream of 1.5 hours.

Recording will remain for 14 days at:
https://www.twitch.tv/simonnaar

-- Simon

[kaywhyn]

Stream is over, a short stream of 1.5 hours.

Recording will remain for 14 days at:
https://www.twitch.tv/simonnaaar

-- Simon

The link doesn't work. I always get a "content is unavailable" error

[Simon]

Good catch, thanks. Link is fixed. I had put 3 'a' in a row by mistake.

WillLem: Written summary of the feature testing will follow here tonight. Then you need not watch it all.

-- Simon

[WillLem]

A somewhat interesting turn of events...

In SuperLemmix, there is an option to hide the minimap and thus reduce the width of the game window. So, out of necessity, I found a way to draw the message to the panel area instead!



This way, we get to see the minimap after all! Happy to backport this to the NL version if we think it necessary?



Meanwhile, I watched some of  the twitch stream @Simon - we can look at not adding the Nuke to the replay if it's done after the unplayable state has been reached. I agree, this is not necessary and looks odd. (EDIT: This was an easy fix, I've committed and pushed this.)

The fall distance ruler, meanwhile, can be changed back to solid colour - no problem. Namida likely just wouldn't merge that part of the code anyway.

[Simon]

Position of the message: No preference, happy to test the UI again after you put it into the stats.

Habitually, I never look at the minimap and instead scroll/zoom much more on large levels. But others like the minimap.

Yeah, I have the preference for the solid color of the splat ruler. I grant that the rainbow cycling isn't as intrusive as I thought, but it's still more intrusive than I like.



Bugfixes: Had a busy day at work, but you've already caught everything. I'll summarize nonetheless:

Overshooting is fixed entirely in Experimental 5. Good!

The following bug is now fixed, too: In earlier stream, on kaywhyn's Fun Teleportation Race in Space, we saw the Experimental 4 freeze after the last lemming left by exiting. The lemming scored a point and made the score equal to the save requirement. Nonetheless, Experimental 4 didn't exit, and instead showed the message. The Experimental 5 exits here always, which is correct.

All 3 user options do what it says on the tin, with the designed exception that the nuke overrides the user option and exits. No bugs here.

The only bug is what you've already seen: When I nuke during the freeze (to exit immediately without seeing explosions), NL writes the nuke into the replay. When we watch this replay, the red R will stay after the final assignment (because there is the nuke coming up) and, when we reach the freeze, the nuke button will have the white square, but we won't see any nuking.

If you have fixed this by not adding the nuke to the replay: Excellent, I believe that is the cleanest fix. I'll test it. I'll have time to stream playtesting on Friday, Saturday, or Sunday evening.

Do you want a Mumble session with code rewiew? Again, Friday, Saturday, or Sunday evening is good.

-- Simon

[WillLem]

Position of the message: No preference, happy to test the UI again after you put it into the stats.

It takes a little bit more work for this to behave since it has to override stuff that can still be accessed during the frozen state (i.e. hovering the mouse over a zombie will show "ZOMBIE" in the same area unless we tell it not to), so I'd probably suggest not going ahead with this for NL unless there's demand.

The minimap message works, we've ironed out all bugs, let's leave it as it is.

Do you want a Mumble session with code rewiew? Again, Friday, Saturday, or Sunday evening is good.

Sure, that sounds good. Let's catch up again again nearer the time.