Implement Rewind to Last Assignment Like NL?

[kaywhyn]

See this topic from the Bugs and Suggestions Board for NL. Not sure how difficult it would be for Lix, though.

https://www.lemmingsforums.net/index.php?topic=3174.msg62994#msg62994

Quite honestly, while playing Lix in the last few weeks, this is one of the features from NL I miss very much. I use it extensively in my LP's of NL content and I find it super helpful. Currently, I find it very annoying to hold down the rewind key to go back 1 second repeatedly. Of course, I know there's the replay tweaker in Lix, but as mentioned in the "tooltip cancelling replay topic," I don't ever use it, whether in Lix or NL, so that's on me

[Simon]

In NL 12.5.5 12.12.5, this rewinds to two ticks before the assignment has happened. I.e., you use this, then step forward one tick, and still your assignment hasn't replayed. Only if you step forward a second tick, you see the result of the assignment.

What is the reason for rewinding to exactly two ticks before the assignment? Years ago, NL had a bug where cutting the replay would cut one frame too late. Is this rewinding behavior an obsolete workaround for that bug? Or is there another reason?

Without a strong reason to rewind to two ticks before the assignment, I would implement this to rewind to one tick before the assignment. I.e., you use this and can still click to cancel the assignment. Or you use this, assign something else (which adds an assignment to the start of the upcoming physics update), thereby cut the old assignment and replace it with a new assignment in the exact same tick as the old assignment. Or you use this, step forward once, and see the old assignment.

If no earlier assignment exists, this restarts the level. Do you want this? Or do you want no effect?

-- Simon

[kaywhyn]

In NL 12.5.5, this rewinds to two ticks before the assignment has happened. I.e., you use this, then step forward one tick, and still your assignment hasn't replayed. Only if you step forward a second tick, you see the result of the assignment.

What is the reason for rewinding to exactly two ticks before the assignment? Years ago, NL had a bug where cutting the replay would cut one frame too late. Is this rewinding behavior an obsolete workaround for that bug? Or is there another reason?

Just to be sure I understand, when you say 12.5.5, do you mean v12.12.5 of NL? This is and has been the most recent version of NL for well over a year now. If not, then you have a really old version of NL. Or rather, a version that doesn't exist. There is a v12.6.5, though! I'm thinking it's simply a different numbering custom/scheme that's used elsewhere around the world which is probably just foreign to us USA people, therefore that's why I'm confused every time I see 12.5.5 from you instead of 12.12.5

Anyway, currently the way it works in NL is rewinding to the frame before the skill assignment. In other words, you use it, step forward a frame, and then if you press the hotkey to advance a frame again, the assignment occurs. In NL, I don't think it was ever rewind 2 frames before the skill assignment, except in the case of it being a bug like you described, but I never ever encountered the hotkey rewinding 2 frames before the point of assignment in my experiences. I must had came long after it has been fixed if it was indeed a bug before.

Without a strong reason to rewind to two ticks before the assignment, I would implement this to rewind to one tick before the assignment. I.e., you use this and can still click to cancel the assignment. Or you use this, assign something else (which adds an assignment to the start of the upcoming physics update), thereby cut the old assignment and replace it with a new assignment in the exact same tick as the old assignment. Or you use this, step forward once, and see the old assignment.

Yes, exactly! As I said, this is currently the way the hotkey works in NL: When pressed, it rewinds to the frame before the skill assignment, not two frames before it. This then allows you to do the things you described, like reassign the current skill on the frame before it was assigned, click to advance a frame and cancel the skill assignment, etc.

If no earlier assignment exists, this restarts the level. Do you want this? Or do you want no effect?

I'm very used to the level restarting when pressing the rewind to previous skill assignment hotkey if there hasn't been any at the time it was pressed, so I would be fine with this behavior carrying over to Lix. At the same time, there's no reason the level should restart in this scenario, since it is a rewind to previous assignment hotkey. If there's no assignment, the level probably shouldn't restart in this case. I do acknowledge that the level restarting could possibly get annoying even though it has never ever bothered me whenever this hotkey instead of the one for restart is pressed, so having no effect would be preferable. The only plus to this that I see is that it simply gives another way to restart the level in addition to either pressing the restart hotkey or clicking on the restart button in the UI. Therefore, I would be fine with Lix implementing this no effect behavior instead of the way NL does it with the level restarting when there aren't any assignments. I'm fine with either behavior, but Lix isn't NL, so perhaps this can be another difference from each other

[Simon]

In NL 12.5.5, this rewinds to two ticks before the assignment

Just to be sure I understand, when you say 12.5.5, do you mean v12.12.5 of NL? This is and has been the most recent version of NL

Yes, I mistyped the version. I tested in 12.12.5, not in 12.5.5.

in NL is rewinding to the frame before the skill assignment.
use it, step forward a frame, and then if you press the hotkey to advance a frame again, the assignment occurs.

You describe the same NL behavior that I describe for NL (and that differs from what I propose for Lix), but I call this NL behavior { rewinding to 2 frames before the assignment } and you call it { rewinding to 1 frame before the assignment }.

The reason for the language difference is probably that when you see the result of tick n, the panel will tell you "Tick n". When you now click a lix, you produce an assignment for tick n + 1 in the replay, and, because the click unpauses, physics will advance to tick n + 1 and perform that assignment. You talk about the player action (which indeed happens after tick n and before tick n + 1) and I've talked about what your action has produced.

Yes, exactly! As I said, this is currently the way the hotkey works in NL: When pressed, it rewinds to the frame before the skill assignment, not two frames before it. This then allows you to do the things you described, like reassign the current skill on the frame before it was assigned, click to advance a frame and cancel the skill assignment, etc.

The functionality that I propose, I didn't describe it as { when pressed, [...] reassign the current skill on the frame before it was assigned }.

I said: When you activate the function that I propose, then click a lix, you cut the earlier assignment X from the replay and produce an assignment Y such that X and Y are in identical ticks (and not such that Y is a tick earlier than X, as what NL 12.12.5 does).

Why does NL 12.12.5, when you rewind-to-previous-assignment (= assignment X) and you then reassign (producing Y), produce an assignment Y that is 1 tick earlier than X? I still believe that this is a leftover bug workaround.

It's possible that you want this out of habit, regardless of why NL 12.12.5 has it in this surprising way.

-- Simon

[kaywhyn]

AH, I completely misinterpreted and misunderstood what you wanted!

Yes, I mistyped the version. I tested in 12.12.5, not in 12.5.5.

Ok, thanks for clarifying that it was an error/typo on your part. Still amusing that you managed to mistype the middle number, though If you haven't done so yet, you might want to fix this number in the title of your jumper skill shadow bug report then

in NL is rewinding to the frame before the skill assignment.
use it, step forward a frame, and then if you press the hotkey to advance a frame again, the assignment occurs.

but I call this NL behavior { rewinding to 2 frames before the assignment } and you call it { rewinding to 1 frame before the assignment }.

Indeed, we're describing the same thing for NL, just worded differently.

The functionality that I propose, I didn't describe it as { when pressed, [...] reassign the current skill on the frame before it was assigned }.

I said: When you activate the function that I propose, then click a lix, you cut the earlier assignment X from the replay and produce an assignment Y such that X and Y are in identical ticks (and not such that Y is a tick earlier than X, as what NL 12.12.5 does).

Yes, I completely understand now. I misinterpreted what you meant earlier. In other words, you want to implement the behavior in Lix as follows: If you press the rewind to last assignment hotkey, followed by a press of the advance 1 frame hotkey, you will see the skill assignment after pressing the latter just once instead of seeing the assignment after pressing the advance 1 frame hotkey twice, which is what currently happens in NL, following the press of the "rewind to last assignment" hotkey. Or, as you have said, this can allow you to assign a different skill on the same frame as the old assignment instead of being on the frame 1 earlier.

This can work too. I'm fine with seeing your idea of the behavior implemented, and again can be another thing that Lix does differently from NL

Why does NL 12.12.5, when you rewind-to-previous-assignment (= assignment X) and you then reassign (producing Y), produce an assignment Y that is 1 tick earlier than X? I still believe that this is a leftover bug workaround.

I disagree about it being a bug. This current NL behavior of the function has never bothered me and which I find very helpful and useful, nor has anyone complained about it, though it's possible there might still be some angst about the feature, maybe from ones who aren't as vocal.

It's possible that you want this out of habit, regardless of why NL 12.12.5 has it in this surprising way.

It came about because currently I find it very annoying to hold down the rewind 1 second hotkey until I get back to the point before the screw-up, though again when in fact I am bringing this inconvenience onto myself, since there's the replay tweaker but that I simply choose to never use it, whether in Lix or NL. Again, NL's current implementation of the "rewind to last assignment" behavior has never bothered me whenever I have used the hotkey and therefore I don't see it as a bug, but I'm perfectly fine with your idea of its implementation for Lix

[Simon]

Attached, for testing, is a 64-bit Windows build of Lix that replaces the 1-second-rewind with rewind-to-before-previous-assignment. Design choices: It skips to the frame before the assignment affects physics, i.e., the frame in which we would click to produce that assignment, i.e., the frame that you've called the frame of assignment. If no previous assignments exist, it restarts the level. Somehow this restarting felt natural.

I'll reply in more detail later.

-- Simon

[Simon]

to fix this number in the title of your jumper skill shadow bug report then

Changed 12.5.5 to 12.12.5 in NL jump arc shadow topic, thanks!

you want this out of habit, regardless of why NL 12.12.5 has it in this surprising way.

annoying to hold down the rewind 1 second

Right, I see why rewind-to-previous-assignment is useful.

With "you want this out of habit", I meant: When NL rewinds to before the assignment, why do you consider it natural/desirable/correct/... that it rewinds to exactly 2 ticks before the assignment's effect (1 tick before the click), and not to the immediate tick before the assignments effect (the tick of the click).

I don't question the usefulness of rewinding to some tick near the assignment.

This can work too. I'm fine with seeing your idea of the behavior implemented, and again can be another thing that Lix does differently from NL

Okay, I see now that you don't mind as much exactly how far before the assignment it goes.

I think I'll keep the rewind to the tick immediately before the visible effect of the assignment, then. If you begin to miss some deep importance of NL's behavior, let me know.

this is a leftover bug workaround.

I disagree about it being a bug.

By "bug", I didn't mean this rewinding behavior.

I called this a workaround for a different bug, and that bug was: LMB advances physics before cancelling replay. This has long been fixed. I reported it in 2016-02 and namida fixed it around middle 2016.

I didn't dig for the history of the rewind-to-previous-assignment in NL. I merely remembered that I filed that replay-cancelling bug. It's possible that rewind-to-previous-assignment is entirely unrelated to that replay-cancelling bug.

Then why do I bring this history up at all? I copy a feature from NL here. It's possible that NL's rewinding to precisely 2 ticks before the assignment's effect is somehow really useful/natural/smart/..., compared to rewinding to the immediate tick before the effect. What importance might I be missing when I implement it in Lix to rewind to the frame immediate before?

The main deeper meaning I can imagine is: Rewinding to 2 ticks before the assignment would have been useful when NL had that replay-cancelling bug. Under that bug, and under NL's rewind-to-2-ticks-before-assignment, you can { activate that rewind, then left-click to cancel replay } and still see the replay cancelled; compared to being under that bug, but with Lix's proposed rewind-to-1-tick-before-assignment, you would { activate that rewind, then left-click to cancel replay }, but thereby run into the bug where NL replays the unwanted previous assignment that you didn't see yet on screen, but you wanted to cancel with the left-click.

Since Lix hasn't had such a replay-cancelling bug, I don't need that workaround.

The second possible reason is that NL's rewind-to-2-ticks-before-assignment makes it easier to pull the assignment exactly one tick earlier (omits need to use the 1-tick-rewind before reassinging), at the cost of unnaturality of the feature. If this is your only use case, I recommend the tweaker. It's designed to do exactly that: Tweak assignments that were mistimed by a few ticks.

Given that I could have recommended the tweaker in the first place, why do I still jump on this opportunity to implement rewind-to-previous-assignment at all? The answer is: I've considered to add this functionality to the tweaker, too: Click on an assignment line in the tweaker to skip/rewind to the time of that assignment. Now, suddenly, you want this even outside the tweaker, and you have lots of experience with that feature to boot. I'm considering you the expert for this. If I deviate from exactly what you know (exactly to what tick around the assignment to rewind/skip), I'll better know what I'm doing.

That's the reason why I'm making this discussion feel like pulling teeth.

-- Simon

[Simon]

Attached is today's 0.10.16 with the same change (replace 1-second-rewind with rewind-to-previous-assignment).

Have you had time to test these?

Once you like the behavior, the main problem will be UI. Do we inflict the previous-skill-rewind on others by dropping the 1-second-rewind, or do we make it an extra button that goes where in the full panel, or do we make it a user option, do we put the visible button in the tweaker but let it react to a hotkey even while the tweaker is closed, ...

-- Simon

[Simon]

I'm beginning to think that this (= rewind to the physics update before the most recent assignment) should become a full-fledged panel button. We have the space because the restart button is double-width; we can cut that back to normal width.

You probably know the big arrows that appear over a lix after a replayed skill assignment. They lead me to another idea:

This rewind should go hand-in-hand with similar markings that appear before the next skill assignment. Assignment notifications de luxe!

-- Simon

[WillLem]

Just wanted to show some support for this feature happening. Also...

In NL 12.5.5 12.12.5, this rewinds to two ticks before the assignment has happened
...
Years ago, NL had a bug where cutting the replay would cut one frame too late. Is this rewinding behavior an obsolete workaround for that bug? Or is there another reason?

Without a strong reason to rewind to two ticks before the assignment, I would implement this to rewind to one tick before the assignment

...I'll see if I can get it to "one tick before assignment" in SLX - I'll investigate the bugfix and see if there's any reason it can't be done.

[Simon]

Working on this, to have at least the button (and hotkey) in the next release 0.10.20 or 0.10.21. I believe this button can be really handy once you get used to it.

Attached is a possible button icon. Do you have better ideas?

The extra feedback (after rewind: highlight the lix that will get the next assignment) can come later.

-- Simon

[WillLem]

Attached is a possible button icon. Do you have better ideas?

This is great - very clear

[Simon]

All right, I've drawn this in 1x and 1.5x so far.

Edge case design question: What happens when we activate this new rewind button, but there is no earlier skill assignment? Ideas:

• Don't allow it. Hide this new rewind button entirely. While it is hidden, widen the restart-from-beginning button (make it as wide as it is in the current stable, e.g., 0.10.19) and endow the restart button with the rewind's hotkey.
• Do nothing. We show the rewind button, and you can click it, but nothing happens on activation.
• Restart from the beginning. Pause, because this rewind button normally pauses.
• Restart from the beginning. Unpause (you can then watch the hatch open at normal speed) because the restart-from-beginning button normally unpauses, and the rewind behaved like the restart-from-beginning.

Edit: I've chosen #4 (restart from beginning and unpause) and implemented it in Lix 0.10.20.

Leaning towards #1 (hide button), which seems clearest. Problem: With #1, buttons appear and disapper during play. If you convince me that #1 is bad, I'll lean towards #4 (restart from beginning and unpause).

Pie-in-the-sky downside of #1: If we ever make this new rewind-to-assignment button a two-task button (react to LMB and RMB), and make RMB clicks skips to the next skill assignment, we can't hide the button meaningfully anymore. But two-task UI sounds bad here, usually the second task is a better version of the first (e.g., fast-forward with second mode turbo-fast-forward), not an inverse version.

-- Simon

[Simon]

Lix 0.10.20 will have the button with above idea #4: Button always shows. Framesteps to immediately before the previous skill assignment and pauses. If no earlier skill assignments, restart from the beginning, then unpause (you can then watch the hatch open at normal speed) because the restart-from-beginning button normally unpauses, and the rewind behaved like the restart-from-beginning.

There will be no default hotkey. You can bind one in the options menu.

-- Simon

[Simon]

kaywhyn wrote feedback in Explain Traps/Flingers on Mouseover:

Same thing with the rewind to previous skill assignment feature, though admittedly I was negligent on the feedback on testing it before it was in stable Lix. In all honesty, I do miss the way NL implemented it, though interestingly enough namida's implementation of it for Loap is the exact same as Lix's current implementation of the feature. So, I guess I could live with this, but I'm definitely used to NL's manner of the feature's implementation, only because in this way I don't have to press the hotkey to step back a frame too.

Thanks for the feedback!

Please record a solving session in NL for me. E.g., upload unlisted to Youtube. It's hard to imagine why you want to rewind to exactly 2 physics updates before you see the assignment, not to 1, or 3, or 4, or ... Skill assignments aren't that often late by exactly 1 physics update; they're late or early by a few. I'd like to see your NL usage in the general case.

You rely on a bug in NL, or, more specifically, on a leftover workaround for a fixed NL bug. There can be value here. It's always possible that accidental features end up more useful than what we design. But I'd really like to see it in action first before I implement anything different than the obvious rewind to the physics update immediately before the assignment.

To pull assignments earlier/later by 1 physics update, try the replay tweaker. You'll get your result faster than with any NL workflow.

-- Simon