[bug] [player] Desync when RR change & assignment in same frame

[Simon]

<namida42> this [= the assignment logic], and a fix to the weird window stuff, are the two biggest things needed. but both are intimidating tasks.
<SimonNa> hmm
<SimonNa> the windowing has more severe impact for me
<SimonNa> but the assignment is so lovely and exciting to find bugs in, I focus on that, it's like fishing in a lake

I reeled in this carp. This can desync replay and physics: You will see different actions on the screen than what actions will be replayed later.

1. Play a RR 1 level. Let a lem spawn and land.
2. Pause.
3. Set the RR to 99 by right-clicking on the + panel. This doesn't advance physics.
4. Advance exactly 1 frame with the hotkey that advances physics and doesn't cancel the replay. This seems to write the RR change into the replay.
5. Step back 1 frame. See how the RR in the panel shows 1 again.
6. Assign basher.
7. Unpause. Watch the lemming bash. The game will continue to spawn lems at RR 1.
8. Restart level. Watch the lemming bash. The game will continue to spawn lems at RR 99.

The physics lack an action that the replay has: The change of the RR to 99. Expected instead: Items 7 and 8 above continue with the same RR.

You can repro an equivalent bug by replacing RR-to-99 with nuking.

As for LMB advances before cancelling replay, namida and I agree on a more fundamental redesign of the assignment logic: All input goes into the replay first, then the game fetches data from the replay and invokes the data on the physics. The program should be designed such that this is the only way to affect physics.

-- Simon

[namida]

As for LMB advances before cancelling replay, namida and I agree on a more fundamental redesign of the assignment logic: All input goes into the replay first, then the game fetches data from the replay and invokes the data on the physics. The program should be designed such that this is the only way to affect physics.

This change has now been made in the source code (in a seperate branch, just in case). Pending further testing (for anyone who'd like to help test this, you can get a copy with this change here; this copy is identical to V1.47n-C except for this overhaul and the addition of Nepster's extra object info icons), which I'll probably do soon, we should be very close to having an inherently desync-proof NeoLemmix, rather than active measures being taken to fix desyncs when they occur. ^_^

EDIT: There are several known issues with assigning skills to the highlit lemming in this version.

EDIT: The above experimental has been removed. The new 1.47n-D:FC73BC8 experimental includes the changes discussed here.

[namida]

Reuploaded. New version fixes the issues with assigning to highlit lemmings.

[Simon]

I have tried 1.47-C, 86efbd6. I haven't been able to get a desync anymore. Well done.

Remaining is 2 bugs, and 1 design question. I'll post them in this thread, because you posted 86efbd6 in this thread, and it's particular to that.

1. Assign something.
2. Framestep back to the frame right before the assignment is carried out.
3. Double-click nuke, then unpause.
Observed: The assignment is carried out, no nuke.
Expected: The assignment is cancelled, instead we get nuke countdowns.

Setting the RR removes from the replay all future assignments, except the assignments for the very next frame. I don't know if this is intended or not. While you don't allow multiple assignments per frame, you allow 1 assignment, 1 RR change, and 1 nuke at same time. Example: The replay has saved commands A, B, C for the next frame, and we input command D for that frame, and then we input command E for that frame. I want D to remove A, B, C from the replay, but we don't want E to remove D. The Lix solution is that D and E go into a special waiting room, and will be only written to the replay right before the update happens, when no more player input can arrive.

Please specify the expected behavior for this corner case. :-)

Sometimes, you show the R, even though there is no replay data in the future, and sometimes you don't show it, even if there is data. I can find out more details for this bug. I suggest that you don't make a status variable for the R, but instead make it a purely functional dependency.

-- Simon

[namida]

1. Assign something.
2. Framestep back to the frame right before the assignment is carried out.
3. Double-click nuke, then unpause.
Observed: The assignment is carried out, no nuke.
Expected: The assignment is cancelled, instead we get nuke countdowns.

There is no explicit decision as of yet as to whether assign skill and nuke are allowed in the same frame. Regardless, the behaviour should either be (a) both happen, or (b) only the nuke happens; depending on the decision that gets made.

Setting the RR removes from the replay all future assignments, except the assignments for the very next frame. I don't know if this is intended or not.

If the user enters a new action into the replay, all later actions should be removed.

While you don't allow multiple assignments per frame, you allow 1 assignment, 1 RR change, and 1 nuke at same time. Example: The replay has saved commands A, B, C for the next frame, and we input command D for that frame, and then we input command E for that frame. I want D to remove A, B, C from the replay, but we don't want E to remove D. The Lix solution is that D and E go into a special waiting room, and will be only written to the replay right before the update happens, when no more player input can arrive.

RR change + an assignment and/or* a nuke should be valid. The Lix solution sounds like a good approach to use here.
Undecided on nuke + assignment in same frame.

Sometimes, you show the R, even though there is no replay data in the future, and sometimes you don't show it, even if there is data. I can find out more details for this bug. I suggest that you don't make a status variable for the R, but instead make it a purely functional dependency.

The use of a status variable is partly "because I didn't change that part yet". I'll investigate whether simply checking "are there any actions for later frames" is feasible (specifically, whether or not it leads to performance issues) and if so, make the change.