[SUG] Replay Insert Mode / Replay Editor updates

[Simon]

WillLem and I know where to attack in the source, but source discussion has a separate topic.

Back to the design of insert mode.

Will uses NL's insert mode often, or rather the SLX mode that is NL's mode with absolute overwrite prevention. For this post, I'll define it as:

• In cut mode, on new assignment, cut all lemmings' future, then add the new assignment.
  
• In insert mode, on new assignment, look at the next physics update; if no assignment sits there, add the new assignment. (Never remove or overwrite.)
  
• Air clicks cut all lemmings' future only if you're in cut mode.
  

For reference, Lix's insert mode:

• In cut mode, on new assignment, cut all lix' future, then add the new assignment.
  
• In insert mode, on new assignment, cut the same lix's future, then add the new assignment.
  
• Air clicks cut all lix's future regardless of mode.
  

Will cares about integrity of the replay as a whole. This guarantees that you can revert your change. Any map click in insert mode either does nothing, or it inserts exactly one assignment, which you can revert by erasing.

I care about integrity of unaffected timelines. When lemmings A and B will not interact, assignments to A in insert mode should not affect what B will do. This is weaker than Will's goal of preserving the entire replay. I welcome cutting A's future because junk assignments are annoying. I accept that this has no easy reversal.

Consider a player accidentally deleting 20 carefully configured future assignments with a single click; we should guard against this, however unlikely it may seem.

For air clicks, I haven't made up my mind about how much value the easy reversal has. In today's stream of NepsterLix, I played Lots of Small Tasks, a 20-fold disjoint union. I was in insert mode throughout. I took care not to click air by accident. I explicitly say so in my twitch stream at 57:50 -- this is again the lingering fear that I'd like to design away.

On the other hand, when air clicks in Lix's insert mode didn't cut the global future, I got annoyed in 2022/2023.

When I'm sure that my click goes to the desired lix, I haven't experienced such fear recently. I suppose that misassigning to wrong lemming, and accidentally cutting his 20 assignments, is rare enough. But I can't prove that either.

In Lix, sometimes, I cut the same lix's future explicitly. Maybe I do this when I really care about the replay as a whole? I haven't paid attention to that yet. Sometimes I'll implicitly cut by assignment in insert mode. One big idea behind Lix's insert mode is that I wanted to solve disjoint unions and have each sublevel feel like it has its own replay.

I have no good answer for the design yet. A complete undo stack of replay changes feels like travelling in a new fifth dimension (x, y, physics updates, replay, undo), but it's not out of the question. I'll sleep over it more.

-- Simon

[WillLem]

Will cares about integrity of the replay as a whole ... I care about integrity of unaffected timelines

There are definitely benefits to both designs. One preserves everything indiscriminately and protects against accidental clicks/assignments/etc, the other allows replay tweaking on-the-fly rather than having to open a separate replay editing window.

As with most things, it comes down to user preference. Personally, I'm likely to continue to want Replay Insert to be a total "No Overwrite" mode for my own purposes and so this will probably continue to be available (if not default) behaviour, but I would be open to adding an option, a hotkey, or some other way of getting the Lix-style behaviour if people want it, and if we can figure out how to do it!

I played Lots of Small Tasks, a 20-fold disjoint union. I was in insert mode throughout. I took care not to click air by accident. I explicitly say so in my twitch stream at 57:50 -- this is again the lingering fear that I'd like to design away.

On the other hand, when air clicks in Lix's insert mode didn't cut the global future, I got annoyed in 2022/2023.

The proposed (and, let's be clear, current) NL-CE behaviour solves the first problem and creates the second. It seems there is no easy answer for "should clicking air cancel Replay Insert?" - I'd lean more towards that it shouldn't, for similar reasons to not wanting to overwrite assignments.

[Simon]

Then put absolute overwrite prevention into the next release. It's already better than NL 12.14, which accidentally overwrites different lemming.

The problem with your hotkey remains that it overwrites different lemming, which nobody wants. We have seen that different-lemming prevention is amenable code-wise. I'll help you until it's done.

-- Simon

[WillLem]

Then put absolute overwrite prevention into the next release.

It should already be in the RC...? (Can't check right now, on mobile).

The problem with your hotkey remains that it overwrites different lemming, which nobody wants.

It doesn't have to. If we figure out SameFrameSamLem, that could be the hotkey behaviour for sure.

I'll help you until it's done.

That's good, I appreciate that. You help temper some of my more haphazard coding habits and it's always nice to have your company

[Simon]

absolute overwrite prevention into the next release.

It should already be in the RC...?

Ah, yes, RC1 prevents all overwrites. It behaves as follows. Situation:

• Replay contains old assignment for the next tick.
  
• Activate insert mode.
  
• Point to a lemming that would normally (= if nothing were in the replay) eligible to be assigned.
  
• Click.
  

The game then does:

• You hear an assign sound.
  
• The replay stays as before the click. You didn't cut, you didn't insert.
  
• Physics advance once.
  
• The old assignment replays.
  

This UX is problematic. You hear the expected assignment sound exactly as after a successful click, and the physics advance, too. But the click didn't produce what we wanted. It feels like a bug.

It's outright misleading when we assign permanents that will do nothing on the immediate next frame. The potential assignee does exactly what he would do if the click's assignment went through: Walk forward once.

-- Simon

[WillLem]

This UX is problematic. You hear the expected assignment sound exactly as after a successful click ... It feels like a bug.

The assignment sound happens because of the original assignment, this we know. You should also hear the assign fail sound as well; can you confirm this?

But yes, it's clearly not ideal.

My suggested solution to this if we keep "no overwrite" behaviour would be to only trigger the assign fail sound for this particular situation (i.e. attempted assignment fails due to existing assignment). The slight inconsistency with the fact that the assignment sound is heard wherever else there is assignment during replay mode is acceptable; here, the assignment failure feedback is more important.

[Simon]

Yes, I hear both the successful old assignment and the short click for the failed assignment. I didn't notice that yesterday.

I agree that you shouldn't play a successful sound here.

On a click that will not assign, don't advance physics in the first place? Play only the failed assignment. Then you won't have to introduce inconsistencies. On air clicks, you probably want to advance physics, but air clicks are safe, can't mistake air clicks for a wanted assignment.

Wondering if you want to tell people before the click that the assignment will not go through.

-- Simon

[WillLem]

I agree that you shouldn't play a successful sound here.

OK, I'll implement this for the 1.0 release version. EDIT - This is now implemented ready for release.

On a click that will not assign, don't advance physics in the first place? Play only the failed assignment. Then you won't have to introduce inconsistencies.

Unless I'm misunderstanding what you mean, not advancing physics on a mouse click would be inconsistent. At every other time, clicking advances physics; I see no reason to change this.

Also, the player needs to see the reason their assignment has failed: because there is an existing assignment, which will be activated on clicking and advancing physics.

(Again, I might have misunderstood what you meant).

Wondering if you want to tell people before the click that the assignment will not go through.

We'd need a way to detect future assignments to the selected lemming, which we currently don't have (but would likely need to be implemented to allow same-frame-same-lem assignments anyway).

What sort of feedback do you imagine? Some ideas: the lemming could simply not be selectable on the frame prior to the assignment, or the selection rectangle could have a big "X" through it. A "this lem cannot be assigned" message in the panel would also be OK.

This could look like a bug, though. I still think the failed assignment itself is enough feedback: let the user know why it's failed, rather than that it can't happen (but without providing a reason).

Consider: the user cannot assign on the next frame anyway, so physics might as well advance, the fail sound plays, the original assignment is seen, and the player can see the reason why they can't assign on that frame. They then simply step to another frame to assign the new skill or use the Replay Editor to remove the original assignment if it absolutely must be on that frame.

[Simon]

inconsistent
might have misunderstood

I meant: In NL 12.14, all replayed assignments sound the same (all play the regular assignment sound effect). In your RC2, only some replayed assignments will sound like that. Those replayed after a failed click will produce no sound. This will be less consistent.

But it's decent. It's better than (advance physics + play sound for successful assignment).

Next week, I will playtest in Lix: Replayed assignments sound different than freshly clicked assignments.

not advancing physics on a mouse click would be inconsistent.

The intuition here was: If you can't give the player what he wants the most (assignment), give nothing. Don't give 30 %. Fail as clearly as you can.

The alternative to make all click failures not advance physics. E.g., player clicks to assign basher to basher, physics shouldn't advance. Then that not-advancing will be consistent with the not-advancing on failures that come from old assignments in the replay. You'll also preserve the sound consistency; all replayed assignments produce the same sound.

user cannot assign on the next frame anyway, so physics might as well advance

Hmm.

He can change the release rate, but that would be a feeble argument.

He can delete the old same-lemming assignment, then assign. If you advance, he'll have to rewind, then delete, then assign. I'll sleep over this.

let the user know why it's failed
physics might as well advance
original assignment is seen

The original assignment can be elsewhere in the level, for an unrelated lemming.

This will remain a design problem even if you eventually allow same-lemming overwrite as an option. I have no good answer for this.

What sort of feedback do you imagine?

No idea yet. This design problem is entirely new. I was curios how satisfied you were with the RC's feedback on failed clicks. Yes, assume that we solve all technical problems, e.g., how to fetch this information from the replay.

I agree that we shouldn't make things look like bugs. Generic crossed-out cursors or no-signs won't clarify the reason behind the click that is going fail. Some leeway you have, it's a corner case in an expert feature.

If you're happy with what you have, release CE 1.0 with what you have. It's better than NL 12.14 because it prevents accidental different-lemming overwrites. We can solve the hard design problems in March. And user options for same-lemming overwriting (really: cut future of that lemming, then assign) can also wait.

I don't mind going 5 times in circles with this. You're the first to shred the Lix design choices. I wonder if I want to make it a user option in Lix whether air clicks in insert mode cut the replay.

-- Simon

[WillLem]

In NL 12.14, all replayed assignments sound the same (all play the regular assignment sound effect). In your RC2, only some replayed assignments will sound like that. Those replayed after a failed click will produce no sound. This will be less consistent.

Yes, having implemented this and tested it a few times, it does feel somewhat odd, even if it is technically "better UX"...

The intuition here was: If you can't give the player what he wants the most (assignment), give nothing. Don't give 30 %. Fail as clearly as you can.
...
Then that not-advancing will be consistent with the not-advancing on failures that come from old assignments in the replay. You'll also preserve the sound consistency; all replayed assignments produce the same sound.

I see. In that case, this is definitely worth a try. For RC2 For the 1.0 release*, all assignments that fail due to an existing assignment at the same frame don't advance physics (and, trigger the Assign Fail sound as feedback).

*RC1 feedback has been slow, let's just go ahead with the release version. We can always tweak this again in later updates.

[Simon]

assignments that fail due to an existing assignment at the same frame don't advance physics

... but all other failures to assign still advance physics: You select basher, you click on a basher, and physics advance from this failed assignment.

I agree that this combination a good choice to try in public. I'm not sure if it's absolutely best and I'd like to see feedback.

Reason: I've experimented with non-advancing failed assignment in Lix singleplayer streams. It wasn't fun to block all failed assignments from advancing physics. When an ascender/hoister is still ascending, but we know that he'll be assignable within 1-3 physics updates, I'll select builder and click on him several times. This ensures that he builds ASAP. I didn't know that I used this pattern until I removed it experimentally, and I'm putting it back in.

-- Simon

[WillLem]

When an ascender/hoister is still ascending, but we know that he'll be assignable within 1-3 physics updates, I'll select builder and click on him several times. This ensures that he builds ASAP. I didn't know that I used this pattern until I removed it experimentally, and I'm putting it back in.

Yeah, exactly. This is one of the reasons I wasn't sure about preventing physics advancements. I'm still not 100% sure it's best either.

It works well to offset confusion caused by either "we heard the assign skill sound but this is not the skill we tried to assign" or "we heard the assign fail sound and yet the lemming has begun an action", but also causes the player to have to click more times to get to a frame they can assign upon. If we advance physics and allow the sound clashes, we get to assign in fewer clicks.

There is probably no 100% correct answer to this one. Happy to consider any ideas that anybody might have.