[?][SUG][PL] Insert Mode: Erase future of same lemming

[Simon]

CE 1.0.1
NL 12.14

During Insert Mode between physics updates N and N+1, when you insert a skill assignment to lemming A that will affect physics update N+1: First erase the future of A in the replay (erase all assignments to A at N+1, N+2, N+3, ...), then assign to A.

This will fix two problems at once:

• The garbage will be automatically deleted. In existing NL, the player must now either go to the replay editor to delete the garbage by hand, or, worse, let it clutter the replay and hope.
  
• You naturally allow same-frame-same-lemming overwriting. CE 1.0.1 blocks same-frame-same-lemming, which is the most annoying type of failed assignment because the intention is clear.
  

If you're concerned about losing data, we can talk. The hunch is that you shouldn't worry, but I'm happy to be convinced otherwise.

Armani and I have already argued for this in Improve same-frame assignment behaviour in Replay Insert mode, which is now closed. That thread, anyway, became more about the sound for failed assignments and whether to advance physics on failed assignment.

-- Simon

[WillLem]

Armani and I have already argued for this in Improve same-frame assignment behaviour in Replay Insert mode, which is now closed.

Not sure why the topic was closed as it hasn't yet been resolved and is still in the Bugs & Sugs board. Anyways, I've re-opened it.

First erase the future of A in the replay (erase all assignments to A at N+1, N+2, N+3, ...), then assign to A.

...

CE 1.0.1 blocks same-frame-same-lemming, which is the most annoying type of failed assignment because the intention is clear.

My instinct with this is (and always has been) that we shouldn't erase replay actions invisibly; if the player wishes to erase all future actions for this lemming, it should ideally be done via the replay editor where the player can see exactly what's happening.

Regarding the second point, IMO the benefit of {not accidentally overwriting a previous action unintentionally} outweighs the annoyance of having to either (a) move to another frame to make the desired assignment, or (b) manually delete the existing action (and future, if desired) via the replay editor.

The whole point of Replay Insert mode is that it preserves all existing actions. The OP is suggesting a third mode, which preserves all existing actions {except these}. Further complication of the replay system, more for new players to learn, potential for mess/bugs in the code.

Bottom line is that the engine is ultimately meant to be a game. The replay editing features are a nice bonus, and should of course be as sophisticated as we can possibly make them. But in-game actions such as skill assignments should have completely visible (or audible) results; nothing should be happening that the player doesn't know about (i.e. deleting future assignments).

Possible solution:

A hold-during-assignment hotkey which means "I want to delete" might be the best compromise here? We'd also change the cursor whilst it's held.

[Simon]

(a) move to another frame to make the desired assignment

On a same-lemming assignment? If you add your new assignment after/before the existing assignment, you waste a skill, or you produce garbage that's going to waste a skill on the next frame and cancel your worker lemming. (a) doesn't work around a same-lemming clash; this is different than for a different-lemming clash.

(b) manually delete the existing action (and future, if desired) via the replay editor.

Obviously we disagree here.

I'll write more in late November 2025 because I'll be short on time these days. Until then, focus on other bugs.

In the meantime: I encourage other players to join.

-- Simon

[Simon]

I'll have time to look at the code together on Saturday, November 29th. Does that suit you? I'll have time all day and you can pick the time.

-- Simon

[WillLem]

I'll have time to look at the code together on Saturday, November 29th. Does that suit you? I'll have time all day and you can pick the time.

Apologies Simon, I missed this message. I'd be happy to look at this with you again at some point in the next few weeks.

[Simon]

Hi! Thanks for coming back to this.

Time is tight these weeks. I can offer you: [some dates, WillLem picked Saturday, 7th]. Time of day is your choice, ideally in the atfernoon or early European evening.

This is mainly to look at the NL source to look at the existing infrastructure, and to rule out potential bugs that would arise from the implicit cutting of same-lemming future.

-- Simon

[WillLem]

I can offer you: Saturday, March 7, or Sunday, March 8

Both are fine for me, let's go for 3pm CET (2pm UTC) on Saturday. We should only need a couple of hours. See you then

[Simon]

All right, I've noted Saturday, March 7th, 15:00 CET (14:00 UTC). See you!

-- Simon

[Simon]

Implementing the function from voice chat.

I can't build Delphi here to test. There will probably be many small errors.

How wise is cutting future nukes when we cut an assignee's assignment future? I think it's correct to cut the future nuke. If you disagree, put Continue; instead of the empty statement ;. I erase future nukes in Lix, got no negative feedback, and most NL levels behave like Lix levels in this regard. Nuke levels are rare and you can always re-insert the nuke. Inserting a nuke shouldn't cut future assignments of anybody.

Code Select Expand

procedure TReplay.EraseLemSkillAssignment(
  L: TLemming;
  aFrame: Integer;
  DoCutFuture: Boolean);
var
  Item: TBaseReplayItem;
  i: Integer;
begin
  for i := fAssignments.Count - 1 downto 0 do
  begin
    Item := fAssignments.Items[i];
    if (Item.Frame < aFrame or (Item.Frame <> aFrame and not DoCutFuture)) then
      Continue;

    if (Item is TReplayNuke) then
      ; // Always delete a future nuke, like in Lix. Okay in NeoLemmix or not?
    else if (Item is TReplaySkillAssignment) then
      if ((Item as TReplaySkillAssignment).LemmingIndex = L.LemIndex) then
        Continue;

    fAssignments.Delete(i);
  end;
end;
-- Simon

[WillLem]

Thanks, Simon.

Your modified version of the method compiles with the following tweaks (see condition brackets, and no ";" for the empty statement):

Code Select Expand

procedure TReplay.EraseLemSkillAssignment(
  L: TLemming;
  aFrame: Integer;
  DoCutFuture: Boolean);
var
  Item: TBaseReplayItem;
  i: Integer;
begin
  for i := fAssignments.Count - 1 downto 0 do
  begin
    Item := fAssignments.Items[i];
    if ((Item.Frame < aFrame) or ((Item.Frame <> aFrame) and not DoCutFuture)) then
      Continue;

    if (Item is TReplayNuke) then
       // Always delete a future nuke
    else if (Item is TReplaySkillAssignment) then
      if ((Item as TReplaySkillAssignment).LemmingIndex = L.LemIndex) then
        Continue;

    fAssignments.Delete(i);
  end;
end;


[WillLem]

Apologies for the double-post, but this ideally shouldn't be hidden under the code in the previous post.

I need community feedback before deciding on the following:

1) Should we allow same-lem-same-frame assignment in Replay Insert mode?
2) Should we always erase the lem's future existing assignments when making an assignment, regardless of replay mode?
3) Should we erase future nuke when making an assignment in Replay Insert mode?

I'll give this a minimum of 1 month from today to generate discussion.

Your silence = I will probably mostly go ahead and follow Simon's advice, i.e. we'll allow same-frame-same-lemming overwrite even in Replay Insert mode, and will also erase the future assignments of that lemming. I'll also probably make this behaviour optional in Settings; having thought over the proposed hotkey, it's probably asking too much of players to press a key every time they want to make an assignment if they know they always want the same behaviour. Meanwhile, I probably won't erase the nuke, but Simon may convince me otherwise next time we meet.

So:

1) Yes, optionally 2) Yes, optionally 3) Maybe, but probably not.

[Simon]

I'll steelman a case for the restrictive behavior 2) No, and weakly 1) No:

You have 50 lemmings in a dense pack. The replay contains a future builder assignment for one of them, followed by a largely-completed 10-skill route (he's a main worker). Now you want to bash with one of the 50 lemmings in the dense pack. You click into the middle of the pack. If you're unlucky and bash with the soon-to-be builder, you lose the builder's future, i.e., you cut the 10-skill route from the replay.

In Lix, this risk is reduced because Lix (under default options) is in insert mode whenever the tweaker is open. In the tweaker, you see the hovered lix's future assignments highlit. You'll think twice before you click. NL doesn't have this default behavior and indeed warrants separate risk-vs-annoyance balance.

Ideal would be: 1)-2) Yes, and some previewing power into the replay/click, and an undo stack for changes to the replay. Such undo is expensive to implement. Will and I consider undo out of scope of this issue here.

Please participate in WillLem's call for feedback (in the post before this)!

-- Simon