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 (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 :laugh:
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
Quote from: Simon on August 27, 2023, 10:23:54 AM
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.
Quote
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.
Quote
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 ;)
Quote from: kaywhyn on August 27, 2023, 11:23:17 AM
Quote from: Simon on August 27, 2023, 10:23:54 AM
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.
Quotein 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.
QuoteYes, 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
AH, I completely misinterpreted and misunderstood what you wanted! :forehead:
Quote from: Simon on August 27, 2023, 11:58:34 AM
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 :P 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 ;)
Quotein 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.
Quote
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.
Quote
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 ;)
Quote
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.
Quote
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 ;)
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
Quote from: kaywhyn on August 28, 2023, 06:00:01 AM
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 (https://www.lemmingsforums.net/index.php?topic=6144.0), thanks!
Quote from: kaywhyn
Quote from: Simon
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.
Quote from: kaywhyn
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.
Quote from: kaywhyn
Quote from: Simon
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 (https://www.lemmingsforums.net/index.php?topic=2509.0). 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
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
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
Just wanted to show some support for this feature happening. Also...
Quote from: Simon on August 27, 2023, 10:23:54 AM
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.
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
Quote from: Simon on February 10, 2024, 12:34:27 AM
Attached is a possible button icon. Do you have better ideas?
This is great - very clear :thumbsup:
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
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
kaywhyn wrote feedback in Explain Traps/Flingers on Mouseover (https://www.lemmingsforums.net/index.php?topic=6742.msg102489#msg102489):
Quote from: kaywhyn on May 28, 2024, 11:14:53 AM
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
kaywhyn, I'd still like to see you use the NL rewind-to-assignment in action, to see why you need it to rewind to two ticks before the effect is visible (instead of to the immediate tick before the effect is visible).
Since I made rewind-to-previous-assignment a year ago, I haven't used it a single time.
I don't know if I'd use rewind/advance to (the tick before an) an assignment of your choice in the replay tweaker. The tweaker doesn't have this feature yet. It looks natural to make this.
-- Simon
Yes, I have not forgotten about this. Trying to think of the best way to go about this, especially as to avoid spoiling level solutions for you :P For now, let's just say that because I use this hotkey a lot that it has become natural for me during gameplay that I don't really use the "B" key to go back a frame even though pressing the rewind to last assignment hotkey does the same thing once the skill is assigned. Similarly, I use mouse clicks to advance a frame instead of the "N" key. I also find it very useful when I need to undo several skill assignments, even if it might be faster to just hold down the rewind hotkey or restart completely. I don't know, I'm one of those Lemmings/Lix players who generally doesn't like bringing up any pop-up windows/menus during gameplay, hence why I don't like using the replay tweaker even if it's likely the most efficient out of the "going back" hotkeys I use. I find menus during gameplay "intrusive" for some reason.
However, as "actions speak louder than words," I'll definitely get video footage for you of me using this feature. Thinking about it, unless you're ok with them, honestly probably the best thing for me to do is to just find one of my LP videos where I make extensive use of it, but again, the problem is spoilers. This will take some time, as I would have to watch through the many vids I have on my channel. Perhaps I can link a vid where there's only one level where the feature is used.
On another note, is it currently possible to customize the duration of the rewinds/time skips in Lix? If it is, then I'm not aware of how to do so.
Lix has no customization of the rewinds.
What values would you choose?
-- Simon
I use the 5-second rewind and 5-second forward NL hotkeys in addition to the 1-second rewind/forward, 10 second time skip, and rewind to last skill assignment. So really, the 5 seconds would be in addition to all the other rewind/forward Lix hotkeys, not replacing any of them ;)
Quote from: WillLem on February 07, 2024, 08:55:29 PMQuote from: Simon on August 27, 2023, 10:23:54 AMIn 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?
...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.
Finally got around to investigating this. Turns out that namida fixed the "-2" bug (in Commit 9c665ca (https://github.com/Willicious/SuperLemmixPlayer/commit/9c665ca4551352b7735ef631f9fa7c83ed287a60)), so NL (and indeed SLX) actually skips back only 1 frame prior to the previous assignment. Or, at least, it
should.
When checking in the program itself, there is in fact an additional frame to step over before the assignment takes place.
I wonder if, prior to namida's fix, it was necessary to step over 2 frames. If so, then the current behaviour (having to step over 1 frame) is technically correct according to what's written in the code; i.e. the "Previous Assignment" hotkey which performs this skip asks NL to skip to "TargetFrame -1".
Is having to step over a single frame desirable? Or, is the expected behaviour that the next mouse click (i.e. to step forward 1 frame) should advance to the assignment frame? I wonder what the purpose of the extra frame is...?
It would be an easy fix, anyway (at least in NL/SLX); we'd simply ask it to skip to the "TargetFrame" itself.
Quote from: WillLem on November 19, 2024, 06:46:59 PMIs having to step over a single frame desirable? Or, is the expected behaviour that the next mouse click (i.e. to step forward 1 frame) should advance to the assignment frame? I wonder what the purpose of the extra frame is...?
Just giving this a bump. I'm looking at implementing a fix but don't wish to go ahead without answers to these questions, just in case there's a good reason for waiting that extra frame.
Quote from: WillLemIs having to step over a single frame desirable?
Desirable for whom? For kaywhyn? For me?
I cannot give you first-hand UI findings because I never use the feature (rewind to previous assignment). My playstyle doesn't need it.
All I can give you directly: Implementation-/design-wise, it felt more natural to rewind to (the tick before the assignment is visible). It felt unnatural (as in: I never thought of it before kaywhyn tested) to rewind to (the tick before (the tick before the assignment is visible)), which kaywhyn wants.
I'm waiting for kaywhyn to record and show his NL usage as a video. Are you (WillLem) prodding for such a video?
I'll guess why kaywhyn wants to rewind to (the tick before (the tick before seeing the effect of the assignment)). Consider the following 4-step sequence of actions.
- Rewind to before the assignment's effect is visible. I.e., use rewind-previous-assignment in the current Lix 0.10.28.
- Rewind one more tick.
- Assign the same skill (which you've rewound in step 1) to the same lemming.
- Fast-forward to view the result.
This 4-step sequence pulls the assignment earlier by one tick. Step 3 cuts the replay and reassigns the single cut assignment a tick earlier than from where it was cut.
When the rewind-to-skill behaves how kaywhyn wants it, he can omit step 2 because rewind-to-skill will then perform step 1 and step 2 together, not only step 1.
The minus button in the tweaker does all of this in one shot, including viewing the future result. You'll always view the result at the same future tick because you're tweaking an assignment in the past. The minus button is also easier to spam multiple times than it is to repeat that 4-step sequence by hand multiple times.
-- Simon
(Note: by all means split this into a SuperLemmix topic from Reply #19 onwards).
Quote from: Simon on January 01, 2025, 08:42:14 PMDesirable for whom? For kaywhyn? For me?
For anyone.
Quote from: Simon on January 01, 2025, 08:42:14 PMI'll guess why kaywhyn wants to rewind to (the tick before (the tick before seeing the effect of the assignment))
Yes, this is desirable, but what happens in NL/SLX (and I think this is what kaywhyn is requesting) is that "Rewind to last assignment" jumps back to (the tick before (the tick before (
the tick before seeing the effect of the assignment))).
EDIT: I missed the "before" in the innermost parentheses - Simon was in fact referring to the same thingSo, it's likely there's been a slight misunderstanding.
We likely all want the
single extra frame, for the reason outlined by Simon (i.e. so we don't have to skip back an extra frame to modify the original assignment). My question is do we want the
extra extra frame as requested by kaywhyn.
Quote from: Simon on January 01, 2025, 08:42:14 PMAre you (WillLem) prodding for such a video?
I always prefer visual bug reports; so much easier to understand what the problem is. But no, an explanation has been enough in this case.
FWIW, here's the bug. Note the additional un-needed frame:
(https://i.imgur.com/ORhWwyv.gif)
EDIT: It's a single line of code to fix this, so I've gone ahead and implemented it in SLX commit 33a43a3 (https://github.com/Willicious/SuperLemmixPlayer/commit/33a43a35d9b1cf02977117114caeddde9a15df57). We can test it for a bit there and then backport it to NeoLemmix as and when CE happens.
Quote from: WillLem on January 01, 2025, 09:47:23 PMNL/SLX
jumps back to (the tick before (the tick before (the tick before seeing the effect of the assignment))).
We mean the same, but either we count ticks differently, or you didn't see the "before" inside the innermost parentheses.
We see the red builder bag for the first time
after tick 100. The red bag is the visible effect of the assignment
for tick 100. I -- and the Lix UI -- call this earliest sight of the red bag "the world
at tick 100", but it's technically in-between ticks 100 and 101, not
during tick 100. I would understand if somebody called this "at tick 101"; I don't.
The Lix feature rewinds to tick 99. This is before you see the effect of the assignment. In your gif, the walker is straddling, both of his feet touch the ground. At tick 99, we see the effects of all assignments for ticks ..., 96, 97, 98, 99. There are no such assignments this early in the gif. You're contemplating to change SLX to rewind to tick 99.
NL/SLX rewind to tick 98. This is the tick before (the tick before you see the effect of the assignment). The walker's frontal foot is in the air. kaywhyn wants Lix to rewind to 98 instead of to 99.
-- Simon
Quote from: Simon on January 02, 2025, 03:06:20 PMyou didn't see the "before" inside the innermost parentheses.
Yes, that's likely correct :forehead: I've updated my previous message with
strikethroughs.
Quote from: Simon on January 02, 2025, 03:06:20 PMNL/SLX rewind to tick 98. This is the tick before (the tick before you see the effect of the assignment). The walker's frontal foot is in the air. kaywhyn wants Lix to rewind to 98 instead of to 99.
I see. What's the reason for this
@kaywhyn?
Frame 99 allows you to overwrite the original assignment at frame 100 (i.e. the same frame
as the original assignment), whilst providing an extra frame to prevent having to step back to make said assignment.
What's the need for the extra tick that frame 98 provides?