[BUG][PLAYER] On assignment for frame n, first erase old assignment for n

Simon · May 30, 2019, 05:02:37 PM

Split off from Simon should report these 3 NL bugs properly:

How to repro:

1. Assign something, B, for physics update ("phyu") n, to lemming L.
2. Framestep back to between physics updates n-1 and n.
3. Assign something, A, for phyu n to lemming L.

What happens: B is replayed and your new assignment A is eaten without effect. B's effect is visible on the screen.

Expected instead: B is erased from the replay and A becomes part of the replay, and A's effect is visible on the screen.

Quote1. If you framestep back to between physics updates ("phyus") n-1 and n, and then assign A for phyu n to lemming L, but the replay already contains an assignment B at phyu n (forgot whether it has to be to L or not), then B is replayed and your assignment A is eaten. Expected instead: B is erased from the replay and A gets through.

namida wrote: This has been a known issue for so long - since Lemmix even, I think - that it doesn't even register to me anymore - it's just "I have to step back two frames to cancel that assignment". But you're right, this absolutely should be fixed.

-- Simon

namida · May 30, 2019, 07:32:36 PM

Edited topic title to reflect the typical naming scheme for this board. (I don't know if Nepster feels the same way, but I actually find this to be really useful when looking through the topics to find stuff to work on.)

namida · September 27, 2019, 02:18:56 AM

After being a known bug for something like 5 years, if not more, this is finally fixed in commit 108240B.

namida · September 27, 2019, 05:03:38 AM

Reopened because a related bug still exists: If you just click in empty space or press the cancel replay key on such a frame, the assignment still occurs; the correct behaviour is only happening for a new assignment.

namida · September 27, 2019, 05:28:54 AM

And fixed. I'm a bit wary of this fix - it feels too simple, almost "I would've done this already if this didn't cause some side effect", but I don't recall actually trying it. Please look out for possible awkward behaviour around this fix during the release candidate phase; I've specifically tagged the commit that fixes this just so I can easily find and reverse it if need be.