Hi,

geoo will pay me a short visit next week. He'll arrive on Thursday, May 23, and leave on Saturday, May 25. With only two days, there isn't much time, but I'm looking forward to:

• Discussing Lix development. What is important? Which bugs are most nagging?
  
• Discussing Lix physics. We have some long-open small physics oddities. Let's fix at least some for 0.12, whenever that will release.
  
• Testing a top-secret work-in-progress feature. Well, it's only semi-secret because I'll give you a hint:
  

To get into the mood, here's our topic from the February 2023 visit.

-- Simon

FF buttons be hold-down instead of toggle, how I thought they always should've worked

Interesting observation. In Lix, I hold the 10-second framestepping, too, and it becomes fast-forward for me. Hard to say if it's worthwhile to turn toggle-on fast-forward into hold-to-fast-forward. I imagine that toggle-on is better for recording solution videos, but that's niche. Even in livestreaming, I prefer hold-to-framestep instead of the toggled fast-forward.

I haven't played Golems enough yet to decide if I want a super-fast hold-to-fast-forward in Golems.

snapshot basically only needs to store the accumulated changes to the terrain and effect maps along with the (uncompressed) creature states, gadget states, and various other small bits of game state.

There is wisdom here: Separation of all level state into an immutable and a mutable section. It's enough to store the immutable section once, at the beginning. We store the mutable section in regular intervals, possibly compressed.

We can push this further in all of our engines.

E.g, hatches and water don't need to be part of the mutable state at all. Their animation is only dependent on the number of physics updates since the beginning. We can keep them in the immutable section, and only prepare them just-in-time during the drawing step. It's common to have 10 to 50 water tiles in a level; Lix can omit many allocating deep copies here.

Traps must remain in the mutable section because they eat lemmings at unpredictable times, and both physics and graphics depend on such recent eating. Theoretically, traps can split into an immutable location and the mutable number of the physics update of recent eating, at cost of even more complication.

Thanks!

-- Simon

We refactored the three bools into one enum.

I tested the Exp 8 (from WillLem's previous post) and it all looks good. The default behavior is to exit if save requirement met. Options load and save correctly, and behave accordingly during play. Icho's Lemmings United mass-tests identically in this Exp 8 as it did in the Exp 6, i.e., everything looks good here, too.

Pull request is up for namida to review. WillLem and I are both happy to give high-level overviews of the source changes; namida: Ask here or in IRC or anywhere. The diff is moderately large: 9 files changed (7 source files and 2 new images), 211 insertions, 61 deletions, but overall it stayed surprisingly manageable.

Thanks, WillLem, for your patience and for ironing it all out!

-- Simon

what an enum is

Like a Boolean, but with 3 values instead of 2 (true, false), and you get to name the 3 values yourself.

https://en.wikibooks.org/wiki/Pascal_Programming/Enumerations#Declaration

-- Simon

I'm sitting in Mumble. Join anytime.

BRB in 20 minutes (17:30 UTC). Back.

-- Simon

You still have 3 internal variables, which can be a similar source of bugs as the 3 exposed options from the text file.

For example, here:

if not MatchStr(sOption, sPossibleOptions) then
    EndifLevelPassed := True
else begin
    AlwaysEndGameplay := (sOption = 'Always');
    EndIfLevelPassed := (sOption = 'IfLevelPassed');
    NeverEndGameplay := (sOption = 'Never');
end;
... you risk a bug whenever this runs while ((AlwaysEndGameplay is true) or (NeverEndGameplay is true)) and you run into the 'if'. I don't know if the code ever runs in that case. I know that it parses options during startup. But if it does run at another time, you'd again violate the invariant that exactly one of the three is true. This is a maintenance trap: The option-loading code now has a silent requirement that it may only be called once.

One way to avoid that worry is to remove the if/else entirely and write:

AlwaysEndGameplay := (sOption = 'Always');
NeverEndGameplay := (sOption = 'Never');
EndIfLevelPassed := not AlwaysEndGameplay and not NeverEndGameplay;

But even better: Track the option internally with one variable. Then it's absolutely impossible to have more than one of them true, it'll be obvious anywhere in the program and to any maintainer. Consider an enumeration; Delphi 6 should support them:

type TExitToPostview = (
    etpAlways,
    etpIfPassed,
    etpNever
);
var ExitToPostview : TExitToPostview;if sOption = 'Always' then
    ExitToPostview := etpAlways;
else if sOption = 'Never' then
    ExitToPostview := etpNever;
else
    ExitToPostview := etpIfPassed;

I'll sit in Mumble for the night from 19:00 UTC to around 22:00 UTC. Catch me in Mumble spontaneously; otherwise, we'll review next week.

-- Simon

NL 12.12.5.

1. Build a level pack including some talisman levels.
2. In NL's options, name yourself X.
3. Cover your levelpack including all talismans with replays played by X.
4. As X, mass-verify your replay collection.
5. In NL's options, name yourself Y.
6. As Y, mass-verify your replay collection.

Expected: Identical output in steps 4 and 6 for each replay.
Observed: Different output in steps 4 and 6 for each talisman-winning replay.

When Y mass-verifies replays from X, then NL will still test for pass/fail correctly. NL will print pass/fail correctly to the screen and to the results file (the text output file in your NL worktree). But NL will refuse to tell Y whether X's replay achieved a talisman. NL will print talisman-winning replays as plain wins.

I understand that Y doesn't want X's talismans recorded in Y's personal statistics, but Y doesn't want X's plain wins written there, either. Then why does NL still print win/loss, but not talisman, during Y's mass-replay verification of X's replays?

Experienced NL designers/level maintainers: When you co-author a pack, or when you inherit a pack with talismans from another maintainer, how do you work with his replay collection? Do you mass-rename the player to yourself in the covering replays before you mass-verify the replays? Especially co-authoring a pack sounds impossible under this NL behavior without constantly renaming the players in all those replays.

-- Simon

Got it!

Nice! Just Mine becomes easier when you solve the wrappy rank in order. But I told you to look directly at Just Mine (and skip the preceding 5 wrappy levels), thus, well done!

-- Simon