Clicking the R in status bar: Yes, promising idea. The R is the visible UI element for replaying, it makes a sense to click that to cut the replay. If you animate it -- it doesn't even have to be glaring -- it will pop in the panel area. E.g., a play arrow ▶ that moves through it. It's clearer and less glaring than cheap color-changing the entire R. Let me know if you want me to draw such an animation.

The status panel has been a safe zone for clicks. If you click the panel, you don't misclick buttons yet, and neither you mis-cancel the replay (as clicking into the main map would). Now, we'll sacrifice this safe zone for newbie-friendly UI. Hard to give a final verdict. My hunch: If you want to try this, let's do it. Saving a few newbies' sanity is worth it. Or leave the bottom 10 % of the status panel as safe zone. >_>

Lemmini R: Adding the pulsating R in the main map is similar. Because you'll put it on the map (not in the panel), when we click that R, we have clicked the map, and NL will cancel the replay even if you don't write extra clicking code. It's the same in Lix: The wobbling R is in the corner of the map, and clicks go to what's on the map behind the R -- air, usually, and that cancels the replay.

Here, I'd only warn about making it too big, because it will appear constantly in pepole's solution videos on youtube. Big enough to attract new players' clicks, but no bigger.

I'm happy to try either idea: Moderate animation to the existing NL panel R, or your Lemmini R in the main map.

Indeed, Saxdude's first guesses in the panel are: Restart, pause, and then button with the R (which loads replay and doesn't solve his problem). This is promising. Only afterwards, he tries clear-physics and force-direction. He also clicks the status bar (lemmings out, goal flag), even though I haven't seen him explicitly click the red R in the status bar.

---

Dialogs: Let's try other ideas than dialogs first. Dialogs break the game flow (you accept this), but people still won't read them, and even if they read a one-shot dialog, they'll have forgotten it when they return in half a year after 10 minutes with a distraction. Don't put important info only in a one-shot dialog.

Option to disable replay: No strong opinion. I'd wait. We have seen people want this, e.g., Dave4 wanted this, but only after he failed to cut the replay. We'll have to see if people still want this after cutting the replay has become obvious for new players.

Cursor: Bug #400 on Lix: Scissors mouse cursor while replaying is an unrealized feature idea. I'd like the ingame cursor (crosshairs) to show scissors. The idea is that you can now click to cut the replay. It's more feedback, but untested. In NL, I'd only try this together with our other ideas.

-- Simon

I'll guess: The grid-based piece viewer is a tile browser with a large two-dimensional area that displays many tiles at once, laid out two-dimensionally instead of tiles all in a line. Ideally, you have the full tileset on the screen at the same time.

Pop-out is GUI speak for showing some parts of the editor's functionality in a separate window from the main program window. You can resize the windows independently. The deluxe variant is when the popping-out is optional and you can dock the pop-outs back into the main window.

For the search bar, I won't guess. Certainly, searching across tilesets is strictly more powerful, but I don't know if Giga needs an in-tileset search or an across-tileset search.

-- Simon

auto-replay optional and off by default
many players will miss out on what is actually an extremely useful feature.

It pains me that off-by-default can be reasonable. It's simple and kills the confusion directly at the root. But I'd rather wait with this until several other ideas have failed -- including trying more things in Lix and discussing applicability to NL.

Both user stories (Dave4 and Saxdude26) show the annoyance only when assignments replay after restarting the level from the very beginning. That hints us at offering two modes of restart: Restart with replay, restart without replay. IIRC WinLemm did this? Not overly elegant, but at least it's a way to do it without printing text during play. I'm not recommending for or against it; it's one idea.

Our sample size (2 new players) is still small. Maybe we find more stories where the replay annoys people after rewinding. Then we can't fix it by merely offering two ways to restart. E.g., mobius wanted the option to turn off replay-after-rewind, i.e., to make rewind immediately cut all rewound assignments. It looks like this user option also saved Saxdude26's sanity, in a roundabout way.

-- Simon

I remember that the inside markings (C in the image) are for walkers (edit: wrong, see my next reply; B is for walkers), and I don't use the outside markings. I assume both outside markings (A, B) are for climbers (edit: again, wrong, only A is).

I don't know if the red bars (C, D) at the ends are inclusive or exclusive. I use the ruler for rough measurement, and if a single pixel counts, I experiment. (= I let one splat and rewind.)

-- Simon

NL doesn't tell the player during play how to cancel the replay. This confuses random reople on the internet. You don't always have the luxury of people reporting their confusion here.

I believe that this is far more annoying for new users than most experienced players assume.

---

Example from 2022-02:
Bug: Uncommanded clicking

Dave4 creates an account on LF specifically to report this bug. This report was his first post.

Dave used to work around this by exiting NL entirely, then restarting NL.

---

Example from 2023-06:
Join development team

yoyoz files the automatic replay as a bug, and has already changed the NL code to fix it: "There is a problem when you click on restart button: Same actions are replay. I have fixed it. But for the moment, i havent found where fix when you restart the level with the menu screen."

---

Example from 2023-07 that I found today:
https://www.twitch.tv/videos/1878712696?t=0h17m23s -- watch from 17:23.

Saxdude26 fumbles in the NL ingame UI and level selection UI for 3 minutes. He restarts several times, which doesn't solve his problem. He saves the replay to disk, which doesn't solve his problem. Eventually, he goes to the options (dialog doesn't show on stream) and (presumably) disables replay after backwards frameskip. That's his solution -- he cuts highly useful things. Ends with: "Do I like having replays? Yes. Do I like that it keeps replaying when I restart the level? No."

He hasn't clicked air in those 3 minutes. He has clicked practically every panel button, but never the air. Why should he click air when NL doesn't nudge towards clicking air?

---

Writing these down because WillLem is considering ingame text over status panel for Don't exit on losing all lemmings.

-- Simon

LemGame refuse to run the update routine if all:
1. 2. 3.

Yes, for the freeze, this is a good approach, and it doesn't need messaging nor extra state tracking.

That's 38 characters, the panel allows 45.

Sounds doable, yes.

When you overwrite this status panel, you can't display its usual values. Most values have become irrelevant by here (we know that 0 lemmings are in hatch, 0 lemmings are in level), but I like to look at by how many lemmings we fell short of the save requirement. I'd nudge you to still show this (how many more to save) at all times.

Maybe we want the time limit here, too, but I have no experience. The time limit doesn't sound as important to show (i.e., by how much we fell short of the save requirement feels more important). Or ditch half of the message, only show "skip back or restart", or "rewind or restart", or ...

In a pinch, if you don't show a value, we can rewind 1 or more ticks to view the regular panel.

Which nuances will determine how the re-write looks.
option to unpause the game and continue into the "no lems" state
need more community feedback

Right; others, please join the discussion.

-- Simon

what binaries are in this context?

Here: An NL executable. I can't build it myself from source here.

Generally: Executables, DLLs, static libraries. Program code in CPU-consumable form instead of human-readable source code.

Ah, you've released an entire experimental build. Thanks! I'll test it this weekend at latest, and you'll have feedback by Monday.

Quote from: Simon on February 13, 2024, 01:23:43 AM

Is suspend the same as pause?

prevents player input and releases the mouse.
wants input from the dialog before gameplay can be resumed.

Okay, you decide if this is appropriate. It sounds as if NL stops reading hotkeys during suspension, which would be a problem. We want hotkeys active throughout this; we usually want to rewind.

You say it wants input from the dialog, but we don't plan to add a dialog.

Quote from: Simon on February 13, 2024, 01:23:43 AM

pause when you are running out of lemmings, not when you have run

pauses at the frame the very last lemming is removed.
prefer something other than this?

Two answers.

1. It's indeed good to end when the last lemming is removed. It may be even nicer to end when ((the last lemming is removed) and (no triggered trap is eating anymore)).

2. It's possible you didn't get the nuance. To be safe, I'll rephrase: Your problem is that your code re-pauses too often. My reply was that this pausing should originate from actively running out of lemmings (which can only happen if we still had lemmings before advancing physics during this very iteration of the program main loop) instead of from having run out of lemmings (which is still true in future main loop iterations, regardless of whether we advanced physics again or not).

namida and I recommend nearly the same solution. The difference is: namida wants to track state (has he messaged you before). I want to generate the pause as a result of advancing physics, which won't happen again until you rewind. My solution needs no extra state, but ties the check to parts of the code (physics, or at least the game code that triggers physics advances) that don't care about UI. I don't know enough NL internals to tell you what's ultimately better.

skip of, say, 1000 frames overshoots by a significant amount

Yes, this is problem #1 that you should address.

Problem #2 arises from holding a skip hotkey down. The held key generates keyboard input for every iteration of the program loop. In 2023 NL, such skip input will advance physics even during pause, which is fundamentally good. But here, the skip will ignore your pausing. I hold the key down, I reach the end, your code pauses, my held key generates more inputs and completely bypasses your pause. Now I've overshot by many multiples of the single skip length.

freeze the game instead, then I agree visual feedback is absolutely necessary.
work with the limited skill panel display

Yes, 100 % agree that this is the biggest task in implementing a freeze. To make it lovely, you'll have to design visual feedback unlike anything in NL. I have no easy answer. More on this later.

benefit to freezing physics (as opposed to pausing the game) that I haven't yet become aware of...?

Also more on this later.

-- Simon

Menu looks good to me. Looks like you can support namida's/Icho's ideas without overly much extra work or extra menu space. And you've already thought of disabling the Pause checkbox when we want to always exit.

You haven't attached binaries yet, therefore playtesting has to wait until you do. (I still haven't gotten a Delphi build toolchain to work on Linux.) I'll be happy to playtest during the weekend. Or you focus on development first, and I'll find more time later in the month.

suspended

Is suspend the same as pause? You didn't like the absolute prevention of further physics updates (= what I called a freeze, but I don't know a best name either). You wanted the regular pause, which the player can unpause.

immediately gets suspended again because the check for no lemmings is still returning true
sane way to fix this

If the check works well already, you can alternatively be happy with a freeze that you can't unpause. Assuming you really want to add more logic here:

You want to pause when you are running out of lemmings, not when you have run out of lemmings. Therefore, it's conceivable to move the origin of this information into/near physics, because that's when we run out of lemmings.

When, at the start of a physics update, you still have lemmings, and you've run out of lemmings after this physics update, then a result of this physics update is that the UI should react (to losing all lemmings). The physics update doesn't care of how exactly to react; the UI will look at the user options.

This avoids state (no need to remember whether we've already paused for loss) but puts UI-relevant logic into physics (which we usually want to avoid). The physics already tell the UI about many things, e.g., to play sound, and this would then be one more event that the UI receives from the physics.

I haven't checked the NL source if this is easy, or even if it's sensible at all for NL.

Even in Lix, where I have a dedicated class for this concept (EffectSink) of ferrying eye/ear candy (sound commands, commands to generate explosion debris, commands to make a flying pickaxe, assignment arrows, ...) from physics into the physics-ignorant part, I'd have to write extra code to pry the message from the EffectSink into the speed logic (which so far is completely independent of the effect sink).

namida shows sensible feeling already in the wording ("message") instead of treating this purely as a state check. It may be wrong in NL to put it in the physics, but even elsewhere, it's still good to think of this particular pausing as a message/event, not as a continuous situation.

-- Simon